Karl Scotland – Using Agile to Deliver Value
Archive for November, 2008
Managers' Introduction to TDD at Agile2008
Nov 28th
InfoQ has just published a video of myself and Dave Nicolette’s presentation at Agile2008 – A Managers’ Introduction to Test Driven Development
Kanban and the New New Product Development Game
Nov 26th
One of the primary origins of Scrum is “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka, published in the Harvard Business Review in 1986. This is the article in which the contrast is made between a traditional sequential or “relay race” approach and a holistic or “rugby” approach. Hence the name Scrum was derived. As part of their explanation of the differences between the approaches, the authors describe three types of approach:
- Type A – single phases, proceeding exactly sequential
- Type B – single phases, overlapping at their borders
- Type C – multiple phases, overlapping each other
The Type C diagram was in my mind when I was putting together the diagrams towards the end of The Anatomy of an MMF, and I think this approach actually describes a Kanban based approach pretty accurately, where we recognise and allow phases to exists as necessary, but at the same time encourage whole team collaboration.
Jeff Sutherland has also reinterpreted the classifications to describe how Scrum’s Sprints progress:
- Type A – single Sprints, proceeding exactly sequential
- Type B – single Sprints, overlapping at their borders
- Type C – multiple Sprints, overlapping each other
Another way of describing this evolution could be to say that Type C is multiple, overlapping MMFs, where each MMF is variable length and not time-boxed. Its worth noting that The New New Product Development Game makes no mention of time-boxes!
Is Kanban Only Suitable for Mature Teams?
Nov 5th
Another hot topic around kanban is whether it only suitable to use with mature agile teams. In terms of Shu Ha Ri, is kanban a Ri process, or can it be a Shu, or even Ri process?
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.
