The temple of grog - an agile game
EMUNDO SPIRIT AND AGILE DEVELOPMENT
Having an agile mindset is part of the eMundo spirit. We have lots of agile projects, so basically everyone must know about this. Yet, sometimes, doing agile software development is harder than expected.
To get around this, we developed a game - "The Temple of Grog" - that tries to teach the contents of the agile manifesto without actually doing software development. This makes it much easier because of the domain being completely inconvenient to any single workshop participant.
WHO/WHAT IS THIS GROG?
Grog is a god. Goal of the workshop is to build a temple for Grog.
Grog’s world is full of unknown terms and concepts - just like in real life when a new project enters our scope.
HOW WAS THE GAME CREATED?
The idea was to find a topic/project that is suitable to develop it the agile way, but definitely outside of our usual work scope - namely software development.
-
No single member of the team should have experience in the topic
-
The domain language must be hard to understand
-
Lots of information should be filtered by the participants
-
Additional information should be added later
-
The goal must be open
Building a temple for an unknown god from an unknown world seemed to fulfill all of this criteria very well. Especially the first requirement is easily satisfied, since who can actually claim to have experience in building temples these days?
PLAYING THE GAME
The workshop participants get divided into random teams (which are ideally not the teams from day to day work). The teams get bits of information - where lots of information is weird or misleading. The goal is still unknown.
The workshop is done in iterations where all teams meet again and show the outcomes of their work. Questions to the gamemaster (who is Grog’s representative) can arise any time.
Before starting the first iteration, the gamemaster gives the goal to the teams.
Of course, some influencing by the gamemaster throughout the workshop (like picking team members, changing timeframes, adding additional information, …) helps to show the benefits of agile development.
AFTER THE GAME
Since the goal was clear, yet the way to it certainly was not, the outcome is quite undefined. Grog distinguishes between a "temple" and a "good temple" - this information is packed into the random bits provided to the participants.
Final Review
In the final review, the teams present their final work and the gamemaster may ask if the temple is now good by verifying some measures.
Good teams will be done earlier and present better, like by not having a single presenter. This means the team identified itself really well with the project and agile development has shown itself to be effective.
Retrospective
Finally, a retrospective is done before finishing the workshop.
The retrospective is used to look back at the workshop and identify positive outcomes. Also, it is used to look forward towards existing projects and identify problems within them that can then be discussed with the project’s respective members later.
Ideally, all participants leave the workshop with a refreshed perspective on the principles of agile development that can then be used to further improve the processes in other projects.
DISCLAIMER
Since the workshop is meant to be done without any prior knowledge, we have to be sparing with specific information on the game itself.
Nevertheless, please do not hesitate to contact me if you have questions regarding details of the game.
