Showing posts with label games. Show all posts
Showing posts with label games. Show all posts

my kanban 1's board game

Here's a slide deck explaining the essence of my kanban 1s board game. Jon Jaggers Kanban 1s Board Game
  • You can play an early session with no clips so the players can see how inventory builds up (you can also push done story-cards to the next edge's corner, rather than waiting for them to be pulled).
  • The clips that hold the story-cards are a crucial part of the game. They make it a kanban game.
  • You can limit the number of clips per edge to create a natural work-in-progress (wip) limit.
  • You can add a new rule: players can also spend a 1 to split a story-card in two, eg a 4 into a 3 and a 1 (assuming they have a spare clip).
  • You can record the day a story-card comes off the backlog, and also the day it gets to done and thus measure the cycle time.
  • You can simulate scrum-style discrete sprints.
  • You can vary the number of dice at different edges.


Bordeaux kanban 1's game

Philippe Launay is an Agile team lead and Coach for AGFA in France.

Phillipe recently organized a Kanban 1's game in Bordeaux after he and Fabrice Aimetti translated the slide-deck into French.

Way to go Phillipe.



Phillipe gave me some great feedback
  • printed handouts of the rules on each table.
  • instead of story-cards with numbers on why not have story-card with dots on. Instead of a 4 have 4 dots.
He writes:

We really had some fun and we learned a lot. The feedback is very very positive... All attendees, the two observers, and the two organizers are more than satisfied with the result. So again thank you to for providing the game.

It's my pleasure Phillipe. And in case any else is wondering, please feel free to translate the Kanban 1's Game slide-deck if you want to. Just send me an email and I'll collect links in this blog.

My Kanban 1s Game

Update! I've now created a Kanban Board Game around this idea.

Here's the latest slide-deck for my kanban 1s game. Based on feedback from several recent sessions I've changed two features:
  • Backlog It now costs 1 unit of work to create a backlog item. Also a worker on any table can create a backlog item at any time.
  • Bugs There's now a much simpler way of simulating bugs - simply lose all the current work on the story-card.
Jon Jagger's Kanban 1s Game

kanban 1's game

NB: Heres a more recent slide-deck

I ran my Kanban 1's Game as an open space session at both the xpday conference and also at the Lean, Agile eXchange conference. It proved quite popular so here is how to play it if you're interested. Kanban1sGameRules

Some notes on new game variations/updates

Thank you to Kevlin Henney and Liz Keogh who helped to improve the game.

Slow motion velocity/wip game

I've noticed when teams play the velocity/wip game they tend to focus a lot of their energy on learning how to throw their dice faster. Learning to throw faster means you'll throw more 1's during your 1 minute iteration but that isn't really the point of the game. It also means that comparisons of velocity between different iterations are misleading.

Thinking about this today I suddenly thought of a two simple ways to improve the effectiveness of the velocity/wip game...
  • Instead of having a 1 minute iteration have a fixed number of rolls per iteration. Eleven say.
  • Do each roll in slow-motion. After each player rolls their dice, count up the 1's then slowly and calmly discuss how to play those 1's on the current board. Then make the play. Then repeat.
I tried it today (hi Michelle, Lee, Brian, Kenny, Marty, Jarlath, Gerard, Tony, and Charlie) and the difference was startling. Instead of trying to increase their velocity, the team worked on learning to play the game better. So much so that they actually forgot to measure their velocity!

Winner or loser?

As well as running an evening CyberDojo at the NDC 2010 conference in Oslo last week I also attended an excellent morning workshop run by Matthias Skarin. He used several experiential exercises one of which was a simple rally-car driving simulation. In the game everyone stands in a circle and has to choose "Hi" or "Lo". Then you find out what the person to your left and to your right chose and look up your score. For example, Left=Hi, Me=Lo, Right=Lo, check the sheet, Hi-Lo-Lo = 2 points. Then repeat 15 times, each time adding your points to your running total, and rearranging the circle lowest-score to highest-score, slowest driver to fastest driver.

The points table was cleverly structured so there was a tension between working for yourself or for the whole circle. After a few rounds I had an idea. I decided to play the game by trying to maximise the score of the person to my left even if it meant coming last. I have to admit part of the reason for this was I was only half awake, (I hadn't had enough coffee), and figured I wasn't going to do very well anyway. Each round I simply explained what I was doing to the person to my left and asked whether they would like me to pick a Hi or a Lo.. The effect was dramatic - I rapidly became the slowest car as people overtook me. And because we were standing in a circle, in no time at all, the person to my left was the fastest car. Then there was another dramatic effect - since the person to my left was gaining a significant advantage from me each round they rapidly accelerated ahead of the second placed car. At the end of the game two cars had noticeable scores; mine because it was so low, and Paul's (the person to my left) because it was so high.

Afterwards someone pointed out that I had been the driver of the slowest car. I explained how I had played the game and suggested that maybe I had been the navigator in the fastest car!?

The velocity/wip game

While I was at Jerry Weinberg's Problem Solving Leadership workshop last week (which was truly fantastic) I showed a group of fellow attendees a very simple velocity/wip game I've invented. You simply create some cards and arrange them into columns. Each card has a number written on it which is it's estimate. The photo shows the setup for our game; the left column (eg Analysis) contained the numbers 1,8,2; the middle column (eg Design) contained the numbers 1,1,5; the right column (eg Testing) contained the numbers 8,1,2. We put one person on each column; Darrin on analysis, Ted on Design, and Tim on Testing. Play proceeds as follows:
  • each player gets N (eg 3) dice which they each roll over and over again
  • if a player rolls a 1 they add one to their running tally (which starts at zero)
  • if their tally reaches a number on a card in their column they can move that card one column to the right and reduce their tally by that number
  • that's it! (you can also add wip limits to the columns if you like)
Paul was on the timer and gave us one minute. After the minute was up we added up the...
  • work-in-progress: the total of the cards still in the three columns
  • velocity: the total of the cards that got moved out of the rightmost column (into an extra rightmost column called Done)

The first minute

The wip was 25 and the velocity was 11. This makes a total of 36 which is greater than the total we started with. This is because there is also an extra left-most column called Backlog which contains more numbered cards. Darrin was on the left Analysis column and after moving all three of his cards into Ted's middle Design column he pulled some more work into his column from the Backlog. Despite this Ted was starved of work for part of the minute.

The second minute

We reset the board back to it's initial position and decided to try and increase the velocity by smoothing the work. We split the high cards into multiple smaller cards. For example, the 8 was split into 3,3,2. Then we did another minute's worth of work. This time the wip was 18 and the velocity was 18. Once again this makes a total of 36 and once again Darrin pulled in more work from the Backlog after emptying his Analysis column. Because the work was less lumpy Ted wasn't starved and the velocity went up.

The third minute

We reset the board back to it's initial position from the second minute. This time we decided to try and lower the work-in-progress left over at the end. After all, if the project got canceled that wip would be waste. To do this we agreed not to introduce any new work from the backlog, and also that anyone's dice could contribute to the tally on anyone's column. Then we did another minute's worth of work. This time the wip was 9 and the velocity was 20.

Summary

Simply by smoothing the work and working together we increased velocity by a factor of ~2 (11 to 20) and reduced the wip by a factor of ~3 (25 to 9). Simple!

Henrik Kniberg's name game

Update: Henrik has now written a detailed explanation of how he plays the game here.

Henrik designed the name game to show how the lean idea of limiting work in progress can have a dramatic effect. Here's how you play:
Split into groups of six. In each group there are 5 customers and 1 developer. Each customer has a project - they simply want the developer to write down their name. That's it. During both iterations the following times have to be recorded (to the second):
  1. the overall start time
  2. the time each customer's project starts (when the developer writes down the first letter of their name)
  3. the time each customer's project is delivered (when the developer writes down the last letter of their name)
  4. the overall finish time

In the first iteration each developer has to act under the principle of "never keep a customer waiting" and tries to write all the names simultaneously. Let's see how a developer's name-sheet changes during this iteration. It starts off empty:
1.        2.        3.        4.        5.
the developer asks their first customer for the first letter of their name and writes it down; the first customer's project has started so they write down their project's start time:
1.B       2.        3.        4.        5.
the developer asks their second customer for the first letter of their name and writes it down; the second customer's project has started so they write down their project's start time:
1.B       2.E       3.        4.        5.
the developer carries on until they have written down the first letter of all their customers names; every customer will have written down their project's start time:
1.B       2.E       3.P       4.T       5.J
the developer asks their first customer for the second letter of their name and writes it down; if this completes the customer's name the customer's project is delivered and the customer writes down their project's finish time (Be will become Bert so not yet):
1.Be      2.E       3.P       4.T       5.J
the developer asks their second customer for the second letter of their name and writes it down; again, if this completes the customer's name the customer writes down their project's finish time (El will become Ellie so not yet):
1.Be      2.El      3.P       4.T       5.J
the developer carries on until they have written down the second letter of every customer; Jo is Jo so Jo's project is delivered and Jo writes down her project's finish time:
1.Be      2.El      3.Pa      4.Te      5.Jo
the developer carries on round-robin, letter by letter, until they have written down the full name of all their customers; every customer now has a project finish time:
1.Bert    2.Ellie   3.Pat     4.Terry   5.Jo
Stop the clock and record the overall finish time.

Now the developers swap customers (so they don't know their customer's names once more).

In the second iteration the developers act under the principle of "limit work in progress to 1 customer at a time". So no multi-tasking. Let's see how a developer's name-sheet changes during this iteration. It starts off empty:
1.        2.        3.        4.        5.
the developer asks their first customer for their whole name and writes it down. When the developer starts writing their name the customer writes down their project's start time, when the developer finishes writing their name the customer writes down their project's finish time.
1.Sally   2.        3.        4.        5.
the developer asks their second customer for their whole name and writes it down. Again, the second customer writes down their project's start and finish time.
1.Sally   2.Russ    3.        4.        5.
the developer continues round-robin asking each customer in turn their full name. All customers now have a project start and finish time.
1.Sally   2.Russ    3.Ed      4.Larry   5.Clive
Henrik writes:

Then we chart the results and compare and discuss. Typically the lead time per customer is at least 5x shorter in the second round, and the total time to do all customers is 3x shorter (so the developer could handle 3x more customers within the same time, and each customer only needs to be engaged in the project for 5x shorter time than before). Most people intuitively believe that, if you start something earlier, you will finish earlier. This exercise brutally murders that misconception :o) A simple exercise, but the effect is astounding.


If you like software-related games you might also like

The name game

When I'm training/coaching a group of people I often haven't met any of them before and sometimes they haven't met each other either. So one of the first things we all have to do is get to know each others names. It can be boring and painful asking each person to briefly introduce themselves so here's an alternative...

Instead, announce that you want everyone to write their name on a flipchart (or whiteboard) and that you're going to time how long it takes. Your mobile phone probably has stopwatch feature (if not just count out loud). Then just say "go" and start the stopwatch. Some people will be puzzled and just sit there doing nothing for a while, but eventually everyone will realize you really mean it! When they've finished and sat down again tell them how long it took, comment on the illegibility of their writing, prepare a new sheet of paper on the flipchart (or wipe the whiteboard), and ask them to do it again making it clear that this time you want it done faster. And legibly! You have to be able to read the names! Say "go" again and restart the stopwatch.

You can easily and quickly repeat this up to ten times. You can allow a little retrospective time between iterations if you like. You can insist that the names are drawn in a way that bears some relation to where they're actually sitting. The variations are endless. The ingenuity shown by the groups when I've run this is often remarkable. They easily get the time down from about 2 minutes to a few seconds. I've also found it works very well if you rerun the exercise every morning (perhaps after hiding most of the pens ;-)

Quite by chance I've learned that my friend Henrik Kniberg has been using peoples names as the theme for a similar group exercise.