Kanban et Agile

The primary mechanism in Kanban software development for improving the flow of work is the Work-in-Process Limit. You basically set a policy for the team, saying that we’ll limit how much work is started, but not finished, at any one time. When the board starts to fill up with too much unfinished work, team members redirect their attention and collaborate to help get some of the work finished before starting new work.

How does this fit in with my Agile processes?

Agile, Scrum and Kanban methods for project management focus on iterative delivery. Teams work in two-to-four-week “sprints” to deliver a small batch of User Stories (each a small part of the desired end product). Teams then get that one small batch of stories completely finished by the end of the sprint.

When one sprint comes to an end, you demonstrate the new features to the customer and then plan the work for the next sprint.

On a Kanban board, you visualize the flow of work. You can visualize how the work is flowing during the sprint through the very fast iterations of design, develop, and test that happen within each sprint. Or, you can let the flow of work be governed by the Kanban board and replace the sprint container with a regular deployment cadence instead. It’s a minor difference on the surface, but it can have a major impact.

With the sprint approach, you spend time at the beginning of every sprint trying to estimate and plan a batch of work for the entire sprint. Then you work on it and push hard to have the entire batch completed, tested and deployed by the end of the sprint.

When you’re focusing on flow and using Kanban, you could still deploy completed code every two weeks. But instead of going through the whole cycle of planning, estimating and moving a batch of work through to completion, you can move work through the system without batching two weeks of work at a time.

Planning and estimating, designing, building and testing can happen for each individual item as it reaches the top of the priority list in the backlog. When there’s capacity on the Kanban board for more work (WIP limits are being honored, and people are available to do more work), they pull the next item to work on.

When the two-week cadence comes around, you simply deliver whatever is ready to deliver. This encourages members of the team to take each item all the way through to completion individually, instead of focusing on having a two-week batch of work completed at one time. You ensure that each item is Done. With a capital D. “Done-Done”, some people call it. And you get it to “Done-Done” before pulling the next item available for you to work on.

The Agile practice of iterative delivery is a huge improvement over old waterfall or stage gate project management methods.

Focusing on Agile process flow using Kanban can sometimes be even more efficient, resulting in shorter lead times and higher productivity. It can lessen the feeling of always “starting and stopping” without abandoning the value of having a regular cadence to work toward.

Does this mean that you’d be abandoning Scrum for Kanban, or abandoning Agile for Kanban? No. Agile and Scrum are both about much more than the sprint. Besides, if you throw out the existing process, be it Scrum, waterfall, or anything else, you’ve got no starting point for your Kanban system. Kanban itself is a process improvement approach, not a process of its own. It’s something you apply to an existing process, like Scrum, or whatever your current process happens to be.

Eh, not really. When considering Agile vs. Kanban, there are fundamental differences between the two.

The ideas behind Kanban come from the world of Lean Manufacturing as a way of doing something called “Just-in-Time” production. It was developed by Toyota (Kanban is Japanese for “Visual Card”) in the 1950s.

Further development of the ideas for using Kanban for knowledge work (like software development) was done by David Anderson, Jim Benson, Corey Ladas, Alan Shalloway, Karl Scotland, Alison Vale, David Joyce, and a sizeable community of people interested in applying principles from the world of Lean to software development, DevOps, and other kinds of Knowledge work, beginning around 2007. While Agile is still growing and adapting, most of the ideas we associate with Agile had begun to solidify long before Kanban came around. So, including Kanban as part of Agile muddies the waters a bit.

Agile process flow was developed primarily by software developers to define better ways of developing and delivering software. See the Agile Manifesto.

Kanban and the Lean principle of Flow aren’t specific to how we develop software. The flow system works very well for that, but it turns out it also works well in places where Agile’s iterative delivery model has struggled: IT Operations for example, or software teams focused on churning out small bug fixes and enhancements to existing production systems, where the flow principle produces a ton of value.

For some environments, it just isn’t practical to batch up work in two week chunks. The need, for some teams, to respond in real time to a constant stream of incoming requests, makes selecting a batch of them to work on only every two weeks pretty impractical.

For that matter, the principles of Kanban software development can work equally well for just about any kind of work:

• Creating marketing campaigns
• Event planning
• Contract negotiation
• Legal project management
• Inventory management

….and many more. Since Kanban doesn’t start by assuming anything about your process or what you’re doing, it can be applied to anything that has a process. It can be as simple a process as ‘To-Do, Doing, Done,’ or something far more complex.

What kind of work couldn’t benefit from better visibility? What kind of work couldn’t benefit from focusing on getting more work finished instead of starting more new work, whenever you get the chance?

So, without abandoning any of the good stuff in Agile, Scrum, Extreme Programming, and without abandoning any of the good stuff about your current process that is already working well for you, you can apply Kanban to it to get better visibility, and apply Kanban tools to help you improve the flow of work.