Agile / IT-Trainings

The Name Game

We recently held an internal workshop to showcase and perfect the games that we use in our Scrum and Kanban trainings. In particular we played How long does it take to write a name?, The Dot Game and The Scrum Game (our version of the XP Game).

I’m a big fan of the HLDITTWAN game, originally popularised by Henrik Kniberg. I use it at the start of Kanban trainings before I’ve even mentioned Kanban. It demonstrates many of the core concepts in Kanban in such a way, that when I actually come to explain Kanban in terms of work in progress or time in progress, people really grasp what is meant.

The game itself is quite simple. Basically the participants are asked how long they think it takes to write a name. Normally they will ask some important questions, such as what materials are available, how big it has to be, how nicely written it has to be. Most groups estimate the time to write a name at around 4 seconds. Now one participant is selected to be the IT department and the rest of the group are customers. It is the IT departments’s job to write names for the customers. Because the IT department wants to keep everyone happy, they decide to work on all names at the same time. So they write the names one letter at a time for each customer, cycling through all the customers. All the customers should be happy, as some progress is being made on writing their name.

In the example below I had two teams competing against each other (the blue team and the green team). Each team had one writer and 4 customers. According to the original estimate, it should take around 16 seconds to write the 4 names. As the results below show, writing 4 names one letter at a time certainly doesn’t take 16 seconds – it took over twice as long – between 38 and 44 seconds!

(I’ve found that when groups already know each other, they often don’t ask how to spell the customer’s name. I get around this problem by handing out names to the customers based on the Irish rugby team. This is particularly effective in Austria! However, it does result in it taking slightly longer to write the names. Also, to avoid a learning effect, you can use different names for the second time through.)

The group should be suitably shocked by how long it took to write all the names. When they look at their original list of circumstances for writing a name, the odds are that multi-tasking wasn’t among them. Given the poor results, IT management decides to implement a new regime whereby only one customer is handled at a time. This results in quite different times for writing the names. Suddenly the average time for a name is reduced – it’s much closer to the original estimate of 4 seconds. The total time is also more than halved.


The first thing that I look at is work in progress. It is easy to see that in the initial set-up, the work in progress is 4, as 4 names are being written in parallel. The second time through only one name is being written at a time and the work in progress is 1. Already the relationship between work in progress and the time it takes to get things done is clear.

The next thing to look at is the average time in progress – i.e. how long does it take on average from start to finish for a given name? It is important to clarify that in the „please everyone equally“ (or make everyone equally unhappy!) scenario, work is considered to start for all names at the same time. In the second scenario, work only begins when the writer accepts the name. The average time for a name is over 30 seconds when work is done in parallel and only 5 seconds when only one name is written at a time. That’s some difference!

Now someone will immediately note, that it took quite a while before the last names were finished. This is true. However, the actual time for the last names wasn’t all the different than for the other names. Implicitly, the names had a lower priority that the other names. If it had been a high priority name, then it could have been done first and would have been finished after 5 seconds. So this game also nicely shows the importance of prioritising work, when the work in progress is limited.

Finally you can also estimate a rate of delivery. In the first case 4 names were delivered in ~36 seconds – or 1 name every 9 seconds or so. In the second example the rate of delivering names was 1 names every 4.5 seconds! The second time through we were twice as fast!

This leads us to the following equation (a variant of Little’s law):

Time in Progress = Work in Progress/Rate of Delivery

Given a constant rate of delivery, the more work in progress there is, the longer it takes to get work done.

So the paradox is that by refusing to take work on, we actually get more work done! Now all you have to do is find a manager who is prepared to tell his customers that he has to refuse their work – so that when he actually does start the work, the customer will have it faster than if he had accepted the work straight away! That’s the hard part of Kanban 😉

Passende Artikel

Ein Kommentar

  1. Ernst Lieber sagt:

    Exzellenter Blogbeitrag. Faszinierend an den „Kanban-Erkenntnissen“ ist, dass jeder von uns diese Alltagserfahrung längst gemacht hat und es nun „Kopfstände“ benötigt, um es den Menschen in die Köpfe zu kriegen.
    Wiewohl dieses bislang namenlose Phänomen zu den universellen Seltsamkeiten des „menschlichen Funktionierens“ gehört (den Wahrheitsgehalt von unbequemen Alltagserfahrungen zu verleugnen). Oder hat es doch schon einen Namen? „Ignoranz“? 🙂