Software development is like a cooperative board game: everyone wins or everyone loses. Team members need to work closely together in order to win or achieve the best results. If someone wanted to do everything on their own, then the team probably wouldn’t achieve their goal or even could lose. You can learn a lot about good teamwork, communication, and agile practices in a software house by playing this cooperative game with your team – check out Escape: The Curse of the Temple.
Successful software development is about failing as early as we can and as often as we can in the process, communication and product development in general. You have to inspect and adapt, empirically learn or get feedback about what you’ve done (even if this means failing), then create a short plan for improvement and inspect results again. This is the best way, as no one is 100% right from the beginning.
Improving teamwork and communication takes time, money and usually up to several Sprints. Why not simulate the Sprint environment and improve the team’s dynamics before spending time and money on real Sprints? “Escape: The Curse of the Temple” is the perfect cooperative board game for that. It’s a real-time board game and one game takes only ten minutes.
Game rules and analogies for software development
Here are descriptions of various features of the game followed by analogies for software development.
The objective for a team of max five players is to escape from the temple before the end of a 10-minute soundtrack while exploring chambers, placing magic gems inside them and looking for the exit. In order to win, everyone needs to escape from the temple through the exit chamber before the time runs out.
The objective of a game is similar to the team’s effort to create a potentially shippable product Increment by the end of a Sprint in software development.
Pawns on the board – focusing and switching context
Each player has a pawn in the start chamber and 5 dice which need to be constantly re-rolled during the 10 minutes.
A modular board is built by players during the game by drawing new chambers from the deck, then connecting them to the existing chambers via stairs and eventually moving through them.
A developer focuses on a particular area of code, or switches context, by staying or moving through the chambers. The dice represent developers’ ability to write code.
Dice rolling and sharing resources – writing code and pair programming
Every symbol on the dice has its meaning. You can use the symbol as a resource to make an action but you can also keep the result for the next roll. In case you don’t want to make use of it, you can always re-roll the dice. Every action a player is able to make requires a specific set and quantity of symbols – from 2 to even 10 symbols. Players can team up and use each other resources, but only when they are located in the same chamber.
The feature’s behaviour created by a developer. Rolling dice is like writing code, you need to do it a few times to get the right result. Being in the same chamber is like having shared context, working on a similar code area, or pair programming.
Magic gems and black masks – User Stories and blockers
Players can act as lone wolves or team up to move the magic gems from the backlog to their chamber. Chambers can have maximally 3 slots for magic gems.
There is a chance that a player could roll black masks on one or multiple dice. In this case, the dice with the black mask cannot be used until the player rolls a dice with a golden mask. One golden mask can lift the curse from 1-2 dice with black masks.
Working on Tasks / User Stories by moving them to ‘Done’ or reducing the technical debt by refactoring and writing tests. You can do it on your own, but working together limits the probability of being blocked at some point. We-are-all-in-this-together mentality helps here.
Going back to the start chamber – Daily standup
Twice during the 10-minute game, the team will have to meet inside the start chamber for a short time. If someone does not manage to do it on time, they will lose one die irrevocably.
Daily Scrum (standups, if you like). The team needs to synchronize their efforts. Essentially, it’s quick replanning but only for the next 24h. If you do not participate in it or participate poorly, your ability to work on your own or collaboratively will probably be weakened.
The final seconds – too late for planning
When the exit chamber is discovered, the team is able to leave the temple. In order to do it, each player needs to get to the exit chamber and roll as many symbols of blue keys as there are uncollected gems in the backlog. The more gems the team has placed in chambers, the easier it is for everyone to escape. The important thing is that even if only one player does not escape the temple, the entire team loses.
Analogy for the worst scenario:
None or insufficient planning or/and synchronisation was performed by the team during the Sprint.
Overestimating, underestimating and more impediments
Besides all this, we can increase the randomness and difficulty of the game with the use of special chamber tiles. Cursed chambers – move inside and get an impediment until it will be taken off with dice, or treasure chambers – move inside and get an enhancement.
Sometimes software development goes easier and faster than we have estimated, and sometimes technical uncertainty, complexity, and effort is greater than anyone has thought.
Where is the Product Owner and Scrum Master?
As a Scrum Master, you can play with the team or help them as a servant leader during the game in a similar way as during the workday – solving impediments, learning from feedback, improving a process, planning, educating. You can’t do it for them, but you can help them to do it on their own.
As a Product Owner, it’s a great fun to play with your team, get a little bit of more understanding of their work and see what trouble software development involves.
Tweaking the game
My recommendation is to give the team 1-2 minutes for Sprint (game) Planning before the Sprint (game), and 1-2 minutes for Sprint Review and Retrospective just after the Sprint ends – let them do it on their own.
Encourage the team to measure the Velocity by counting the number of magic gems placed inside the temple at the end of each Sprint, and write it on the whiteboard.
Or even, let’s assume that the whole Product Backlog was refined at 160 Story Points (magic gems) and there is a desire for the release between 9th and 11th Sprint – then let’s play 10 Sprints and see how this goes.
You can also adjust the difficulty of the game. Add more magic gems to the backlog (more Tasks/Stories in Sprint Backlog). Add more chamber tiles to the deck (more technical debt, domain’s complexity or the areas of code to go through). Agree to create a temple in a particular shape and/or place the exit chamber lower or higher in the deck (establishing the Sprint Goal between Product Owner and Development Team).
Teams can even practice Sprint Backlog negotiations with PO when they have reached the Sprint Goal (temple’s shape), but the time is running out and there are still a few magic gems left in the backlog.
Let’s play 10 Sprints in 2,5h
As you can see, the game rules and mechanics are a ruthless Definition of ‘Done’ and the malicious reality of coding, which forces teams to fail faster and improve on what they have empirically learned. Plans are nothing, but planning is everything.