Comparing Kanban To Scrum
Kanban has been gaining serious interest as a valid approach to implementing agile for your development organization. As such, many people are asking the question "how does Kanban compare to Scrum?". Henrik Kniberg has taken a stab at answering this question.
Henrik Kniberg has recently published a draft version of a "practical guide" comparing Kanban and Scrum. With this concise article, Kniberg presents an outline of the ways Kanban and Scrum are similar, and how they differ.
He starts the article with this quicklist view of each methodology:
Scrum in a nutshell
Split your organization into small, cross-functional, self-organizing teams.
Split your work into a list of small, concrete deliverables. Assign someone to be responsible for that list and to sort the list by priority. The implementation team estimates the relative size of each item.
Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration.
Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
Optimize the process by having a retrospective after each iteration.
For more details check out “Scrum and XP from the Trenches”. The book is a free read online. I know the author, he’s a nice guy :o) http://www.crisp.se/ScrumAndXpFromTheTrenches.html
Kanban in a nutshell
Visualize the workflow
Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.
- Split the work into pieces, write each item on a card and put on the wall
- Use named columns to illustrate where each item is in the workflow
Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.
For more details check out Karl Scotland’s intro: http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence/
Over the next 20-some pages Kniberg goes into detail with his comparison, then presents this summary of his thoughts at the end of his article:
- Both are Lean and Agile
- Both use pull scheduling
- Both limit WIP
- Both use transparency to drive process improvement
- Both focus on delivering releasable software early and often
- Both are based on self-organizing teams
- Both require breaking the work into pieces
- In both cases the release plan is continuously optimized based on empirical data (velocity / lead time)
Scrum Kanban Timeboxed iterations prescribed. Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be event-driven instead of timeboxed. Team commits to a specific amount of work for this iteration. Commitment optional. Uses Velocity as default metric for planning and process improvement. Uses Lead time as default metric for planning and process improvement. Cross-functional teams prescribed. Cross-functional teams optional. Specialist teams allowed. Items must be broken down so they can be completed within 1 sprint. No particular item size is prescribed. Burndown chart prescribed No particular type of diagram is prescribed WIP limited indirectly (per sprint) WIP limited directly (per workflow state) Estimation prescribed Estimation optional Cannot add items to ongoing iteration Can add new items whenever capacity is available A sprint backlog is owned by one specific team A kanban board may be shared by multiple teams or individuals Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles A Scrum board is reset between each sprint A kanban board is persistent Prescribes a prioritized product backlog Prioritization is optional
If you've asked this question yourself, or needed to answer it for someone else, you should take some time to read Kniberg's Kanban vs Scrum article.
Why not CCPM?
Also, the book, by Eli Goldratt, is a fun read. :)
Re: Why not CCPM?
I've read TFA now, and I believe the "support and maintance" work best fit the model proposed in "Drum-Buffer-Rope" (DBR).
...any other personal insights or experiences out there with these?
When you say "sounds like" it gives the impression you haven't worked with Scrum or Kanban before, and when you say "more often than not" it gives the impression you're speaking from experience. These sound like mutually-exclusive conditions. Which one is true?
I think it goes too far to say Scrum encourages waterfallish thinking and outcomes, and it goes too far to say Kanban solves these problems. A process or framework or methodology doesn't "solve" anything. The outcomes people achieve result from the choices they make. Having a process or framework in place that helps guide people toward good choices is, of course, desirable and useful, but the process itself cannot be blamed for poor outcomes or praised for good ones. Every process is "only" a tool. I use quotation marks around "only" because we have to have the right tools for the job, after all. I just mean to say we must not become slaves to our tools, and we must not expect that because we can spell "Scrum" or "Kanban" or any other word that we can put our feet up and relax while we wait for our Magic Process to get the work done.
I think Scrum represents early thinking about "agile" methods that was driven by the status quo in most large organizations at the time. The status quo today is different. More organizations are ready to adopt the level of change that is required to move to a Kanban process, or at least to begin to apply lean thinking. In my view, Scrum "forces" people to be accountable for particular aspects of software delivery by defining specific roles, and "forces" people to deliver incremental results regularly and to reflect on their work regularly. This is appropriate in an environment where these concepts are not part of the culture. Once the organization has matured to the point that people no longer have to be "forced" to do these things, then people may be able to see the way to Kanban. Until they learn to think in terms of ideas like value stream, continuous flow, pull, and waste, it's hard for people to understand why they should consider something like Kanban. It's easy for people to stick a few cards on the wall, walk around repeating "Kanban" or "Scrum" or some other incantation and not really change the way they think or the way work flows in their organization. If people choose to do that, it isn't Kanban's fault, and it isn't Scrum's fault, either.
Personally, I haven't seen Scrum lead to BDUF. I have seen people say they were implementing Scrum while continuing to practice BDUF - their own old habit, their own choice. Kanban would not automagically save them from their own habits and choices. We've got nothing, as a community or as a profession, as long as we persist in joining "camps" that defend their favorite magic-bullet-of-the-moment and disparage others who have found other ideas useful in particular contexts. There are many valid and practical ideas that help us deliver value effectively. I'm not surprised at all to see advancement beyond the initial concepts of "agile." I won't be surprised when we discover the next steps beyond Kanban, either. It's a major step forward, but it's not the end of the journey.
I'm experienced in Kanban and experienced in hearing about Scrum. I haven't done Scrum, but similar activities.
You are right about a methodology not solving process problems. It is the activities that the methodology pushes that solve the problems, through employee work activity. Thus I was merely stating by association, which is true enough.
Over Waterfall I'd take either system, but it looks like by observation and the projects I've seen over the last 15 years that Kanban does a lot more to solve the myth of scheduling and maintaining real velocity. Scrum doesn't address scheduling, instead new names are just applied to the process and I'd suspect (no evidence yet) that project managers would end up with the same bad scheduling numbers.
Iterations are great, but workflow and maintaining velocity would be a higher priority to me. Most teams are going to be able to maintain velocity easier without stop and go iterations and move much faster just working from the backlog of the Kanban.
Just my 2 cents, but I'd go head to head against any other team working Scrum any day utilizing Kanban.
I think scrum is ideal process management methodology for product development and in the other hand kanaban is derived from lean methodology with 50 years experience in business industry. i think it's no matter which agile methodology your are using, the important point is that we should adjust & mix different practices which is work for us. this is nature of agile "just enough". we can mix & match different practices from lean like brainstorming, 5 why and ... into our scrum sprint planning & review meeting.
Last point, just a quick reminder that avoiding BDUF is not the same as NODUF. Need some design up front. So how about SDUF?
Scrum vs. Kanban vs. Scrumban vs. Waterfall in practise
Dustin Moris Gorski
It doesn't really matter which one you choose
You can read more about why here: