The Kanban software methodology is gaining adoption, and is often seen as an alternative to Scrum. It is less prescriptive than Scrum, which makes it easier to start using immediately. But from a learning and improving perspective, there’s a hidden value in Kanban. It works in an analogous way to many everyday systems, like supermarket checkouts, carwashes, and restaurants – and because of that, we can improve our software development by using these as metaphors.
My favourite example of a kanban system is related to something close to every developer’s heart: coffee. Specifically, coffee shops. They make an excellent example because they have most of the properties of Kanban and Lean in software, but also because some coffee shops do it really well, while others do it really, really badly.
For the benefit of readers abroad who may not have visited the UK, Costa is a chain of coffee shops which, in my experience at least, has service of… variable quality. Feel free to substitute your own alternative establishment of choice as you read.
What is Kanban, really?
Kanban is about managing queues of work in an economically effective way. That is, given not everything can be done at once, how do we make the process as profitable and healthy as possible? (Tip: pretending everything can be done at once is an excellent way to cause huge queues of work.) When you’re waiting to pay for your shopping at a supermarket, to have your car cleaned in a carwash, or for the waiter to take your order in a restaurant, you’re in a queue. You arrive (randomly), give your order (which is variable) and wait for the work to get processed (which is also variable).
The core stated properties of a Kanban system according to the Kanban methodology (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
I’m going to focus here on visualisation and limiting work in process, as they are the easiest things to see, and are high leverage points for a team new to Kanban. I’ll also look at managing the process, but analogies have to be drawn more carefully here.
Is coffee fuel for work, or the way you work?
When you’re in a hurry, you probably think of a coffee shop like this: you wait to get served, you give your order, you wait for your drinks, you pay, and you leave.
But to think about it in Lean terms, we need a clearer model, one of the whole system. 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.
The flow of coffee
Let’s look at some “real world coffee”, and what happens when the service is good and bad.
First of all you have to turn up at the queue for the counter. Simple. Or is it? How many times have you walked into a coffee shop and seen a long queue moving slowly, while staff were chatting and gossiping, and walked out? How many times have you seen an overloaded counter and wondered which end of the line to join? By comparison, in the software world, how well-defined is the process for clients to request work? Are they seen to quickly, or do they have to wait unduly?
When you get to the counter, you have to place your order. What happens here? Is the order written down, or does the barista remember it in their head? Imagine you place an order for one large mocha with sprinkles, two lattes (one large, one small but with an extra shot of coffee) and a double caramel macchiato. How confident are you that they remembered your order exactly? Mistakes here are expensive, as putting milk in a black coffee means not only do you have to wait for an extra drink, but so does the rest of the queue. Note, though, that the cost of the coffee is irrelevant, but the cost of a lost customer is significant. Being able to confirm the order (and hence quality of service) upfront is of economic benefit.
So having asked for your drinks, your order is now in a queue. It’s in a state of waiting from the point you finish describing the drinks you want, to the point a barista starts making them. How do coffee shops deal with the order? Let’s apply the Kanban principles to explore this.
Is the work visualised?
In software, when we “visualise work”, we often write in on a Post-It note, an index card, or possibly some online system that can create a suitable graphical display. That is, we create tokens, or kanbans. We only do this because otherwise the work would be completely invisible – there are no tangible artefacts in knowledge work. Once work is visualised as a kanban, it can be more easily managed according to Lean principles, such as limiting the number of them being worked on at any given time.
Imagine time was frozen at the moment you completed your order. What would happen to your order if removed that barista from the shop, and resumed time? In Starbucks, every order gets written on a piece of paper, attached to a mug (forming a kanban), and put in a space for unfulfilled orders. My experience in Costa is that the order is usually in the barista’s head. Think about your software team: could you remove a person after they took any client request, and still be confident that the work would (somehow) still get done? Or do you suffer from complaints about work that was promised but forgotten about? Be aware of the limitations of the metaphor here, however, as the work items in software development are incomparably more complex than coffee orders. But next time someone forgets your chocolate sprinkles, ask yourself why.
Often the barista that fulfils an order will be a different one that took it. In Starbucks, this makes no difference, as the order was written down, and anybody can pick it up. (Again, software requirements are too complex for this.) In Costa, I’ve usually seen orders transferred done verbally. (Ironically, software requirements are too complex for this too.) At busy times, the person at the till will shout across the order to the person nearest the coffee machine, possibly while they’re still making the last order. Written down in a consistent way vs shouted to a busy member of staff. Go on, tell me… exactly how well would you expect this to work? Watch the communication. Watch how many orders are repeated. Now think about your office. When did you last see someone call across to an overworked developer, “Bob, can you just …?”
Is the work in process limited?
There’s a gotcha in most coffee shops: the coffee machine is the bottleneck for significant portions of the day. When the shop gets busy, you can usually find staff available to take and deliver orders, but they’ll be backed up waiting to be made. For this reason, if the staff take on too many orders, they just sit around being unfulfilled. What are the consequences of this?
If those drink orders are held in memory, they can degrade, increasing the number of mistakes. These mistakes have to be corrected, which adds more (re)work into the system, compounding the problem. As contention over the coffee machine increases, staff can end up literally stepping on each others' feet. The situation is no different in software (except perhaps for the injured toes) and can create the illusion that more staff are needed. This is a fallacy I analyse in Why You Shouldn’t Hire More Developers.
Is the process managed explicitly?
Tacit policies cause many problems. They increase conflict, as different people will apply different policies to the same problem. They cause unnecessary (bad) variation, as the same problem will be solved in different ways by different people. They cause indecision, as unnecessary thought is applied to routine work; but at the same time they also cause rework (to correct bad variation) as inappropriate policies are applied hastily.
Now, I’ve never worked in either Starbucks or Costa, so I can’t personally vouch for the level of either of their policy management. But I do know that if something is done inconsistently, it’s safe to say there’s either no policy, or no management. If something is done consistently, there’s at the least a culture for that pattern of behaviour. And if something useful is done consistently well, there’s probably a well-managed policy.
Coffee shops are easy to analyse for some sorts of process policy. Drinks preparation is the easiest, as you can observe it directly. Starbucks is meticulous in the way in prepares drinks. My experience of Costa drinks has actually been fairly consistent too. Indie coffee shops usually have a lot more variation. Some make drinks in a very consistent way. There’s one I’ve been to, however, that would serve pretty much any dark brown liquid in anything suitably-sized vessel and call it “coffee”. Variation like this can be very expensive, as customers will drift elsewhere to where they know they will get what they ordered.
In software development we have it much harder, as the work is much more variable. But we can make many valuable things part of an explicit policy. When regular information on the current situation is important, we can institute a policy of daily standup meetings. When avoiding putting the team in a state of constant overwork is important, we can limit the amount of work in process by some rule(s). When keeping software in a deployable state is important, we can have a policy that the continuous integration server must be running and always be green.
There’s one Starbucks policy I began to infer which I’ll draw attention to, as it sparked a long discussion between me and a friend. When a large queue of potential customers starts to form in front of the till, and there’s a bottleneck at the coffee machine, the last barista will not leave the till and go to make drinks. Instead, they call further down the line to collect more orders, even though they can’t be served, and therefore means customers have to wait a long time for their drinks. Why do they do this? I believe what they are intending to do is known in Theory of Constraints terms as exploiting the market, as the ultimate constraint on a coffee shop is not the staff or machines, it’s how many customers walk through the door. Starbucks has an explicitly managed, reliable process for creating a flow of drinks, which makes full use of the coffee machine bottleneck without overloading the staff. They know that no matter how many orders are taken, they will all be made in a timely, accurate manner. Starbucks has this level of process capability. They know where the constraints are in their business, they know how to exploit them, and they know how to manage the flow of work through them. Do you?
Summary
Throughout this article I’ve given a lot of examples based on my experience in Costa. This may give an unfair bias, as in fairness, the service in most chain coffee shops I’ve been to sucks. Usually it’s not from lack of effort or care from the staff either: they simply don’t know any better, and their managers don’t teach them. (Nor do the managers know any better, and their managers don’t teach them either – I can only assume this goes all the way up to the top.)
Software teams are full of motivated, independent-thinking individuals, who take enough pride in their work that they fight against a system that hinders them. On that basis, even though the work is a lot more demanding, I believe software can provide a much better service than coffee shops. But along the way, we can learn a lot from the way they are run.
The purpose of this article is to give you a metaphor for software development that you can study in real life and in real time. Take a trip to a coffee shop, to many if possible, and watch how they operate. Study the behaviour of customers in the queues, on the way the process is managed, on how failure is handled. Try to find where the principles of coffee shop flow apply to software, and where they don’t.
The real question is: Do you want your development team to be a Starbucks or a Costa?
Further reading
To be able to analyse any sort of process, you need to understand the rules of the game you’re playing. When you understand the rules, you can learn how they interact, and how they form a cohesive system. By far the best reference for the rules of software development (and all sorts of product development) is The Principles of Product Development Flow by Don Reinertsen. It’s not a beginner’s book, being quite technical in some places. But if you want to further your understanding of software development processes, you owe it to yourself to read this. (This is not an affiliate link.)
Thanks for reading
My name is Ash Moran. I’m a software developer and agile coach, and owner of PatchSpace Ltd (Twitter). If you have any feedback, questions, or would like to know more about my services, feel free to contact me at ash.moran@patchspace.co.uk, or continue the discussion in the comments.