Two exercises, one puzzle

Today Benjamin Mitchell played a small exercise I really liked during his Kanban talk.

Benjamin gave each of two people 5 A4 envelopes and 5 pieces of paper. The two people were given instructions to either write a letter sequentially, or to do it in batches.

The sequential person had to put the paper in the envelope, write their address on the front then mark an “X” for a stamp. They had to do this 5 times.

The batch person had to do each of those steps in turn; filling in 5 envelopes, writing 5 addresses and “putting on” 5 stamps.

Now, I remember another exercise which teaches us that multi-tasking is bad. If we’re asked to write all the letters of the alphabet as capitals, then write them all as small letters, then write the numbers from 1 to 26, we do this much more easily by doing the whole of one job than we do by switching between them. It’s very hard to write, “A, a, 1, B, b, 2” – much harder than it is to just write “ABCDEF…” etc. It gets even nastier if we write roman numerals too!

For that reason, I predicted that the batch job would finish more quickly. It’s not like software development, where we do different things. It should be even simpler than writing a sequence. It’s the same thing, five times.

Yet the person working sequentially – doing each letter in turn – finished a long time before the other person. The addresses looked about the same length, and the sequential worker had written his far more neatly, too! Benjamin’s reaction told us that this was pretty standard for the exercise – he expected this.

Why? What was it about this exercise that meant the person writing each letter in turn went so much faster than the one filling the letters, then writing the addresses, then the stamps?

I have a couple of ideas, but I’m curious to see what the community thinks! I’ll write the most interesting answers in an edit here… as well as the most outrageous ones. Let me know in comments, and if you try it yourself I’d love to know the results.

Edit: I said I’d write the most interesting answers here, but too many of them are interesting. I do particularly like this breakdown of the game, via Graham Lee.

Don Reinertsen’s explanation of transaction costs is also helpful:

I am a big proponent of reducing batch size, but the viability of small batches ultimately depends on transaction costs. If you ran the game with the envelopes, the letters, the writing desk, and the stamps each in separate corners of the room, or in different buildings, you would undoubtedly get a very different outcome. Reducing transaction costs enables the payoff brought by small batches.

Thank you all for your illuminating answers!

This entry was posted in kanban. Bookmark the permalink.

22 Responses to Two exercises, one puzzle

  1. Gene Hughson says:

    Two things that I can see potentially causing this: time spent shuffling between the letters is increased when you work in batch mode, batch mode seems a bit more monotonous (which would explain the quality difference as well).

  2. Martin Burns says:

    No definitive single bullet, but some thoughts:

    1) The task switching cost is small relative to the tasks, unlike in deep technical work where a task switch can cost 20 minutes (per research). So the batch-v-switch factor advantage isn’t as great as you’d expect.

    2) If you timed the individual activities, I’d suspect that the difference is in the writing. Handwriting – for our generation – is hard to do in a sustainable way. The breaks help by providing rest/variation periods to the hand muscles.

  3. liz says:

    https://twitter.com/eComSOASocMed/status/302450766742958080 – “Multitasking in this instance had far less handoffs.” Nice observation!

  4. Perryn Fowler says:

    The batch person has more WIP. They have to go through the stack of envelopes 3 times and they have to keep track of the state of 5 envelopes, 5 addresses, and 5 stamps at any one time. The sequential person takes and envelope, deals with it, and moves to the next. They go through the stack once and only deal with one of each thing at any time.

  5. Martin Burns says:

    Taking a step on from there, that’s why people object to 1 piece flow over batching: they think (sometimes correctly) that the transactional costs of switching outweigh the rapid value delivery of flow.

    The answer of course is to reduce the transactional costs to enable smaller more frequent batches on a journey towards 1 piece flow.

    Batches (Iterations/Sprints) > single delivery (Waterfall)
    Small frequent batches > large infrequent ones
    Decreasing batch size tends towards single piece flow.
    Agile tooling & methods (CI, auto-build/deploy, automated testing, rapid error feedback loops etc) enable the journey towards 1 piece flow, by errorproofing and reducing the pain threshold of release/deploy.

    And that was my first insight from about 2008 confirming (for me anyway) that being Agile is to be on a Lean journey.

  6. Ivan Sanchez says:

    This example seems very similar to this one: http://www.youtube.com/watch?v=Bi9R1Hqr8dI

    Maybe it’s worth noticing that the multitasking way is not only faster (less wait and moving batches around between each step), but reduces inventory and waste between steps (imagine they figure out they are filling the envelope “wrong” at the end of the first batch), and means the first “final product” will be ready way earlier than doing by batches.


    Ivan

  7. Darren says:

    I’m not sure that exercise counts as multitasking – there’s not much data in-flight that the person needs to keep in their short-term memory. My initial thought was that the person doing it in batches would spend more time going up and down the line than the person doing each in turn. It’s a good demo of time & motion in action.

    The alphabet example is true because we all learn the alphabet that way – as soon as you start recalling a,b,c your memory has probably handed you the rest of the alphabet without being asked, quite possibly with the song you sang to learn the letters at nursery attached as well!

  8. Helge Nowak says:

    agree to the other commenters especially Perryn Fowler’s observations. The human brain is good at pattern matching. It can spot patterns of activity and will not break them up into small steps for batching. Rather it optimizes at the higher granularity to get the best “return on investment” i. e. quality per effort. Context switches increase the effort and reduce the quality.

  9. Jason Yip says:

    Search for “lean envelope stuffing”. Classic wastes kick in here.

  10. Giso says:

    Agree with Darren (#8). In sequential mode there’s no multi-tasking involved. Writing the letter, putting it in the envelope, writing the address and putting on the stamp is a sequence of actions that we learned so well that it is in fact like the sequence of actions required to write the alphabet. Splitting the sequence into its parts creates work that is unfamiliar to us and therefore requires more concentration. Also with batch mode there’s much more material cluttering up our working place, while in the sequential mode you can put each finished letter somewhere where it’s out of sight (at least that’s what I do when I have to do this kind of thing).

  11. Eric Weilnau says:

    I think the difference would be due to what we mentally identify as a single task since the cost of multitasking comes from context switching. I believe that most people would consider stuffing, addressing, and stamping an envelope a single task. So the person switching between the 5 envelopes is incurring the cost of context switching.

  12. Jeff Lucas says:

    Perhaps the results can be explained by tacit knowledge. In the “multitask” mode, you allowed the subjects to perform the tasks repetatively in a “natural” order. As a result, they were able to complete it in a pattern that was inherently familiar to them. If the order of completion was randomized each time, the batch subjects may have fared better (since the randomness of the order would have much less effect).

  13. Eric Willeke says:

    Perhaps there’s a framing gap? The person who has to do five addresses, five stamps, then five notes is actually doing the multitasking… multitasking between “Writing five letters”. I find context switching quite easy if I’m not moving across goals. Isn’t that the core idea of TDD? Rapidly moving back and forth from two different aspects of contributing to the same goal does’t seem to be multitasking.

  14. Steve Fenton says:

    I’m not sure either the sequential or batch example actually equate to multi-tasking or context-switching in this case. The person is doing one thing at a time but is either organising similar activities in sequence or not.

    Measuring the complete time of these activities either in sequence or in batch is possibly more indicative of issues with boredom, hand-writing speed, muscle fatigue and other such issues rather than of mult-tasking vs non-multi-tasking.

    The real measurement in this experiment would be that in the sequential example the first envelope is completed much faster than the first envelope in the batch example – i.e. once the folding, writing and stamping of one complete envelope is done rather than when the folding or five letters and writing of five envelopes and the addition of one stamp is done.

    If you increase the number of letters, the first is complete in the same time no matter the size of the job in the sequential example. In the batch example, the first is complete later and later in the process.

  15. AlSki says:

    It’s a very interesting result, but I’d be interested to know also if the inputs to the process skewed the result? Did Ben hand out a stack of 5 envelopes, a stack of 5 letters etc, or was it five piles each containing letter + envelope+ pen + etc? I certainly am guilty of defining my interim data structures to fit a process, so I wonder if the individuals had an opportunity to prepare and optimise their input data ready to best fit their process? Maybe the individuals in the experiment’s preconceptions of not pre-optimising skewed the result?

    Even so it still feels like a contrast between two sequential processes. I wonder if this exercise could be repeated by scaling up to true multitasking? i.e. having team A with maybe 5 people, one filling the envelope, the next 3 writing the address (1/3 each?), another on the stamp, and comparing with 5 people, one per pipeline?

  16. John Goodson says:

    Sequential worker does less material handling then the batch worker. Also the outcome is what Little’s Law predicts; remember here is reality and smacked dab up against it is LIttle’s Law, ain’t nothing closer.

  17. Lance Walton says:

    I agree with Darren’s comments.

    We need to be really careful when we talk about multi-tasking. Our brains are massively parallel devices that pull the clever trick of presenting their work as a linear sequence to our conscious brains.

    What we’re really talking about in these examples is time-slicing, and you can train to become better at this with specific sets of tasks because you can learn to treat the time-sliced activities as one larger scale activity. Any example that shows an untrained subject attempting (and failing) to time-slice and then concludes that time-slicing is therefore bad, is not a great example.

    If you want an example of multi-tasking and degraded performance, try something that causes interference between the tasks, like writing addresses on envelopes and reciting a nursery rhyme or someone trying to write down the names of coloured cards that someone else holds up while the card holder also calls out other colour names as they hold the cards up. What tends to happen initially is that we try to convert the multi-tasking problem into a time-slicing problem, which of course causes degraded performance. However, we can acquire the necessary skill to do this. It always used to amaze me to watch my mother playing really hard pieces of music on the piano or organ whilst carrying on a conversation with people with no stutter in either the music or the conversation.

    If you want to see good human examples of both time-slicing and multi-tasking going on, watch a concert pianist.

    Having said all of that… as a programmer, if you want me to solve a problem, don’t keep interrupting me to ask how it’s going.

  18. For completenes, I have already played the other game mentioned, multiple times with the same results (aka the sequence finishes earlier)

  19. I’m not sure why the sequential work finished first, but I can guess that the batch worker’s addresses became messier towards the end out of a mixture of two forces: boredom and a desire to go fast. You have felt this effect if you’ve have had to sign or initial 20 times in quick succession; after the first few times, the novelty of signing or initialing wears off, you want the job over with, so your signature/initials lose their distinctive details and start to look more like straight lines and simple curves. Often, the boredom leads to wanting to get it over with sooner and not caring about the quality of the results.

  20. Don Reinertsen says:

    I am a big proponent of reducing batch size, but the viability of small batches ultimately depends on transaction costs. If you ran the game with the envelopes, the letters, the writing desk, and the stamps each in separate corners of the room, or in different buildings, you would undoubtedly get a very different outcome. Reducing transaction costs enables the payoff brought by small batches.

  21. Paul Klipp says:

    Regardless of who finished all of the letters first, it’s obvious who would finish the first letter first. This exercise also serves as a nice illustration of continuous value delivery vs. keeping busy.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s