The Kanban Coffee Shop

The principles of a Kanban, as defined in David Anderson’s Kanban, are:

• Visualise work
• Limit work in process
• Measure and manage flow
• Make process policies explicit
• Use models to recognise improvement opportunities

Kanban barristas

A couple of weeks ago, our team found out how similar a Kanban software team can be to a coffee shop. The guys from Agility in Mind did a great exercise with us where we were suddenly morphed from a development team into a group of (comically terrible) barristas.
 
They set up stations around the room for:

• Customer orders
• Coffee shots
• Milk/foam

With a few constraints in place, we were then set to work on creating a flow for customer orders. Feedback from our coaches was that it was an incredibly painful thing to watch.  

In the first round, orders came in very fast, which rapidly overwhelmed the coffee shot station, creating a backlog. By the time the orders got to the "customer", 75% of them were wrong!

Rather than listening to the customer (who was literally standing in the corner calling out "Hellllooo??"), we instead gathered together to see how we could improve.

We added Quality Assurance as the final step in the process, and we flowed a bit more smoothly the second time around. Again, we ignored the customer's entreaties.

Finally, we gathered together and proposed a radical change: rather than handing the coffee cup from station to station, we would travel with the cup until it was complete. With this change, people went from specialists to very confused generalists, which resulted in the longest round of drinks with very poor quality for the customer. Epic fail!

Comparison of barrista work to software development

In the end, we learned a bit more about creating an efficient flow, as well as the major lesson of listening to our customer.

Ash Moran at Patchspace explains it well...

What happens from the coffee shop’s point of view is this:

• You, the customer, arrive at the customer queue, and you do so randomly (at this point, you wait)
• A barista takes your order, a list of random drinks – that is a batch of work to be done, of variable size, complexity and value
• Your order goes in a queue (at this point, not only are you waiting, but so are the drinks)
• One or more baristas make your drinks, that is, the batch of work gets processed (you’re still waiting)
• A barista hands you your order, that is, the completed batch of work

Before we go on, just reflect how similar this is to software:

• The client / business turns up with a “new idea”
• The client describes some work they want you to do (which will be of variable size, complexity and value)
• You put the request in your backlog
• At some point, one or more developers become free and turn the request into working code (which will take a variable amount of time)
• You deploy the software/deliver the code, etc

So if you can accept that an index card describing the new feature “View product listings by category” is more or less the same as an empty coffee cup waiting for a drink, the two processes become coherent.

What are your experiences with a shift from scrum to Kanban? Any ideas on how to create a more efficient flow of work?