I am working on some ideas to help people understand the importance of having diverse operating styles in a team and working with people whose strengths complement your own weaknesses.
I run a lot of courses around agile project management and one of the most common questions I get is “What are the most common issues to watch out for when going agile, what should we focus on to make the transition successful”.
So I came up with a simple card game that highlights the constraints that hold teams back and the early practices they can focus on to be successful.
There are now three versions of my agile release planning game so I thought I would add them to the site so people can download them directly:
The original version
The basic game covers release planning and also the challenge of planning for new features, fixing defects and being impacted by technical debt. It works well when leading discussions about velocity charts, replanning and technical debt.
It is set on Mars and involves the team planning how to survive or leave Mars. The version attached contains additional complexity around having the team set clear priorities (survive, continue with a scientific mission or work on leaving). But some people prefer to ignore the scientific goals of the project to simplify the game, in which case they tell the team to focus only on surviving. The components are:
An older version of the game had events the impact the team as well as defects and stories. Generally I have ignored the events so I have removed them from the following folder. So the following folder contains stories and defects … although you may find that the status report is all you need to track defects: ARPG Story Cards and events v1.1
The iteration planning / Kanban extension
The following version can be played on its own (though you will need to read the facilitators guide above and use the story cards). Alternatively it can complement the game above if you use it to replay a couple of the iterations in the orginal game.
It is designed to focus on storywalls and resource allocation during the iteration. The team allocate people to different stages of story development (effectively – elaboration, build and test/deploy). Then, during the life of the iteration they encounter bottlenecks and re-assign people to provide better flow through the team.
Debriefing this extension can lead to great conversations about “activity versus throughput” and the potential issue of testers sitting idle for a week and then being flat out for a week (and hence becomming a bottleneck).
The lost alphabet extension
The latest addition to the family comes from Brazil and was created by Eduardo Meira Peres.
Eduardo has created a simplified version that can be explained and played quicker than the original. He has also changed the problem the team face. They no longer have to survive on Mars, but instead they must work with a tribe here on earth who have lost their alphabet.
The intriguing problem that the team must now solve is to use an agile process to help the team re-invent the alphabet from scratch.
I believe this extension is available in both Portugese and English, though I have only provided the english version here:
Please feel free to use any of these versions – and let me know how you go.
We set up a stand at the recent Software Development Conference to run the Agile Release Planning Game I designed.
It seemed to go down really well, so I have decided to make the game available publicly if anyone is interested in using it.
In the game, participants are a group of scientists and engineers who are stuck on Mars after a “less than successful” landing. They are on a mission to make scientific discoveries but must now rebuild a basic infrastructure for survival before returning to their original mission.
Participants then create a strategy based on rebuilding their ship, building a base and/or returning to their basic goal of research. In doing so they must make trade-offs between quality and velocity.
The game introduces concepts such as release planning, iteration planning, velocity, release planning trade-offs, building by feature and adaptive planning.
The game is designed to be led by a facilitator, but can be run without one. The release planning game takes around half an hour to play and can be replayed multiple times to explore different concepts in more detail or to improve the outcome based on lessons learned in the first attempt.
Different options allow the game to be played as a very simple introduction to the concepts of release planning or a more complex game involving more realistic trade-offs and decision making under conditions of uncertainty and pressure.
In addition, there is an extension included in the game that focuses on planning within the iteration (or sprint) rather than across the wider release.
Let me know if you are interested in learning more, or even trying the game for yourself.