Welcome to EMC Consulting Blogs Sign in | Join | Help

Simon Bennett's Blog

The philosophy of Kanban is Kryptonite to Scrum

As awareness of Kanban grows, people are naturally wanting to learn more about it; especially if they’ve tried Scrum and found it challenging or failed to reap any perceivable benefits from it.

At first glance, many people see the basic difference between Scrum & Kanban being that one system has time boxes, and the other does not.

Another common first impression is that Kanban does away with estimating.

And so teams that have struggled with either delivering in time boxes or estimation find these aspects attractive and look to incorporate these into their Scrum projects. Yay! No more Sprint planning!

But to me neither of those impressions really grasps the fundamental difference, and I think many Kanban practitioners might agree with me. (Chime in guys, I know you’re out there)

To my mind there is a fundamental difference in philosophy between the two approaches.

As referenced in my previous post Purist is a dirty word, many people miss the point of Scrum. They mistake the artefacts, roles and rituals for Scrum – and in the process lose the juice. Kanban enthusiasts often point to these roles, rituals and artefacts as flaws in what some of them see as an overly mechanical and prescriptive process.

But this isn’t the difference either.

The fundamental difference as I see it, is that Scrum is a disruptive and amplifying system. It turns your project up to 11, and highlights the flaws in the way you do everything. These flaws surface as impediments and it’s then the ScrumMaster’s role to remove these impediments; this is where Scrum gets its power to improve, and why the ScrumMaster is such a challenging and difficult role if taken seriously.

Take the philosophy of Scrum far enough and you’ll improve the entire ability of your organisation to solve complex problems in record time.

Kanban on the other hand is a gentler more forgiving system. Especially to start with. You map and measure your existing process, make it visible & then begin to limit work-in-progress and track cycle time. Its proponents say that this is the less disruptive more pragmatic approach. They’re quite possibly right, depending on your exact definition of pragmatic. (Pragmatism is a philosophical movement that claims that an ideology or proposition is true if it works satisfactorily)

It’s not the purpose of this post to discuss which of these two approaches is better (in fact I think they each have circumstances to which they’re ideally suited – but more on that later)

My purpose here is to highlight the danger in mixing the philosophy of Kanban with the practice of Scrum.

If you’re going to use Scrum, but ignore or hide the impediments, (or even not raise them in the first place) then you are asking for a world of pain, and a lack of progress. This is what Ken Schwaber and Martin Fowler are talking about when they speak of flaccid Scrum. (at least from a technical debt perspective)

Both Scrum and Kanban prize transparency; but they handle it in different ways – and Scrum builds-in an explicit call to action, which needs to be answered for Scrum to succeed.

Kanban allows for you and your team to simply “accept” impediments, and measure their effect.

Understanding the difference is crucial, and mixing the two can be fatal.

Please don’t read this as an anti-Kanban rant, it’s not.

And, please don’t read this as a call to “keep Scrum pure” – to not adopt Kanban popularised practices such as limiting work in progress. Limiting WIP has long been a standard working practice among all the best Scrum teams I’ve ever worked with.

It’s a call to understand that neither of these systems are “methods” as much as they are philosophies. I’m currently of the mind that neither is right or wrong, but rather each has its place and the real challenge is figuring out what’s appropriate when. If you’re doing Scrum well right now, and truly getting no benefit, then maybe you are better off going to Kanban because in all likelihood your project is potentially not as complex as you think it is. Flow and predictability as well as end to end to visibility are probably going to give you more benefit.

On the other hand, if you really are dancing on the bleeding edge then I imagine you’ll come to depend on Scrum.

To close: The philosophy of Kanban if applied to the practice of Scrum truly is like Kryptonite. That Scrum project will weaken as long as the philosophy is nearby.

Take it away and that project will regain strength.

If you cannot bear to do that then embrace your Kanban spirit AND the Kanban practices and stop calling yourself a Scrum project.

Published Tuesday, November 10, 2009 3:08 PM by Anonymous

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Karl Scotland said:

One minor comment (there had to be one!)

I'd say:

Kanban allows for you and your team to acknowledge impediments, measure their effect, and use that information to guide improvement.

November 10, 2009 4:07 PM
 

David Starr said:

The philosophies are different, very true. In my experience, Kanban embraces the reality of your organization and gives you the tools to make lasting change.

Scrum reacts to the fire of the moment, whereas Kanban seeks to understand the overall behavior of the team/organization.

Bottom line for me has been that moving teams from Scrum to Kanban has had these results:

1. Reduced tension in the workplace

2. Allowed teams to actually support business objectives without playing the "You're violating the Sprint" game.

3. Caused teams to see their impact beyond their own border. This is huge. Scrum promotes the idea that the team is the #1 first class citizen. Lean says it is the overall organization.

Kanban still needs designated stewards of the process to remain effective and many of the practices Scrum started remain effective. Daily standups, weekly or so planning, this stuff still works and has value.

November 10, 2009 4:07 PM
 

Tobias Mayer said:

Excellent post Simon,  I believe you have captured many of my feelings of the differences between Scrum and Kanban in a way I have not been able to articulate well.  I don't have anything to add to this right now, but I shall certainly promote it.  Others need to read this.

-- Tobias

November 10, 2009 4:08 PM
 

mark.summers said:

It seems to me that lots of organisations can't deal with the tension that Scrum creates by exposing many organisational dysfunctions.  Maybe Kanban is a better approach for them, maybe once the organisation has a greater maturity, it will be able to move to Scrum and deal with the challenges that are exposed.  KanScrum - using Kanban to get to a mature enough organisation to be able to move to Scrum.

Creating the tension in Scrum is by design it is meant to disturb the equilibrium, but the organisation must first accept that it needs to change and be mature enough to deal with what Scrum exposes.  I guess that's why we hear experience reports of CMMI Level 5 companies being able to adopt Scrum a lot more rapidly than some others.

I agree both approaches are useful in different situations.  Thanks for your insight.

November 10, 2009 4:57 PM
 

aritikka said:

Great insight!

Ari

November 10, 2009 6:39 PM
 

Ran Nyman said:

I have to disagree that mapping current state and start improvements works. Many organisations have done value stream mapping in manufacturing and in product development where they see how badly they are doing and fail constantly improving their processes.

November 10, 2009 8:05 PM
 

Bob Sarni said:

Simon, great post - especially agree with your point "Both Scrum and Kanban prize transparency; but they handle it in different ways – and Scrum builds-in an explicit call to action, which needs to be answered for Scrum to succeed" and this definitely hits home for me. "And, please don’t read this as a call to “keep Scrum pure” – to not adopt Kanban popularised practices such as limiting work in progress. Limiting WIP has long been a standard working practice among all the best Scrum teams I’ve ever worked with".

November 11, 2009 2:51 AM
 

Tobias Mayer said:

@Karl "Kanban allows for you and your team to acknowledge impediments, measure their effect, and use that information to guide improvement."

Does Scrum (or any other Agile approach) forbid you to do that, does it prevent you, does it advise against it?  Isn't that what refection is all about?  What am I missing?

November 11, 2009 3:58 PM
 

Karl Scotland said:

Hi Tobias (we meet again :-)

Simon's point was that Scrum "builds in an explicit call for action". Its "Revolutionary". I was refining Simon's point that Kanban "acknowledges impediments" but *doesn't* include the same explicit call for action. However that doesn't mean that improvement doesn't happen. Its "Evolutionary".

Simon's message (I think) is to call a spade a spade. If you're revolutionary, call it Scrum. If you're evolutionary, call it Kanban. Both are useful and valid in the right context.

Does that clarify?

November 11, 2009 4:29 PM
 

Tobias Mayer said:

Hi Karl --

"Simon's message (I think) is to call a spade a spade. If you're revolutionary, call it Scrum. If you're evolutionary, call it Kanban."

I'll hand off to Simon on this. Is that what you meant Simon?

November 11, 2009 5:47 PM
 

Chris Sterling said:

Good day Simon,

An impressive article that captures my experience with teams that use both Kanban and Scrum. It seems to identify the difference in approach using a concise and objective flow. Thank you for such a great read!

November 12, 2009 3:05 AM
 

Sameh said:

Excellent! I enjoyed reading. It made good job in bringing the pieces together.

Scrum or process in general is like a surgery it causes change in the way people work and in the prevailing culture. For me this is a "confrontational" strategy for conflict resolution.

From my view, Kanban is supporting method or technique to minimize WIP, identify wastes and improve Lead Time to process a feature. From my view, it can be useful to integrate them together. Kanban can provide mathematical understanding on how Scrum process faster the feature. Kanban helps to provide guidelines on taking wise decisions while using Scrum.

Thanks again for this good post!

November 12, 2009 11:08 AM
 

Michael Dubakov said:

Nice vision, I should say.

I have a very similar vision BTW, but you nailed it better!

5 Wrong Reasons To Apply Kanban

http://www.targetprocess.com/blog/2009/08/5-wrong-reasons-to-apply-kanban.html

Agile Product Development: Iterate, then Flow

http://www.targetprocess.com/blog/2009/07/agile-product-development-iterate-then-flow.html

November 12, 2009 11:32 AM
 

Juan Banda said:

Simon,

I enjoyed reading your post,  right to the target.

I especially like this part "I’m currently of the mind that neither is right or wrong, but rather each has its place and the real challenge is figuring out what’s appropriate when", I guess that goes in line with whether or not you and your organization are ready for a disruptive approach like Scrum or you want to start with something more moderate.

Regards,

Juan

November 12, 2009 2:11 PM
 

David J Anderson said:

Amazing! Finally something that Tobias and I agree on! Yes, Kanban is evolution while Scrum is revolution. I am very comfortable with that positioning.

Simon! Great post. Very nice insights!

Karl and Simon,

I feel you are using the term "impediment" too loosely in this post. Impediments are just one hindrance to performance. Impediments are special cause variations (in a Deming sense), in addition to this opportunities come from narrowing variability in common cause variation, removing wasteful economic costs, and alleviating bottlenecks.

There has been a tendency in the agile/scrum community to talk about bottlenecks and impediments synonymously, they are not. A bottleneck is a systemic (semi-permanent) impediment to flow or throughput. An impediment is a specific blockage to one or more items. To use the metaphor, a bottleneck and the cork are not the same things.

What's powerful about Kanban is that it exposes this wide range of improvement possibilities and enables the underlying models that help teams see improvements opportunities and act on them in a constructive and objective fashion. Perhaps you could call it a scientific fashion. The intervention is based on a model and the model predicts an outcome. The actual results can be measured and compared with the prediction from the model.

Because of the confusion and misuse of "impediment" and "bottleneck" I've had to dedicate a whole section in the manuscript of the forthcoming Kanban book to clarification.

Regards,

David

November 12, 2009 5:09 PM
 

Stephan Schmidt said:

Basically wrong. If you start measuring cylce time you will see impediments to your cycle time (or bottlenecks). To reduce cycle time you will need to remove those as hard as Scrum would do. Measuring cycle time is a tool, you seem to confuse it with a goal

Cheers

Stephan

November 13, 2009 7:28 AM
 

Jason Yip said:

"Kanban allows for you and your team to simply “accept” impediments, and measure their effect."

I kind of auto-translated "Kanban" here to Lean and did a double-take.  Simply accepting problems is definitely not a Lean philosophy.  Measuring to expose, clarify, and engage people in problem solving vs fixing without explaining is more how I would describe it.

I would also not agree with the evolution vs revolution distinction.  The context determines what is appropriate.  Appropriate response to context is more the Lean philosophy.  Sometimes you need revolution; you always need evolution as well.  Again, I'm auto-translating here.

November 14, 2009 11:33 PM
 

Kenji Hiranabe said:

Great post, I'm convinced.

"Kanban is evolutionary while Scrum is revolutionary" explains why in Japan Agile(Scrum) adoption rate is still low but I see kanban commonly.

My Day One of Kanban is "Before changing anything, let's visualize your flow as a whole." Starting with that, gathering bottom-up consensus as to what thy are doing at Gemba as well as energy of change by involving Gemba developers in an appriciative way.

November 15, 2009 11:54 AM
 

Henrik Kniberg said:

Hi Simon! Well written, I agree with your basic points. But the title and closing remark is a bit misleading:

"To close: The philosophy of Kanban if applied to the practice of Scrum truly is like Kryptonite. That Scrum project will weaken as long as the philosophy is nearby. Take it away and that project will regain strength."

Only if your team had a purist approach to Scrum. Ken advocates a purist approach, Jeff doesn't. Choose your flavor. Personally I don't care much for a purist approach to anything.

Most teams I bump into don't really care what their method is called, they just use whatever works best for them and adapt as needed. In my experience Scrum teams that start moving towards Kanban get strengthened, not weakened.

I would never tell a team that they should remove Scrum to make way for Kanban, that's not evolution. The evolutionary approach is to start experimenting with Kanban, and removing or changing selected parts of Scrum only when necessary.

Here's an article that is intended to aid this path of evolution:

http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

November 20, 2009 9:13 AM
 

Markus Andrezak said:

Great post,

and just what I think along the lines of "Revolution" and "Evolution" where the impact on the social learning and asoption in your environment can not be overrated!

The post is a good example of the possibility of two worlds and the tolerance required in the agile field, leaving lots of space for open fact based discussion rather than blaming!

Here my short ignite talk along a similar line, given at igniteberlin.de last mondy: http://igniteshow.com/videos/why-and-how-kanban

Cheers

Markus

March 4, 2010 10:02 AM
 

Wolfgang Frank said:

Quite interesting post - made me re-evaluate the practices I use as a Scrum Master and agile coach ... though in the end I don't agree. ;-)

I am a big fan of "scrumban" (http://tinyurl.com/5saepx) and know by experience that it works fine. I used a similar approach in practice and despite your metaphor of kryptonite to weaken scrum, applying Kanban principles (basically Goldratts "Theory of Constraints") and trying to avoid bottlenecks, generating flow, minimizing cycle-time during a sprint helps multiplying the output and strengthens a scrum team.

But I can see your point ... you have to be careful how to apply Kanban to Scrum ... it heavily depends on the team and the organization whether you get a benefit out of it. So I consider the "mixture" to be an optimization and refinement in the sense of kaizen and a continuous learning process for mature scrum teams which know how to adpot to these principles step by step on their own pace.

Thanks for the post!

Wolfgang

March 4, 2010 11:20 PM
 

Ola Berg said:

"My purpose here is to highlight the danger in mixing the philosophy of Kanban with the practice of Scrum."

The other way around, however, works like a charm: mixing the philosophy of Scrum with the practice of Kanban.

March 24, 2010 12:19 PM

Leave a Comment

(required) 
(optional)
(required) 
Submit
Powered by Community Server (Personal Edition), by Telligent Systems