At the recent Play4Agile 2013 unconference, during the span of 24 hours (which included 7 hours of sleep), I made the alpha playtest version of this game. In this blog post I share the game as it was in the third play test version at 10:30 on monday 25th of February 2013.
My objectives in designing this game are:
- to illustrate the problem of lacking a clear and shared business strategy and having a transparent and shared way to evaluate business value in the context of different needs of different business units when deciding what to build next.
- to illustrate that it is a bad idea to have many projects, or themes, in development at the same time and that this causes unexpected delays to planned deployments.
- to be plausible as a simulation of a conventional software-based product or service company with multiple departments dependent on IT for software and with traditional software development practices.
- to have an engaging and activating simulation that can be played in less than an hour with a small group of business and IT leaders.
By the way, if you want to read more about how I designed this game, I can tell you that I pretty much followed my empirical game design framework. Well, apart from the fact that I got both the learning objectives and the initial concept for my game stuck in my head when trying to take a nap Sunday morning at Play4Agile 2013. I didn’t get any sleep but I got this game instead.
And a big thank you to the playtesters of playtest #3: Kristian Haugaard, Ari-Pekka Lappi, Martin Olesen, Sandra Warmolts and Silvana Wasitova as well as all the playtesters from previous playtests, including, but not limited to (sorry!) Ellen Grove, Henna Ilvonen, Thorsten Kalnin and Peter Moreno. Sorry for not remembering all you guys, please tell me who I missed so I can thank you all for the contributions.
The Product Portfolio Planning Game, Prototype #3
Product Portfolio Planning Game by Antti Kirjavainen is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License. (Clarification: you can use this game as a part of a commercial training or workshop, but I reserve the right to publish this game commercially for myself.)
The game consists of two phases: The product portfolio planning meeting and the software development phase. In the planning meeting the players take the roles of different business department leaders, the CEO and the IT manager and decide which themes to develop in the following months. In the development phase the players play out the development of the selected themes with a kanban board and a simple dice mechanic.
The game is about a company with three business departments: finance, industry and private. It also has an IT department responsible for developing the technical platforms and services the business services the other departments offer their customers. Each business department has its own customers and own products, but technically there are a lot of dependencies between the products of different departments. The power balance between the business department is represented by numbers (the higher, the more power): 10 for finance, 7 for industry and 4 for private.
The players play the heads of the three business department, the IT manager and the CEO of the company. More than five players can play. In that case the additional players represent additional managers from each department.
It is the start of January, 2013. The company has given a budget for the first set of projects for 2013. The money is enough for development of three themes. The constraint is that these three projects have to be started at the same time to save time.
There are a number of restrictions in the development organization and infrastructure: Because of tight coupling between the services, all themes in development have to be acceptance tested and deployed together. The acceptance test phase and the deployment phase both take one month. The development time for each theme is estimated to be about 1,5 months.
At the beginning, you have the following blankets in the wall:
Monthly calendar, with a “Today” post-it on January 2013.
Portfolio-level Development Kanban board
A poster describing the company structure (see backstory above).
The players must give a name to the company. They can also discuss what kind of products or services the company makes (give them a time box of 2 minutes to get started quickly).
Take five playing cards (A, 10, 7, 4 and a joker) from the deck and shuffle them. The players draw them to pick their roles. A for CEO, 10 for finance, 7 for industry, 4 for private and joker for the IT manager.
Give the players their role cards (just post-its with their role written on it) and their theme cards. The theme cards describe what kind of needs they have for development. Here’s a link to the Google Doc with all the theme cards from playtest prototype #3.
The players are now ready to have their first planning meeting.
In planning meeting, the heads of the departments decide what themes to build next. The IT manager has the final say (by the process) to select which themes go into development. The CEO has no process-related role in this meeting, but attends because she likes to stay hands-on with stuff. Needless to say, roles described by process might not reflect what actually happens.
The meeting is role-played. The objective is to put the themes that will be built in the next months in the “To Do” column of the Kanban board. It does not matter how the players come up with decisions.
The time box of planning meeting is five minutes. If the players have nothing in the To Do column in the Kanban board at the end of the time box, they lose a month (proceed to next month). If they have less than required amount of themes (only in first planning meeting), they lose a month. Otherwise, assume that all the themes in “To Do” at the end of the time box is what they planned to build.
After the planning meeting, the players simulate what happens to the themes in development.
In development, certain things happen in each month.
If there are items in To Do column, they are moved into the “In Progress” column and handled straight away as “In Progress” items.
If there are items in “In Progress”, the players must check for complications. Regardless of whether there are complications, the next thing to do is to move to next month and continue with development.
If all the items are in “Ready for AC” or “In AC Test”, they are moved to AC and will be checked for defects. Whether or not there are defects, the next thing to do is to move to next month and continue with development.
If all the items are in “Deploy”, they are moved to “Done”. Then you move to next month and do improvements.
The players roll 2 dice per theme “In Progress”. Pairs mean complications. For each pair, consult below what happens:
1-3 delays (technical risk comes true, unexpected dependency, unclear requirements) No themes progress to “ready for AC” this month OR take one technical debt (purple post-it on the board).
4-5 defect: put one defect on the board.
6 integration work: deployment will take 2 months for this theme (the top one) OR take one technical debt.
Progressing the themes: The top theme “In Progress” will progress to “ready for AC” if there were no delays or if a technical debt was taken for each one.
When there is three or more technical debt, roll 3 dice instead of 2 per theme for complications. When there is six or more technical debt, add one more dice per theme.
Removing technical debt
You can add a “Remove technical debt” theme to “To Do” in a planning meeting. When “Done”, you can remove 2 technical debt.
If there are defects, put one theme (starting from the top one) per defect back to “In Progress”. These will start progressing the same way as before towards another round of AC testing.
In this phase, the players can collaboratively select one improvement item to have completed this month. The improvement items are:
Clear business strategy (will reveal the life cycle phase of products and market and where to concentrate on)
Automated deployment (deployments do not take a month anymore)
ATDD + Continuous Integration (AC does not take a month anymore, defects can be fixed immediately)
Technical Excellence (the players roll 1,5 dice per theme for complications (min. 2))
After that you go on with the subsequent planning meeting.
The subsequent planning meetings
In the subsequent planning meetings you can decide on your own how many themes you want to develop in parallel. Otherwise the procedure is the same.
So, who wins? For this game it is the head(s) of the business department who can get most themes done for his department. The different department get a different number of points per theme: 2 each for finance, 3 each for industry and 5 each for private.
You can tally the points at the end of the game.
Ending the game
At the third playtest there were no end conditions for the game. We stopped playing when we were close to the end of the session.
Evaluation based on the third playtest
The prototype fulfilled the first learning objective. The play testers liked the negotiation in general. Also the backstory was felt as realistic. Another high point for the players were the descriptions of business needs in the theme cards. They were seen as very realistic and of high quality. There are still possibilities for improvement: there need to be more needs coming is as the game progresses and the players would have liked to have even more contrasting agendas.
For the delay side the mechanic kind of provided a right kind of experience too, but was overall much less successful. The situation changed too quickly so that there were no more unexpected delays and work flowed flawlessly through development. This was felt as too painless a shift to better times. Some of the players also felt that the way you got improvements seemed too easy. They would have liked to work to get them and prioritize them against work on business themes. Also they got no defects, which is probably not that realistic.
Most important other finding was that the gameplay in development was pretty close to the GetKanban game. That is a good thing to keep in mind to differentiate this game from that one.
After third playtest it became clear to me that this game has a distinct potential. The biggest decision to make is do I want to keep concentrating on the two learning objectives or do I only take the first one going forward.
If I would proceed with only the first learning objective that would effectively mean that the whole game would concentrate on the Planning meeting part of the game. There would be different kinds of theme cards for different maturity of the product portfolio management framework, so players could compare the experience how different approaches to this problem impact the difficulty of making decisions. It would also be nice to include reflection exercises along playing the game – a list of good questions after every phase would do the trick, I think.
In that version I could address the multiple projects at a time learning objective with another game like the Name Game.
Another option would be to keep the game intact and to polish it concentrating on the mechanics and probabilities of the Development part and the improvement mechanics. The probabilities of rolling for complications need a bit of attention. What’s more, I would need to have a clearer vision about the objective of the improvement mechanic and how to best support that objective.
Anyway, the next step either way seems to be concentrating a bit on the Planning meeting part of the game to make it excellent instead of good.
All in all, I think you can pretty much take the Planning meeting part of the game pretty much as is and use it to illustrate the difficulty of making prioritization decisions in this kind of complex environment with conflicting interests and ambiguous idea of what is valuable.
Please feel free to use it and even improve it, but please also remember to credit me when you do it.