Comparing Kanban To Scrum

Please, find the french translation of excellent Kniberg's "Kanban vs Scrum" article on Kanban-vs-Scrum-French.

Critical Chain Project Management is a "straight to project" implementation of TOC and Lean philosophy. It uses much of lean principles like Kanban, but deliver the concepts more practically.

Also, the book, by Eli Goldratt, is a fun read. :)

Oops!

I've read TFA now, and I believe the "support and maintance" work best fit the model proposed in "Drum-Buffer-Rope" (DBR).

Scrum still sounds like its for revisinist Waterfall practitioners than Agile"ish" in nature. All of thise time boxing, scheduling, planning, and other errata ends in BDUF more often than not. Kanban however, the projects I know of, rarely fall into the BDUF trap and rarely get bogged down or frustrated as many do with Scrum.

...any other personal insights or experiences out there with these?

Adron,

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.

"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'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.

TFA?

This has been out here for a long time, but was recently referenced by a recent blog I just read. Interesting points about Scrum. I'm finding that more and more I want to release something once its complete rather than waiting til the end of the cycles. I'd rather not batch a bunch of things into a 2 week cycle just because they fit either. I'd rather be batching work together that makes sense together and release whenever its ready. Sounds maybe more like Kanban.

Last point, just a quick reminder that avoiding BDUF is not the same as NODUF. Need some design up front. So how about SDUF?

I blooged this topic, the differences between agile frameworks and when one or the other makes more sense last year which might help to decide which tool is a good fit for a given project or team: dusted.codes/when-to-use-scrum-waterfall-vs-scr...

About two years ago I came to an interesting conclusion — it doesn’t matter how you call it as long as you apply the right principles.
You can read more about why here:

medium.com/dennis-nerush/scrum-kanban-it-doesnt...