Kanban vs Scrum, the ultimate fight? Don't think so, here's why:...
Wow, what a week! A BIG post on Kanban by Scrum evangelist @jcoplien litterally put the blogosphere (and twittersphere on fire!).
It is good to have these family fights in the Agile family once in a while. As a life-philosopher once said: "These things gotta happen every five years or so, ten years. Helps to get rid of the bad blood".
But what are the differences between Kanban and Scrum, really? What are they?
Here's my take on the differences:
Kanban innovation
Kanban is, from it's origin a more systematic approach to measuring, visualizing and following up work in a "system" (one team, many teams, a company you name it). Thanks to the work by the Poppendiecks, David Andersson and Don Reinertsen (and others I'm sure) a pretty interesting and innovative economic framework as been put into the software process development lingo. Cost of Delay, Queues, optimize the whole, etc.
This economic framework is, in my view, the major innovation that Kanban proponents bring to the table. This was to be expected as many of the early adopters of Kanban were using Scrum before and felt the need to quantify and analyze some aspects of software development that Scrum did not tackle.
Scrum innovation
Scrum brought to the fore-front of process discussions issues that had never made it to our attention before: Self-organization, people/team dynamics, problem solving within a short cycle with feedback loops in place (Sprint), etc.
The major innovation of Scrum in my view was the introduction of the Socio-technical system of software development as Liker describes it in the Toyota way. Other similar software development processes took some of the ideas that Scrum also took, but shied away from the self-organization at the team level and blocker-removal focus of roles such as the scrum master. Those methods did not last long because the teams felt like puppets instead of adults with the possibility (and responsibility) to produce the best product they could.
Wrap-up
Both Kanban and Scrum brought significant innovations to the software development world. Those are just two types of innovations. There is more coming from the community and instead of focusing only on these two methods (which all of you should experiment with!) we should also look at what else is missing in the software development ecosystem.
My next interest area is "Complex Systems" (Complexity + Systems Thinking) and Management as a profession. I'll be exploring those subjects more and more in the future as a way to complement my use of Kanban *AND* Scrum. I suggest you do the same and find what else is missing in your environment and look for what else is around that could help you complement what you are already using. Here's a suggestion: start with @jurgenappelo's book on Management!
Happy reading, happy learning!
Labels: agile, complexity, kanban, learning, management, scrum, systems
RSS link
7 Comments:
I think you're right. Every approach seeks to address a different problem. I'm curious about your thoughts on the Core Protocols and McCarthy BootCamp. I have had a lot of Agile and Lean folks say it helps with the self-organization, accountability and trust (the basic underlying people stuff) other approaches try to control.
Cheers, and thanks for this!
By
Vickie Gray, at November 25, 2011 9:17 PM
The whole "big fight" has seemed a bit absurd to me. It's like fighting over which shade of gray is nicer.
I think either approach can be valuable when applied in proper context. It's better to avoid dogma and do whatever is practical.
It's endemic for us programmers to devise general solutions that work everywhere. Unfortunately reality does not work that way. Approaches like these always require some tweaking when taken to practice. Who is to say you couldn't get some aspects of both approaches and combine them to provide most value to you?
We shouldn't be slaves to these approaches. They should be made to work for us instead. Otherwise we're just missing the point.
By
Juho Vepsäläinen, at November 26, 2011 5:10 PM
@Vickie Unfortunately I can't say much on Core Protocols or BootCamp as I have not read about them :( Can you point me to a place where I can read more about those topics?
@Juho Totally agree. Existing approaches should be platforms for our learning (as we apply and learn from that application). I hope that we start/continue looking at Agile that way!
By
Unknown, at November 28, 2011 9:59 PM
HI Vasco,
I have published an article several weeks ago on Scrum vs. Kanban, the article really complements your post about this very topic.
I hope you'll have the chance to read it..
By
PM Hut, at December 01, 2011 10:57 AM
Very interesting post. I've just finished compiling a short note which is basically a case study comparing Kanban with Scrum. We do feel there are more merits to Kanban, feel free to check out the details below.
Link:
http://onsaasproducts.wordpress.com/2012/03/09/developing-saas-forget-scrum-check-out-kanban-and-similar-approaches/
By
Eilon Reshef, at March 11, 2012 11:47 PM
@Eilon
Good post, but i completely miss the "mindset" aspects in your post. What was the biggest change your company/team had to go through? Or were you natural born Kanbanistas? ;)
By
Unknown, at March 12, 2012 10:45 AM
@Kylie I agree with you in principle. In fact, early instances of Scrum were presented with the "scrum board" which is later seen in Kanban.
However the reason why project managers like Scrum better may have something to do with not understanding how Kanban works and why it actually gives the team a better insight into work (and blockers) as well as more visibility into the "flow" (or throughput) of stories.
In the end the difference is not huge. For most project managers the difficult step is embracing agile in general :)
By
Unknown, at June 12, 2014 1:05 PM
Post a Comment
<< Home