Die Card Die – An Interruption Game is a card and dice game for teaching the impact of interruptions on iterations. This game was created as part of the “Agile Game Incubator” session at Agile 2012.

 

Die Card DieCreated By: Todd Charron, Richard Cheng, Cynthia Eng-Dinsel, Sophie Manton, Stacy McDonald, Judith Mills, J Paul Daigle, and David Parker.

Timing: About an hour

Materials: 1 deck of playing cards, 1 six-sided die. Optional: Tape, and sticky notes to create board.

Players: 4-10

Instructions:

In this game, the 52 cards represent the overall scope of the project. The goal is to deliver all 52 cards. You deliver cards by matching all 4 cards of each face value.

You play the game twice. The first time with no interruptions, the second time with interruptions.

Game 1:

In 3 minute Sprints –
Each player plays one card from their hand one at a time into an “In progress” section on the table and then rolls a die, disregarding the result of the roll. When all four suits of a particular card are “in progress” that feature is now complete and can be moved to a “Done” section on the table. Continue until the 3 minutes are up.

At the end of the sprint, record the total number of completed cards. Cards in progress can carry over in the in-progress for the next sprint. Continue Sprinting with remaining cards up all 52 are delivered.

Game 2 –

Do the same as in game one, except if the roll is a 6, move all work in progress to the discard pile and do not play any cards that match the faces in the discard pile. These cards can no longer be used this iteration (they have been removed from the iteration as a result of the interruption). If in mid-sprint you run out of playable cards, then you can pull cards from the discard pile.

At the end of the 3 minutes record the number of features completed. Cards in progress can carry over in the in-progress for the next sprint. Cards discarded are re-allocated back to the players. Continue Sprinting with remaining cards until all 52 are delivered.

Debrief:
The concept is that when a 6 comes up the work is progress in the current iteration has been de-prioritized or put on hold in favour of an emergency interruption.

The first time the game is played, the players will finish or just about finish delivering all 52 cards. The second time it is played, it will take many sprints, probably 3-5.

Learnings:
The value of limiting work in progress (players will try to focus on getting something done before it gets interrupted).
The impact of interruptions on overall delivery time (fewer features delivered, takes more iterations to get the same number of features out the door).
The cost of technical debt from features that get shelved for awhile.
The value of working together to help get things to done sooner.

 

19 thoughts on “Die Card Die – The Interruption Game

  1. I love the game! Very much thanks to Todd Charron and the other inventors. It generates a great insight that disruptions do cost a lot and therefore should be minimized. As some disruptions are hard to avoid, the team will experience that agile approaches can reduce the negative impact of disruptions.

    I experimented with some variations and found these to be useful:

    I usually play three rounds/games + a little theory inbetween:
    – Round/Game 1: As described – no interruptions
    – Round/Game 2: As described – interruptions when dice shows 6.
    – Intermediate: Ask the team which agile practices they know that could be applied.
    Usually the team comes up with: Sprint Planning, splitting stories, pair programming, limit WiP etc.).
    Ask them how they could use these consequently on the card game.
    – Round/Game 3: As round 2 – but now they are allowed to adapt the agile practices
    (i.e. story splitting, sprint planning –> exchanging cards within team, team work/mob programming)

    Round 3 usually gives them the experience that this “agile stuff” really helps. Although the number of disruptions isn´t much different to round 2 – they will get their stuff done in less sprints – and much less frustration and stress.

    In addition to that I change the “backlog” a little bit – already starting with round 1.
    There are two high-prio-super-important-top stories. These two have the major business value.
    Without these stories there is no product! (Be a little dramatic on that, if you like to.)
    – Story 1: All aces and kings (8 cards)
    – Story 2: All queens and jacks (8 cards)

    They will not be able to deliver these two stories with the highest business value in round 2.
    That´s frustrating and a good point to talk about why to do different stuff although the top-stories are not done. In Round 3 they will be allowed (if they ask for it) to split up these stories in two stories of four cards each. Also they will be allowed to split up the other stories (2 cards per story, i.e. both black 7 = 1 story).

    Looking forward for your comments on that.

  2. Paul D, in your 3/21/13 entry, you created some really nice twists on the game. Please clarify what happens in game 1, when all four face types are in progress, and there is no blocking involved from rolling the die. If I don’t have a card to match any of the four face types in the In Progress lane, do I have to add a card to the “Blocked” lane, or do I just pass my turn? Does the “Blocked” lane only fill up with games 2 and 3?

  3. Side note…

    I’m working on a much more involved overall “Agile Game” that will go from Product Vision through to building product in iterations. I extracted concepts from it and created a game where you need 3 decks of cards. One deck (along with dice) detemined the “story points” a card will take. Another deck has teh amount of work accomplished and some blockers that can appear. a part of the 3rd deck is used to remove blockers (though some cards will not remove the blockers).

    I call it FLIPS for Focus, Limiting WIP, Impediment Removal, Prioritization, and Splitting. It shows how all of these concepts are important considerations in iterative development.

    I’ve run it a few times with other coaches and they really like it. It is a lengthy game (about an hour and a half and the lessons begin to sink in); it’s intended to allow one to Train from the Back of the Room. I plan to take it with me to Agile Games New England this year (incidentally another earlier game of mine got accepted to present, so excited to be going!) to show it others and allow them to use it as well. FLIPS has a ton of dimensions to it… The reason I mention it here is it has some similarities to this game, but is much more involved. (I also did a lot of math to investigate how it could work best for those teaching moments.)
    Once I do a bit more play-testing, I’ll probably post it here.

  4. @Todd – The reason I decided to explicitly limit work in progress was to increase the cost of the interruption and force the team to think about removing blockers. With no limit of the number of faces in play, I was concerned that teams would just keep adding WIP and moving cards stacks into “done” without worrying about blocked cards. On the other hand, that would ultimately result in a lot of work that never got done, which would be a lesson in itself.

    Another possibility is not to limit the WIP stack, but play the game cumulatively… that is, do one iteration with no blocking rolls, one with one, one with two, but keep blocked cards blocked between I-2 and I-3. I’ve played it that way with a small group and 3 two minute iterations.

    One thing is that running the “blocker” variations described sort of changes the game–it becomes more about general blockers than about interruptions. It’s still an effective game but it doesn’t focus as strongly on the main lesson of “don’t interrupt your developers”.

  5. @Paul – Interesting variation! I like it! What do you think would have happened if you hadn’t explicitly limited work in progress in round 2?

    @Peter – You’re right, that sentence makes no sense. I took a stab at updating it. Let me know if it’s any clearer. Thanks!

  6. Hi,
    I don’t understand the following sentence. I have re-read it few times and it still doesn’t make sense to me. My are possible corrections but I was not sure.

    Debrief:
    The concept is when a 6 comes up, it represents that the work is progress is a re-prioritization has come up in mid sprint that has made the current WIP less important and other items in the backlog more important.

  7. I tried this game with a group of scrum masters in India this week, with some variations. The rules we followed were:

    The board:
    The team has a “board” consisting of three lanes: In Progress, Blocked, and Done

    The goal of the game is to move all cards from “In Progress” to “Done” in the fewest number of iterations.

    Turns:
    On a turn, the player may either play a card into “In Progress” or remove a card from “Blocked”

    Players take turns counterclockwise.

    Playing a Card: To play a card, the player puts the card in the “In Progress” lane, either in an empty space or on top of a card of the same face, and then rolls a die. If the die causes the card to become blocked, the card just played is moved to the “Blocked” lane.

    Only four faces can be “In Progress” at a time.
    When all four cards of a face are “In Progress”, that face is “Done” and the cards move to “Done”, freeing up a space in the “In Progress” lane.

    Removing a Blocked Card: To move a “Blocked” card into their hand, a player rolls the die. If the roll is not a blocking roll, then the player can move a card from the “Blocked” lane into their hand.

    Iterations: Each iteration is three minutes long. At the end of the iteration, each player may “unblock” a single card and move it into their hand.

    Blocking rolls: We play the game three times. In game one, no value blocks a card. In game two, a six is a blocking value, in game three, a roll of either 3 or 6 blocks.

    ————

    So the main changes are the addition of the third game, the limit on the number of faces that can be in progress, and the ability to remove blockers.

    The team I was working with took a bunch of ideas out of this game. One was the importance of resolving blockers, and the importance on focused work. In game three, they tended to focus on a single face until it was done and keep the blocked lane as clear as they could. In game one, they just played sort of at random and finished very quickly.

    They noticed that the more there were blockers, the more they had to communicate and strategize, so they took away the importance of communication.

    All in all, it was a much richer session than I anticipated, and moved far past just “interrupted work” and into their entire workflow!

  8. Hi Haowei,

    From my perspective, it works more on rework that has to be done because you’ve shelved a feature. Either you’ve forgotten where you were and have to get up to speed again, or the code base around the feature has changed since the shelved feature was originally started and as a result you need to adjust the code or in some cases re-do it completely.

    I wouldn’t use this game purely for the purposes of demonstrating the costs of technical debt though.

  9. I could not see how this game can teach “The cost of technical debt from features that get shelved for awhile”. That said i am yet to play it 🙂

  10. I just had another thought about this game, which if you get a chance to test it out, please try.

    My hypothesis is that if the number of people playing (team size) increases, so will the work in progress (due to the lack of concentration in card ownership) and that this will result in interruptions causing more waste and poorer performance. This also seems to match what I see in real teams as well. Perhaps this is another side-benefit this game can teach us.

  11. I’m teach two classes this week and I’m going try the game in both classes. Excited about trying our new game.

  12. Richard, sorry for the name typo. I’ve updated the game using your description, thanks!

    Paul, interesting variation. I’m hoping to try this game out in the future and perhaps I’ll try it both ways and see what works better. Let me know your results if you try it as well. We can compare notes and see what works better.

    Thanks!

  13. One other idea is that while the name Die Card Die (or in German, The Card The) is awesome, I was thinking the “52 Card Project Game” may be a better description.

  14. Yup, it’s Richard Cheng.

    Paul, you are correct, it’s 4 of the same face.

    I also suggest the following update to the game description:

    In this game, the 52 cards represent the overall scope of the project. The goal is to deliver all 52 cards. You deliver cards by matching all 4 cards of each face value.

    You play the game twice. The first time with no interruptions, the second time with interruptions.

    Game 1:

    In 3 minute Sprints –
    Each player plays one card from their hand one at a time into an “In progress” section on the table and then rolls a die, disregarding the result of the roll. When all four suits of a particular card are “in progress” that feature is now complete and can be moved to a “Done” section on the table. Continue until the 3 minutes are up.

    At the end of the sprint, record the total number of completed cards. Cards in progress can carry over in the in-progress for the next sprint. Continue Sprinting with remaining cards up all 52 are delivered.

    Game 2 –

    Do the same as in game one, except if the roll is a 6, move all work in progress to the discard pile and do not play any cards that match the faces in the discard pile. These cards can no longer be used this iteration (they have been removed from the iteration as a result of the interruption). If in mid-sprint you run out of playable cards, then you can pull cards from the discard pile.

    At the end of the 3 minutes record the number of features completed. Cards in progress can carry over in the in-progress for the next sprint. Cards discarded are re-allocated back to the players. Continue Sprinting with remaining cards until all 52 are delivered.

    Debrief:
    The concept is when a 6 comes up, it represents that the work is progress is a re-prioritization has come up in mid sprint that has made the current WIP less important and other items in the backlog more important.

    The first time the game is played, the players will finish or just about finish delivering all 52 cards. The second time it is played, it will take many sprints, probably 3-5.

    Learnings:
    The value of limiting work in progress (players will try to focus on getting something done before it gets interrupted).
    The impact of interruptions on overall delivery time (fewer features delivered, takes more iterations to get the same number of features out the door).
    The cost of technical debt from features that get shelved for awhile.
    The value of working together to help get things to done sooner.

  15. Actually another thought…

    The manner in which you are treating the interruption is really simulating rework more. May I suggest that you pull out only 1 card from the closest being complete feature to go to the discard stack. So if there are 3 cards, you’d yank one from there; for ties, it doesn’t matter which one you choose.

    The reason for this recommended change is that it maintains the item as a work in progress. It also means this unfinished WIP is a distraction to those items you are still trying to complete.

    let me know what you think of this improvement.

    Cheers,
    Paul

  16. Great game idea! I have a couple of minor corrections for you…

    First, simply because I saw him tweet about it yesterday, it’s Richard Cheng as a contributor.

    And you mean 4 of the same face card, not suit (i.e. 4 10’s 4 Kings, etc.). The suits are clubs, hearts, diamonds, and spades.

    Just thought you’d want those clarifications.

    Paul

Comments are closed.