Stay Updated: Posts | Comments   Follow us on Twitter

Name: Erwin

Web Site:

Posts by :

    The Blame Game

    October 27th, 2012

    This is a game to let people experience the effects of different punishments/rewards systems have on the way a team works together. One team will be ‘The Team’ which is rewarded and punished on a team level and ‘The Individuals’ have a mix of team and individual rewards and punishments.

    Timing: 20-45 minutes
    Materials: Deck of Cards, rules instructions, paper/pen to keep track of scores
    Divide the groups in 2 groups. Ideally around 4-7 people per group. Explain people that the point of the game is to build one or more houses of cards.

    The 2 groups are going to have slightly different rules. One team will be rewarded and punished on a team level and the others will be rewarded individually.
    Whenever I talk about a section in the rest of the rules I mean either the 2 cards standing up ( /\ ) or the card covering it ( — )

    The ‘Team’ scores as follows:
    2 pts for every section they add to the house. This is multiplied by the layer they have added it to. So on the second layer they get 4 points. On the third layer they get 6 points.
    -10 pts for every time the house (partly) collapses.

    The ‘Individuals’ score as follows:
    1 pt for every section added to the house, multiplied by the level for the individual
    1 pt for every section added to the house, multiplied by the level for the team
    In the event of a (partial) collapse the person whose turn it is gets -8 points. And he can shift the blame by choosing someone else to also receive -2 points.

    Both teams are also required to keep track of how many sections at what level they add and how many times the house collapsed.
    It is also possible for a person to pass and not attempt to add any more cards.

    The reason to give them their printed instructions and not explain it in public is that you do not want the teams to know they are playing by 2 different rules.
    Give them 5 minutes to build houses. As soon as one collapses they can keep going and start over.

    After the 5 minutes are up, ignore the scores and gather the statistics on the amount of sections added and total number of collapses.
    Then do a debriefing to gather experiences and see what was different between the 2 teams.

    If there is time do a round with both groups on the team score for some friendly competition.

    Learning Points:

    What usually happens is that The Individuals will be competing against each other. They are probably more risk-averse and look to blame strategically. After someone has a high enough score they sometimes sit back and pass instead of taking the risk of losing their lead.
    The Team on the other hand is working together. They are figuring out the way to place cards, help each other place them and warn when they see something going on.
    Compare this with how bonuses and blame is usually distributed in their organisation.

    Special thanks to the people in my PLAID workshop at the AgileHolland Agile Games Night who came up with the problem and the resulting brainstorm and the volunteers at Agile Coach Camp Denmark for being guinea-pigs.

    VN:F [1.9.16_1159]
    Rate This
    Rating: 4.8/5 (4 votes cast)


    Agile Airplanes

    July 28th, 2011

    John Heintz, from Gist Labs, has just released his Agile Airplane Game at

    It is a game in which multiple teams have to coordinate to fold certain quantities of different airplanes that meet certain acceptance criteria (like being able to fly :) ). John has made a nice matrix on what aspects of agile are covered by this game:

    Read the rest of this entry “

    VN:F [1.9.16_1159]
    Rate This
    Rating: 4.5/5 (6 votes cast)


    The Big Payoff

    July 3rd, 2011

    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 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)
    * Pen
    * Sissor

    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.

    Learning points


    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.

    • Work out the projects/constraints/events to optimize the chances for difficult decisions
    • People are confused about the 2 colors projects
    • I am going to try names of animals next, with fishes for waterfall projects and cats for agile projects
    • How to get people emotionally involved/attached to the current plan.
    • It is now too easy to completely change a project that has not started yet.
    • Fixed events vs random ones
    • Fixed events make it possible to prepare carefully prepared traps.
    • Random events make it clear for the players that unpredictable ‘shit happens’
    • Figure out what to do with projects that go over the 12th quarter
    VN:F [1.9.16_1159]
    Rate This
    Rating: 4.2/5 (5 votes cast)



Discuss Comments
Agile Games Group