Where we left off

In the introductory Kanban post, I provided some background on Kanban in order to give you some context for how Kanban might be used in an agile software development environment. Now I want to provide some insight on how Kanban is currently being used with agile and why I think the idea of doing so holds some merit.

In Part 1, I mentioned that Kanban and Agile share some basic tenets: improve efficiencies in a non-prescriptive environment where rules are kept to a minimum. I also said that at the very least, incorporating Kanban into an agile environment by combining rules 5 and 6 of Toyota’s Production System (TPS) seemed to make the most sense. In other words, using Kanban as a means for fine tuning in order to stabilize and rationalize the process could bring a lot to the table in an agile software environment.

Let’s take a look at some of the ways it’s been done so far.

How has Kanban been implemented in an agile software environment?

In his article, Kanban Applied to Software Development: from Agile to Lean, Kenji Hiranabe discusses several ways Agile and Kanban have been put into practice, including:

• Agile Kanban
• Sustaining Kanban
• Lean + Agile Kanban
• Portable Agile Kanban

Agile Kanban

Hiranbe equates Agile Kanban to ‘Task Kanban’ in that, like Agile, it doesn’t show processes, such as Development, Testing and Deployment, but instead relies only on visual cues that show the status of a story, such as To Do, Doing and Done. He uses this photo of a Task Kanban implemented by the JUDE development team at Change Vision, Inc. to illustrate:

Sustaining Kanban

Unlike Agile or Task Kanban, Sustaining Kanban has separate and serial processes (Development, Testing, etc.) and the Kanban cards move between those processes from left to right, as shown in this example, a pieced-together image of Yahoo’s Kanban system from Jeff Patton in his article, Kanban Development Oversimplified.

How Yahoo’s Kanban board works:

• The circled numbers along the bottom are the number of stories allowed in the corresponding column.
• The boxed numbers in the left column represent an approximate wait time in days, so items at the bottom will have a slightly longer wait time than those higher up on the board.
• Stories start on the left side and move to the right across the board as they progress through various phases of development. Those in the top row are in progress. As they complete a phase and move to the right, stories below them are moved up.

Although at first glance you might think otherwise, Hiranbe explains, “Sustaining Kanban is not a classic waterfall process, where all the requirements are ‘designed’ at one time, ‘developed’, and ‘validated’ at another time, which would cause all the cards to move in a group. Instead, the cards move one by one, like the one-piece-flow of manufacturing.”

Using the Yahoo example, you can clearly see the “flow of work” concept used in Sustaining Kanban is different from the “iteration” concept of agile. And, in order to be a true ‘pull’ system, rules would need to require that only the next group to the right is allowed to move the cards on the board.

Lean+Agile Kanban

Hiranbe describes Lean+Agile Kanban like using Agile Kanban synchronously within each process and using Sustaining Kanban asynchronously across the whole value stream of processes

Kanban-nano

Patton also found a smaller “portable” Kanban system he in a project being developed by Central Computer Services, Co. At Central, a team works in several smaller sub teams (usually pairs). When a sub-team pulls a user story, they break it down into their tasks and post them onto their own portable Kanban board (in this case, a bulletin board they can carry with them).

In Central’s case, the Kanban system consists of two levels:

• A project level in which a card represents a user story.
• A team (or a pair) level where a card represents a task.

Central uses the term ‘Kanban-nano’ to refer to its agile-Kanban system.

It’s just another way to be agile!

The idea of using a simple task board with index cards or sticky notes is as old as Agile itself.

Even after seeing only a few styles of Kanban in place for agile software development, it’s certainly not a stretch to imagine other variations that could be used in order to create hybrid agile-Kanban systems. One example is Scrumban, fully discussed by Corey Ladas in his 2008 paper, in which he describes Scrumban as “Incrementally enhancing Scrum with more and more pull-like features.” In doing so, Ladas says, flow becomes smoother as process capability improves, providing opportunities for kaizen.

The beauty of the Kanban system: it’s very visual. If logjams occur they’re obvious and action can be taken to address them.

Over time, the process of improving the system is considered ‘smoothing’ or production leveling, and is sometimes referred to in production as “heijunka”. It’s a technique for reducing waste and is an important part of the production efficiency in the TPS and in lean manufacturing in general.

So, at least to this point, you might agree as I said in part 1:

“At the very least, incorporating Kanban into an Agile environment by combining rules 5 and 6 of the TPS seems to make a lot of sense, i.e., using Kanban is a means to fine tuning in order to stabilize and rationalize the process.”

But what are the tradeoffs?

Phew, that’s enough to read for now. In Part 3, I’ll discuss some of the tradeoffs that might occur and if bringing Kanban into an agile environment necessarily means we lose the collaboration between teams with different perspectives, a very important part of product development in my mind.

I’ll also provide some additional resources you can use to find more information on using Kanban in an agile environment.