Are you really doing Kanban? Or did you just give up on Scrum?

Toyota developed Kanban in the late 1940s by studying supermarkets.

60 years later, the software industry adapted Kanban by studying Toyota.

My first exposure to Kanban was in a college industrial engineering class, and I was a huge fan. I used Kanban in my first job out of college to optimize a manufacturing process, and I got a promotion because of it. I was an even bigger fan after that (and just a little full of myself).

Years later, now in the software industry, I’m seeing Kanban again. While I’m still a fan, I’ve seen several software teams abandon Scrum in favor of what they believe is Kanban. In reality, many of these teams have just eliminated certain parts of Scrum. They’re left with a process that is unpredictable and doesn’t provide the data necessary to run their business.

Kanban in a Nutshell

Think about a supermarket. The store manager tracks how fast each item sells, and orders only enough of that item to replenish supply when inventory gets low. The restocking process is “pulled” by demand. Too little inventory means shelves will go empty. Too much inventory drives up storage costs and waste in the form of expired and rotting food.

Toyota adapted the supermarket process to make cars. Each process on the car line was a customer of the process upstream, and a supplier to the process downstream. The number of items in each raw material and sub-assembly stack on the car line was given a limit (work-in-process or WIP limit). A “Kanban” (Japanese for “sign board”) was placed in the stack to signal when that item should be re-stocked, and the Kanban was sent upstream to order a new batch. The time it takes for an item to flow thought the process (cycle time) was measured. Based on the data, the process was adjusted and tuned to squeeze out the waste.

Kanban was adapted to improve software development processes in the mid-2000s, most notably by David J. Anderson (http://www.djaa.com/). The idea was to start with the process you are already using, waterfall as an example. You map your process, and each process step becomes a column on a Kanban board. You put tasks or user stories on cards and move them through the columns. You set WIP limits on each column and measure cycle times for the cards to pass through each step and/or the entire process. The WIP limits will expose waste and inefficiencies.

From Scrum to Kanban?

I’ve worked with several teams that said they tried Scrum but switched to Kanban. Before giving up on Scrum entirely, I would ask the following questions.

1. What are the columns on your Kanban board?

In cases of abandoned Scrum, the Kanban board will usually mimic the Scrum storyboard. There are three columns, “To-Do,’ “In-Process,” and “Done.” In other words, the team has abandoned the sprint cadence in favor of a continuous stream of work, often with no estimates.

2. Do you have work-in-process limits?

Kanban relies on WIP limits to expose problems. In the case of “To-Do à In-Process à Done,” there will only be one WIP limit. Without WIP limits, it’s not Kanban.

3. Are you measuring cycle time, and is it useful?

Kanban uses cycle times to measure the efficiency of the process. Cycle time is the WIP divided by the process throughput (10 items / 2 items per day = 5 days).

Unfortunately, cycle time isn’t particularly useful in the case of a converted Scrum board, because user stories or development tasks will vary widely. A text change on a form will take 2 hours, and a new security feature might take 10 days.

4. Are you planning your work?

Even if you’ve eliminated your sprint cadence, planning is still necessary. Without a dedicated time to plan, it’s important to understand how and when this work is going to get done.

5. Are you generating the data you need to run your business (not just your software development process)?

As much as we hate cost estimates and release deadlines, they are usually necessary to run a business. You must have some way to predict when you can deliver features to your customers, and how much you are spending to do so. If you can’t answer these questions, your business is at risk.

6. Why wasn’t Scrum working?

I usually hear variations on the same complaints about Scrum:

• The planning meetings were taking too much time away from development.
• The demos and retrospectives weren’t useful, so we’ve stopped doing them.
• We always carry stories over from sprint-to-sprint, so it made more sense for us to eliminate the sprint boundary.
• Story point estimating doesn’t work for us, so we stopped doing it.
• Morale was dropping due to all of the above.

Scrum, done correctly, should be lightweight. It should maximize the time the team is actually developing software and minimize administrative waste. It should facilitate good organizational habits that produce consistent, high-quality software. Scrum, done correctly, can also generate all of the metrics needed to manage your business.

Kanban is a powerful method to improve and tune an existing process. Scrum is a lightweight software development framework. If you’ve decided that Scrum really won’t work in your situation and you decide to use Kanban, define a process you think will work better and use WIP and cycle time measurements to tune and improve the process. If not, you may end up with chaos.