Kanban is a widely used method for process management, scheduling, and transition management with deep roots in Lean. As early as 2007, a group of software developers – David Anderson, Jim Benson, Corey Ladas, Darren Davis, and others – applied kanban to the process of software development, calling it Kanban for Software Engineering.

Since then, Kanban has evolved into different streams based on the different experiences of companies and consultants. There has not been a single entity driving a common message (as there was for Scrum with the Scrum Alliance). Today, there are at least three distinct views of what Kanban for software development is. This has created a certain amount of confusion. The views are:

• Kanban is merely a method to manage workflow (Corey Ladas)
• Kanban is a thought process and a subset of Lean thinking and should be used in conjunction with other Lean-Agile approaches (Al Shalloway, Karl Scotland, others)
• Kanban is a branded approach to help transition organizations to different practices by using a system to pull work (David Anderson, Lean Kanban University company)

This blog attempts to address some of the confusion about Kanban. It is based on conversations I have had with many customers as they try to sort out whether and how Kanban can help them as they try to become more lean and agile at scale. It is also based on a talk I gave at the Agile 2013 conference, De-Mystifying Kanban: Understanding Its Many Faces.

And for more about this topic, please see Extending the Kanban Method and Why We Need a New Meaning/Name for Kanban.

Clearing Some of the Confusion

I am a great proponent of Kanban for software development. We have seen it be very helpful for many of our customers over the years. I want to see it used whenever it is appropriate.

Below are several issues where there has been confusion about Kanban for software development.

Team structure: Still important with Kanban

Whether one uses Scrum or a flavor of Kanban, teams are important. Software development is involves teams and team structure can have a great impact on effectiveness. Ignoring team structure or letting it just evolve is wasteful and potentially harmful. Please see Cross-functional teams eliminate waste and manifest Lean.

Kanban, Scrum, and SAFe^TM: They complement each other

Kanban, Scrum and the Scaled Agile Framework (SAFe) are three major approaches or frameworks being proposed for software development. They all attempt to help the enterprise become more Lean and agile. Which should you choose? Maybe all of them! The good news is that they can support each other very nicely. This is because they all have roots in Lean.

• I have long said that Scrum is a manifestation of Lean. Good implementations of Scrum incorporate Lean thinking. Poor implementations, sometimes called “ScrumBut”, fail to take this into account. For example, see The Five Whys of Lean as an Answer to the But of Scrum.
• Kanban, as I said earlier, has deep roots in Lean tracing back to Taiichi Ohno. It works because of Lean.
• As shown in Understanding the Scaled Agile Framework, SAFe can be considered a manifestation of Lean.

The point is the approach doesn’t matter. What matters is are you delivering more business value? Scrum, Kanban, and SAFe should help you deliver business value or not be used at all. Use Lean thinking to use the right approaches to fit your context.

Which comes first: “doing things right” or “doing the right thing first”? Answer: Yes

Net Objectives has been doing large scale Agile for almost a decade. To work at scale, teams must know that they are doing the right things, the things that the Business prioritizes as giving the most value, and they must deliver product that does what it is supposed to do, defect free and per specification.

One of the classic problems we have seen is that teams are overloaded. Overload can be caused by many factors such as not having the Business side properly engaged, having too many projects, not using minimum Business increments (working on building and delivering the most important business value quickly), and “shoulder taps” or interruptions. The larger the enterprise, the more challenging this becomes. Kanban and Lean-based portfolio management work together to address this issue.

Doing things right means ensuring that the product does what the Business wants and needs and that it does it free of defects. Scrum suggests managing testing but does not recommend how. The Kanban Method considers testing orthogonal to it. Lean thinking fills in this gap with the how, using up-front testing, acceptance test-driven development, and emergent design. An interesting blog to track is Sustainable Test-Driven Development. 

The Lean startup community is showing the great value in discovering what is important to build.

Simpler is more important than minimalistic

Minimalism appears to be a core value in the Kanban Method. We have all seen the opposite of minimalism – and it isn’t pretty! But we must remember Einstein’s popular quote, “Make things as simple as possible, but not simpler” (emphasis mine).

This core value must be tempered with Lean thinking. Being minimalistic is not a good if it means we miss things. Minimalism in frameworks can lead to framework tunnel vision, selective attention syndrome. It is what led to the Tacoma Narrows Bridge catastrophe.

Software development is complicated. The key is not to try to do everything but at least to consider different things. One form of minimalism is always starting with the same beginning. We often need to see what the problem is. We often can see the problem just by considering patterns of behavior we’ve seen in the past.

Is Kanban an Agile method? Well, it is a method for agility

Companies are not really Agile or not; rather, they are just more or less agile. The goal of being Agile is agility and agile approaches should increase agility, the ability to respond quickly to changing business conditions and changing understanding. Kanban, in all of its flavors, helps with agility.

Kanban is not, strictly speaking, an “Agile method.” It is not based on the Agile Manifesto. It is a “cousin” in the Lean family. While Lean and the Agile Manifesto are not incompatible, there are several things in Lean thinking that are outside the scope of Agile. This is why we call our approach Lean-Agile. We believe Lean-based Kanban should be something that everyone interested in agility should be aware of and use.

Kanban has foundations in Lean

Using Kanban to manage flow is a method created by Taiichi Ohno when he created the Toyota Production System (the definition of Lean). Attending to flow enables one to transition any situation by first seeing where you are and then making improvements by managing Work-in-Progress (WIP) levels.

All three of the versions of Kanban for software development mentioned at the beginning of this article manage WIP levels. This is good as far as it goes.

The second version takes this further, offering guidance based on Lean-thinking. For example, it suggests three other steps before managing WIP levels:

• Have teams only pull work to begin based on their capacity. This is not the same as managing WIP levels. It means don’t start something you can’t finish.
• Look at the structure that the work takes place in. In software development this means to create teams to the extent you can since teams remove delays in the workflow, thereby reducing waste (see Creating Teams in Scrum and Kanban).
• Change the order of the workflow. All too often teams do their work in the wrong order. Test-first (ATDD, TDD) is catching on because it results in an improved workflow. Managing WIP will not get you to this.

Summary

Here is our view of Kanban:

• Kanban, Scrum, and SAFe can co-exist and complement each other.
• Improving a clogged pipeline can often lead to better decisions in what you feed the pipeline. But just as often, attending to the front of the value stream is the best place to start.
• Software is complicated and people behave in complex patterns. Heavy process is not good but minimalism has a different set of risks and is also ineffective.
• Improving the development team can often enhance the ability for the Business side to see what they should select to be worked on. But often the business side can be convinced to focus merely by being explained the power of minimal business increments. The Lean startup community is demonstrating that focusing on discovering what is of value can lead to great results.
• Kanban is an approach that helps organizations become more agile.
• Kanban should use Lean thinking to manage workflow.