Commentary on The Art of Agile Development's Iteration Planning practice.

In the last few years, Kanban Systems have become an increasingly hot topic in the Agile community, thanks in part to the Poppendiecks' wonderful introduction of Lean Manufacturing principles. Three people who have been working on Kanban systems in the Agile space are David Anderson, Arlo Belshee (video), and Kenji Hiranabe.

Despite the interest, I haven't seen any good overviews of Kanban systems. In this essay, I'll try to fill the gap. I'll describe what Kanban systems are, why they work, and when you should use them.

Kanban Described

Kanban systems are an approach to scheduling work. Typical Agile projects use time-boxed iterations. At the beginning of the iteration, the team meets and chooses stories from their backlog that can be done by the end of the iteration. Over the course of the iteration, they develop those stories, and at the end of the iteration, they ship them.

Kanban systems are different. Instead of using time-boxed iterations, Kanban systems focus on a continuous flow of work. The team takes a story from the backlog, develops it, and ships it as soon as it is done. Then they take the next story from the backlog, develop it, and ship that story. Work is shipped as soon as it's ready, and the team only works on one story at a time.

That's the ideal, anyway. Approaches differ. My favorite approach is based on Arlo Belshee's, and that's what I'll describe here. (Arlo, with his usual flair for names, calls it "Naked Planning.")

MMFs and the Backlog Queue

The primary work unit for the team is the "minimum marketable feature," or MMF. An MMF is the smallest feature that has value to the market. As Arlo puts it, MMFs are "the smallest features we can sell."

The team maintains a backlog of MMFs in a queue. This queue is strictly limited in size. Arlo allows seven MMFs in his backlog; I usually prefer two or three. A small backlog is good because it limits the amount of time an MMF can wait, which prevents them from getting stale.

The team only works on the top MMF in the queue. Stakeholders can add, remove, and move the other MMFs in the queue as much as they want, so long as they don't exceed the queue's size limit.

Work in Progress

The team works on the top MMF in the backlog queue until it's done. They use simultaneous phases, so there's only three classifications: waiting, in progress, and done. MMFs are either in production ("done"), at the top of the backlog queue ("in progress"), or waiting.

The use of simultaneous phases is probably the biggest difference between Arlo's approach and David Anderson's. David Anderson doesn't use simultaneous phases, so his MMF-equivalents have to travel through multiple stages: Engineering Ready Queue, Systems Analysis, Development, Build, Test, Release Ready, and In Production. This means that his team works on multiple MMFs at a time, which leads to a need for complex configuration management, and I'm sure it lengthens his cycle time.

The team brainstorms and tracks the tasks required to complete the current MMF only. As tasks are completed, they're removed from the board; as new tasks are discovered, they're added. When all the tasks are done, either the MMF is done or the team has forgotten something.

Once the MMF is done and the on-site customers have approved it, the software is released. The MMF is taken off the queue and development starts on the next MMF.

Tracking and Estimating

There's no estimating of tasks or MMFs in this approach. Instead, you use what Arlo calls "Disney Line Planning": "Your wait from this point will be XXX days." In other words, you measure the typical time it takes to complete an MMF, from start to finish, and extrapolate to various points in the queue. Since MMFs can vary in size, this is a rough projection, not a commitment.

MMFs and tasks are tracked on index cards stuck to a large whiteboard. You could use an electronic tool if you wished, but for a colocated team, I recommend the low-tech approach. A big whiteboard is constantly visible and encourages discussion and collaboration in a way a computer can't.

Urgent Work

If there's an emergency, a support request, or some other urgent need, there's an empty slot on the board marked "Urgent." The team can put an MMF in that slot at any time without having to go through the regular backlog queue. The team strives to finish urgent items quickly, and they try to keep the slot empty and available at all times.

If the "Urgent" slot is full and another urgent item appears, it has to be added to the backlog queue.

Bugs

As with other Agile approaches, the team is expected to fix bugs before the MMF is done. If bugs are found afterwards, the fixes are scheduled with a new MMF. If a bug needs to be fixed immediately, the team uses the "Urgent" slot.

Understanding Kanban

The name "Kanban" is really a misnomer. "Kanban" means "sign" in Japanese. In Toyota's Kanban system, when a station on the manufacturing line ran out of inventory, they would place a sign in an empty box and send it up the line to indicate that they needed more inventory.

But despite the name, the sign is not the most important part of the Kanban system. What Toyota was really trying to accomplish was "one-piece flow." One-piece flow means manufacturing items one at a time rather than in batches. It creates flexibility, improves productivity, eliminates waste, increases throughput, cuts time to market, reduces the impact of error, and reduces the cost of inventory. It's a Good Thing.

Kanban is a hack around the limitations of the physical world.

In manufacturing, one-piece flow is hard to achieve. Sometimes efficency requires that you build up inventory, like when you truck items from one location to another. Kanban is a hack around this limitation. It's a way of controlling the amount of inventory in the system. But the ideal is still one-piece flow: working on just one item at a time, with no inventory waiting. Lean coaches will actually remove Kanban cards to shake things up and spark further improvement to the system. As Jeffrey Liker says in The Toyota Way (emphasis his):

...TPS experts get very impatient and even irritated when they hear people rave and focus on kanban as if it is the Toyota Production System. Kanban is a fascinating concept and it is fun to watch... When is the kanban triggered? How are the quantities calculated? What do you do if a kanban gets lost? But that is not the point... The challenge is to develop a learning organization that will find ways to reduce the number of kanban and thereby reduce and finally eliminate the inventory buffer... So kanban is something you strive to get rid of, not to be proud of.

So when you hear "Kanban System," don't think of little cards pulling work from upstream stations. The ideal of the Kanban system is to eliminate inventory and achieve one-piece flow. And in software, we can. We aren't subject to the same physical limitations that a manufacturing plant is.

That's why I prefer Arlo's approach to David Anderson's. By using the Extreme Programming approach of simultaneous phases, everyone on the team works on one MMF and gets it to done, then they work on the next. Work-in-progress inventory is reduced to the absolute, bare minimum: just one MMF. (Beat that, Toyota!) By doing this, we create flexibility, improve productivity, eliminate waste, increase throughput, and do all of the other wonderful things that one-piece flow gets you.

When to Use a Kanban System

I like the idea of Kanban systems, but I'm not sure they're appropriate for everyone. This might just be unfamiliarity: I have a lot more experience with the old-fashioned iteration-based approach.

The good thing about Kanban systems is that they really do a great job of eliminating waste. They eliminate iteration planning, they react extremely well to changing needs, and they work well in chaotic environments. The theory behind them is sound, and if you are a fan of Lean ideas, then using a Kanban system will seem like a no-brainer.

On the flip-side, one of the biggest problems I see with agile teams is "Agile thrashing." In Agile thrashing, the team flails about, making progress on a lot of disparate ideas, but never really creating anything significant. I worry that Kanban systems, with their limited backlog, will exacerbate this problem.

I'm also concerned that Kanban will be too advanced for teams new to Agile planning. One of the great things about iterations is that they're timeboxed. At the end of the week (or month), time's up! You're done. Many teams struggle with this. They have trouble getting to "done done" and the timebox helps them recognize and eventually fix the problem. Timeboxes also prevent scope creep and they also force important trade-off decisions to be made. Overall, they're an excellent tool for improving the team's self-discipline, and Kanban systems don't seem like they'll provide those benefits.

In the field, I've seen Kanban work best in chaotic environments where upcoming features don't have much in common. I don't think it's a coincidence that the initial examples of Kanban come from those sorts of environments. David Anderson's team was responding to change requests. Arlo Belshee's team worked in a start-up, where frequent, entrepreneurial shifts in direction are commonplace. One team I worked with used a Kanban system to respond to post-release change requests, but plans to switch back to iterations once they start planning their next release.

So, should your team use iterations or a Kanban system? Here's my criteria:

• If your team is new to Agile planning, use iterations. Be super-disciplined about getting everything "done done" each iteration, using slack, and achieving a stable velocity so you can consistently make and meet iteration commitments. This will force your team to learn important lessons about how Agile works.

• If you're producing a new product or a significant new release of an existing product, use iterations. Create a vision, do release planning, get a good product manager, and make sure he's heavily involved. Your goal is to create a compelling product with significant value, and you'll benefit from a gestalt view of the product and the predictability iterations provide.

• If you're in an environment where the feature backlog is constantly in flux or hard to predict, particularly if you can release the software on a whim, try the Kanban system. Entrepreneurial environments, maintenance of mature products, and recent releases are all examples of environments with unpredictable backlogs. The Kanban system will convert that chaos into a smooth, constant flow.

And if none of these categories seem to fit, go ahead and give the Kanban approach a try. You'll learn something new and hopefully have fun doing it. There's a lot of potential here, and I don't think we've explored all of the options. Try it! Let us know how it works out.