A good description of Shu Ha Ri can be found here.  To summarise, the concept comes from the Japanese martial art Aikedo and refers to the three stages of learning.

• Shu is the first stage, where the student is imitating and following the master’s steps
• Ha is the second stage, where the student is showing understanding, and breaking away from the master’s steps
• Ri is the final stage, where the student is showing mastery and fluency by creating their own steps

So, is kanban a way of working which can be described such that teams can imitate and follow, or is it only achieved by teams who have mastered their process and become fluent?

A common perception is that kanban is a Ri level process. This primarily due to the fact that most prominent kanban implementations have been either by existing agile teams, or by teams with strong agile leaders. However, I think that this is a misconception, caused by a lack of understanding of kanban. A similar effect occurred in the early days of XP, when a lack of knowledge led to the idea that XP could only be used by highly skilled and experienced teams. This is now generally accepted to be untrue.

As the body of knowledge about kanban grows, I believe that kanban will become regarded as a Shu level process. In fact there is anectodal evidence of successfully introducing kanban to non agile, and hence low maturity agile teams. Comments on a recent thread on the kanbandev list include:

Eric Willeke,

“All that to say that ‘making a change to Kanban’ may or may not work, but embracing the Kaizen principles and adopting a waste-challenging behavior will very likely lead you to something like Kanban without the change-induced stress of ‘changing to kanban’.”

David Anderson,

“I would use kanban in preference to any other approach now because it doesn’t require teams to change their behavior initially and when the change comes it is incremental and based issues the team is having that are affecting its performance – a bottleneck, some waste or some variability in flow. As a result the resistance to change is reduced to an almost negligible amount.”

and,

“I would use kanban because i have seen it create the conditions that lead to positive cultural change towards a kaizen culture and because it drives automatic organizational maturity with a culture capable of reaching a high maturity level.”

Chris Matts,

“A number of teams in London implemented Kanban after a one hour presentation by David. Scrum master training takes a couple of days.”

Allan Kelly,

“The Kanban team have needed less instruction and help, and I see a wealth of statistical data coming out of the team.”

Aaron Sanders,

“I also find Kanban to be easier than Scrum. Teams tend to intrinsically “get it”, understanding the madness behind the method. such as: collaboration, swarm on work, work outside your ‘expertise’ to get things done, continually look to improve, learn and grow, etc.”

It seems to me that there is in fact a subtle difference between kanban and typical agile processes such as Scrum. Scrum focusses on being agile which may (and should) lead to improving. Kanban focusses on improving, which may lead to being agile. However, being agile itself is not important – it just happens to be the best way we (or at least I) know at the moment. If a team improves in other ways, then its the improvement that’s important.