Firstly, this post is not an attempt to be divisive or competitive. Instead it is meant to be exploratory. What would it mean for the statement in the title to be true? Actually, the full statement was “People have so misunderstood Scrum, that they’ve reinvented it and called it Kanban”. It was made by Jim Coplien at Scan-Agile, after (but not necessarily the result of) a conversation over dinner where myself and a few others were describing how we used Kanban. Each time we described different aspects of our processes, Jim would say something along the lines of “but I do that with Scrum”.
So what would it mean for people to have so misunderstood Scrum that they have reinvented it and called it Kanban?
- It might mean that at their heart, Scrum and Kanban have the same intent. That both are really focussed on helping teams think about their processes in order to help them succeed.
- It might mean that the way that Scrum was originally articulated (and is still articulated according to the latest Scrum Guide) was not as clear as it could have been. That teams might misconstrue the focus on roles, meetings, artefacts and rules.
- It might mean that there are alternative ways of articulating the same intent. That teams might find alternative articulations valuable.
- It might mean that Kanban can be equally misunderstood. That teams might be bewildered by a less prescriptive approach.
- It might mean that we should spend more time on understanding how to help teams solve their problems and less time arguing and fighting over preferred solutions.
These are just some of my thoughts. They do not mean that I think Scrum is bad – just not perfect. They do not mean that I think Kanban is perfect – although it’s currently my first language. The topic drew a good crowd at the Scan-Agile Open Space and we had a good discussion. What else might it mean?
It would be very nice if you could quickly summarize your Kanban implementation that Coplien thinks might also qualify as a Scrum implementation.
Although the title is a red herring it is an intereting subject. A subject which was underlying many of my discussions wigth other at Scan-Agile.
All of us have the same intent. The religious wars that go on at the moment are just that. Speculation without scientific basis.
We, as the Agile community, should start more interesting dialogues that help us learn. Hopefully we can turn this discussion about Kanban/Scrum into one of those. Any research/ data to wshare with us on the subject?
Well, since Kanban the manufacturing methodology was first developed in the fifties, and Agile methodologies were most definitely inspired by the “lean” mentality of Kanban, I think it’s reasonable to say that Scrum is a relabelling of Kanban.
I don’t like guesses “It might mean”. Everything that includes people (like software dev. process) can be misunderstood, compromised, misinterpreted and rejected.
Sometimes there is no good reason to defend Scrum (or to defend Kanban). Sometimes it is just a fear. Someone who knows Scrum may fear Kanban. It is all about human nature. Many people don’t like to be pushed out of comfort zone and learn new things. It is no surprise to me that CST will defend Scrum. He may feel that Kanban pushes him out of business and pushes him to learn something new to be in charge.
It happens with everything. Scrum is not a silver bullet. Everything in software dev. is SO context dependent. Kanban has its place. And I don’t care about terms at all.
Kanban did bring something new, new angle at least + some cool tools. There is no need to fight against it. Learn it. Try it. Understand it. Adopt it. Mix it in when required based on context. Win the game.
Karl,
I think both serve the same purpose. But that Kanban has more explicit guidance on ceremony that focuses on the work and the flow. Scrum has more explicit guidance on ceremony that focuses on social interactions. This distinction creates some insight into how to address the challenges facing your team.
Dennis
I don’t think the movement to Kanban follows from a misunderstanding of Scrum, but I do think it possible that because Scrum’s inflexible framework brutally reveals organizational dysfunction that people reel from it and seek ways to circumnavigate the problems. Throwing out fixed time-boxing, or replacing it with “flexible timeboxing” aka cadence, may be one of those ways to recover from the reeling.
The mess of software organizations is massive and terrible. Sometimes it is too much to handle. It is natural human reaction to want to put the worst problems aside in order to deal with the immediate (and often easier ones). Whether this is a good approach is yet to be figured out. My guess is that it isn’t. Bury something deep enough and it is hard to find it again when you do feel ready to dig it up. Earth shifts. And deeply buried things tend to rot.
There is a lot common in Kanban and Scrum. If I had to put all differences into one single phrase then it would be:
“Scrum maximizes capacity while Kanban minimizes cycle time”.
Meaning: In Kanban the time a single story is in the system is minimized. Get a single thing done as fast as possible.
In Scrum, things done together in a time-box (Sprint) is maximized.
Therefore, choose what matches your needs best.
And I agree with Tobias Mayer that there are quite a few organisations out there that did not get Scrum running and jump now to the next “Hype” without understanding why Scrum did not work. I guess, they will fail with Kanban, too; due to not working continuous improvement.
Nice read but i am sure a lot of people might not agree. Personally i am a fan of KANBAN as well, but can you point out the 3 major stand outs between KANBAN and scrum and where KANBAN has the edge against scrum according to you.
[…] Is Kanban A Relabeling of Scrum? and A New Lean and Agile Picture (Karl Scotland) […]
I don’t consider Kanban being a relabeling of Scrum.
I do have a minor issue, though, with relabeling Kanban as a software development methodology… I sometimes wonder if David Anderson regrets calling his Corbis stuff a “Kanban system for software engineering” because we (the community) shortened it to just Kanban and that name stuck. Anyway, I digress.
On a more serious tone, I also have an issue with teams adopting Kanban for the wrong reasons, i.e. because another methodology revealed a dysfunction, it started to hurt, and Kanban offered a quick fix. Statements like, “in this Kanban thing we don’t have to estimate”, or, “if we do Kanban then nobody needs to become a generalist and all that feature team crap goes away.” Hearing people say things like this (and being somewhat serious while saying that) makes me a sad panda. There’s great value and a powerful improvement mechanism behind the (unfortunately named) method we call Kanban.
Finally, I’m always happy to see discussions about Scrum and Kanban, their different approaches and fundamentals, without unnecessary and unproductive FUD and expletives.
Thanks, Karl, for blogging this.
You always have to remember with Cope that he likes making big broad statements that grab the imagination. Who could forget “Abstraction is Evil” or “UML set the industry back 10 years.”
Usually there is some truth behind the headline.
For me one of the strengths of Scrum has been that it is relatively well defined. While “agile” has come to mean just about anything you want it to it is quite clear what Scrum is, and is not.
While Scrum and Kanban may have similar roots and underpinning theory they are different. To say Kanban is a renaming of Scrum shows a mis-understanding of Scrum, Kanban or both.
Try this: apply Bas Vodde’s Nokia test to a Kanban team
– No iterations in pure Kanban, that fails part one
– No concept of a product owner or backlog in Kanban, they may exist but they are not mandated (as they are in Scrum)
– No estimation in pure Kanban
– No burndown charts, cumulative flow yes, burndown no
Finally disruption: heck yes, Kanban teams I’ve seen are disrupted all the time. Scrum seeks to create undistributed times, that concept seems lacking in Kanban.
Of course between Pure Scrum and Pure Kanban there are a lot of variations and this is probably the space Cope is thinking of.
Allan, I’m curious – what do you consider making up “Pure Kanban?”
Boy, I’ve done it now haven’t I? I’m going to regret using the expression “pure Kanban”…
There are teams that do Kanban as Karl or David would describe it in a conference presentation: no iterations, straight to release, no estimating, measure their flow and so on.
Then there are teams who are trying to do Kanban, but they have warts. Perhaps they still need to estimate, perhaps they can’t measure their flow, or perhaps they still do iterations. Maybe it looks more like ScrumBan.
If you want, replace “pure” with “by the book” – is a prerogative term I know.
I’ve written an article that attempts to illustrates the similarities and differences between Kanban & Scrum in a clear and objective way:
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
Thanks for the clarification, Allan.
Mike: I blogged the implementation that Jim labeled as “red pill Scrum”. See http://huitale.blogspot.com/2009/10/huitale-way-is-it-scrum-or-is-it-kanban.html
Hi Karl,
I see Lean/Kanban as mostly a re-packaging and branding/sales effort. David’s success doing what worked for him in a specific context has been badge an re-sold as “best practice” for everyone everywhere. He as as much as admitted so in the past.
To me as far as I can tell, the leading Kanban practitioners are doing Agile. Agile as always been a broad church, from DSDM to FDD to XP. I see Kanban as practiced by people like Rob Hathaway as fitting into this tradition.
What makes all these things Agile? Accepting complexity and adapting to change. As many have said here, I think you would be better off describing your actual practice what you do, when and where it works, and why it works. I don’t think the branding helps. This will add to the broad pool of Generic Agile knowledge. The best practitioners don’t follow a brand, they pick and choose ingredients from where ever and apply them as applicable. I don’t see that changing.
As for Lean. It seems to be all things to all men 🙂 On a more concrete level, we can study Lean product development and Lean Manufacturing. We have known about these things for a long time now, and have borrowed from them much in the past, but it should be needless to say that neither of these things are Agile. Agile goes beyond questions of efficiency and addresses the effectiveness of teams in an unordered, complex and changing world.
Of course re-stating Agile using new “Lean” language may better help some understand it. But we should be sure to “re-state” rather then “replace”, otherwise we will merely be turning the clock back and going over old ground.
I’d rather move things forward… I sense you do too.
Paul.