The Big Payoff is a portfolio game invented by Alexandre Boutin (@agilex) and Erwin van der Koogh (@evanderkoogh) at the Agile Games Conference 2011 in Boston during the ‘Design your own game’ track by Don McGreal (@donmcgreal) and Michael McCullough (@mccm68) of Tastycupcake.org fame. It has won ‘Most Creative Game’ at that conference.
The game is designed to give people a taste of what it is like to manage a portfolio in an agile organisation. The learning objectives are:
1) Show how much better Agile projects are for portfolio management
2) Show the advantage of planning with stable teams
Please note that this is a fairly complicated game and that it needs a bunch of iterations to properly tweak it. At the end of the post is a list of things we still think need some improving. Please help us improve by sharing your experiences with the game.
* Explain: 10m
* Play: 45-60m
* Debrief: 10m
* Big piece of paper (like flipover, ideally with grid)
* Bunch of paper (2 different colors)
We need 1 board with materials for every 3-5 participants.
On the big paper make a big table with horizontally 4 teams and verticially 12 quarters. Make sure the cells are big enough, about 5x5cm
This is going to be the planning board. Now we need to make some projects. We do this by making strips of paper. The length of the paper is the length of the project and on it we put a number. The number represents the value of the project when it is completed.
The ratio that we will be using during this game is value/quarter. So pick an average value/quarter and create a bunch of projects with value above and below that average. Use one color for agile projects and another for waterfall projects.
Be sure to include some very juicy waterfall projects with a high value/quarter, we are going to mess with them later
Make an overview of the projects and their value/quarter.
Next are some constraints. Dependencies between projects, projects that need to be finished before a certain time or can’t be started before a certain quarter. Or can only be done by a certain team.
The whole point is to give them a big puzzle where they have to optimize the projects to score as many points as possible in the next 3 years.
Next up are the event cards. Of course nothing is going to go according to plan. So be creative and make up some events. High value projects with very tight deadlines, halving the value of big waterfall projects, CEO pet projects with no or little value that have to be completed, projects taking longer etc etc.
Explaining the game
When explaining the game do not tell participants about the events. Keep those events to yourself. Just present the board, the projects and the constraints. In fact, do not even tell them about Agile and waterfall projects. Or about value/quarter.
Explain that, except for constraints, all projects can be done by all teams.
Playing the game
Leave the players with the puzzle. It will usually take them about 20-25 minutes to figure out the best configuration. During this someone will have figured out value/quarter. Once they do give them the value/quarter sheet. That is going to save them quite some time.
Once they are happy with the configuration and look at you to tally the results walk to a board, write down Q1, and write down their total for Q1, which is most likely 0. Then grab the event cards and pick one.
Give them a couple of minutes to change the plan with this new information and then tell them the difference between agile and waterfall projects. Agile projects can be divided for the value/quarter rounded down. So an 18 value Agile project taking 4 quarters can be divided into 4/9/13/18 points. This is to represent that they are delivering value throughout.
Keep going for 4-8 quarters or until time runs out, but leave about 10 minutes for the de-briefing.
Go over the game and see what people have learned. People will most likely have realized the risk of waterfall projects, how easy it is to be able to cut up Agile projects and realize partial business value. Explain that the game is a bit oversimplefied (all teams can do all projects for example), but this can work without much alteration in real life.
And that there’s a lot more ‘shit’ happening in RL than the game.
Things to tweak
As mentioned before this game is still in a beta phase. There are quite a few variables that still need tweaking. This is a list of stuff that doesn’t quite work as we want it to. If you have any suggestions to improve these or other areas, please drop us a line or comment below.