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.