Tower defence is a group of games, where enemies wave by wave attack your home trying to destroy it. To defend it, you place towers that shoot near enemies. Usually there are multiple types of towers and multiple types of enemies – each enemy is vulnerable to a specific type of tower. You need to plan towers carefully and mix tower types, to be able to destroy each enemy before he hits your home. Here I will present how to adapt this concept and use it during retrospective.
First define a topic of the retrospective. One of my recent examples is how to reach the Sprint Goal, as we failed in achieving the last one and we wanted to be better next time. Our game was named Sprint Goal Tower Defence Game – Sprint Goal was our home and we wanted to defend it from enemies.
There are three stages of Tower defence retro:
1. Create enemies.
2. Create towers.
3. Play the game and destroy as many enemies as you can.
Create enemies
Create enemies stage is focused on creation of as many enemies as you can. You can use any idea you want, one of the techniques which provide good results is anti-problem approach (https://gamestorming.com/the-anti-problem/). In my case we asked ourselves a question – what should we do to be sure that we fail the next Sprint Goal?
Be creative and accept all ideas – from giving up with good practices to intentional sabotage. Do not communicate with stakeholders, stop doing refinements, resign from code review practices, spend 4 hours on coffee breaks each day of the sprint, accept all requirement changes without blinking an eye, stop testing, underestimate stories, intentionally create bugs – all are good enemies. List all of them and group in one place.
Create towers
The second stage, create towers, is focused on creating as many towers as you can. Each participant should create his own towers and should not share them with others yet. Each tower should be able to destroy at least one of the enemies and help to defend your home (in my case, help to reach the Sprint Goal). Examples of towers are – follow code review practices, do more refinements, start testing early, do pair programming, test work in progress, actively ask for stakeholders’ feedback, eat vitamins. Towers can be things that you already apply in everyday work, but also new ones – behaviours, actions, circumstances which you would like to have or follow.
Play!
Now you are ready for the final stage – you prepared all the game’s elements, so it is time to have battle. It is very easy to have here both deep discussions and fun. Do not waste this opportunity!
One by one, every enemy attacks your home – you or other team member can select which enemy goes now. To defend against the enemy, team members may claim that they have a tower destroying it. If so, he/she should say it out loud and place the tower close to the enemies. As an example, the enemy underestimate stories may be destroyed by more refinements tower or look into code during refinements. Enemy accept all requirement changes may be destroyed by tower create and estimate separate improvement for all requirement changes during Sprint.
There can be more than one tower used against every enemy and already present towers may also be used. All together you decide whether the enemy is destroyed or not. If the enemy was not destroyed, mark it – this is a real problem to which currently you do not have any working solution.
Conclusions
At the end of the game, aside of fun and discussions you should have:
- List of all problems, obstacles, impediments which attack you home. Some of them will be marked as currently impossible to defend from – those are great topics for further workshops or inspiration for organizational changes.
- List of all towers which help you defend your home. Some of them will be new ones – those are improvements which you would like to introduce.
Should you have any feedback about this format of retro, please share it in comments!