For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.

I believe that Kanban is a great fit for several contexts. I also think that some reasons people give to use Kanban over Scrum for software development are just misunderstandings about Scrum.

First, let me define what I mean by Kanban, because there are about a million different moderately credible definitions of Kanban.

I primarily define Kanban as the concept described by David Andersen's Kanban book, slightly enhanced by David's more recent definition of Kanban to include some changes to the "core properties." Even though David described Kanban in contexts where software is the work being visualized, I don't think Kanban is a good fit for software development teams.

Caveat: There are always multiple dimensions to consider in any scenario -- I've tried to focus on the key decision dimension in each of the cases below -- just for the sake of simplicity of this article.

Here is where I think Kanban fits well...

In cases where a team doesn't really work on the same shared product, I think Kanban fits well. And by product, I mean product.

For instance, I've participated on courseware development efforts, developing Scrum courses. Everyone on the team worked on the same shared product (even though that product was not software), and we all contributed to that same shared product in different ways. In my view, that was a good fit for Scrum. But let's consider a different case.

Let's consider the case of an IT operations team who does little to no software development. At any one time, a team of IT operations people could be working on 8 different work products. Different servers, documentation, different sys admin systems, running ad hoc reports, monitoring data, networks, etc. There would certainly be value in visualizing the work that is going on (something that goes on in Scrum and Kanban), but since everybody's mostly working on a completely different (non software dev) work products, Kanban is a good fit here. This team probably does not need concepts like a Sprint Review. There is no wider customer group who all share the same "product" to review in a Sprint Review. There is no marketplace for "the product" per se and as such, we don't need marketplace updates, or an analysis on whether our features are attracting the right revenues or cost savings that we'd hoped for. Your typical IT network support team also falls under this umbrella -- a team of people working on separate work products where there is no marketplace for that product. Your network support people are imaging new machines, trouble shooting network problems, re-setting passwords, etc. Maybe that even do a little SQL querying or script writing -- which is technically software development -- but when done as such a small part of the rest of the work that team does, this small amount of software dev probably doesn't warrant Scrum. Having said all of that, while I consider this context to be a good fit for Kanban, I ALSO think it is a good fit for Scrum. So, whether Scrum or Kanban is a better fit for this kind of team will often have much to do with the teams they support and the other organizational context.

Another case of where Kanban fits well is non IT work in general. My company,, runs on Kanban. Yes, we work on separate work products, but we also do a ton of stuff that has nothing to do with IT. Our work products do not have a marketplace of their own (with the exception of training courses/courseware). It is mostly back office admin type of stuff -- book keeping, proposals for clients, marketing collateral, assembling class supplies, scheduling travel, etc. Note that there is little to no software development occurring in this case.

Another case of where Kanban fits well is when you have ~2 or less fewer people doing the work. Even if these 2 people work on the same work product, Scrum is probably too much overhead here, especially so if those 2 people are in very close contact or co-located. Personal Kanban also falls under this umbrella.

Another case of where Kanban can work well is in tracking work as it crosses an entire enterprise. Let's assume that software development work is only a tiny or non existent part of this enterprise workflow. In the places where software dev is part of this flow, those software dev groups would use Scrum or scaled Scrum for their piece of the broader workflow.

Now, in places where this kind of entire enterprise workflow is *mostly* tracking software development efforts, I do not believe that Kanban is a good fit. I believe that using a scaled Scrum approach with very broad product definitions virtually eliminates the need for Kanban in this context. In fact, in the original Toyota Way version of kanban, using kanban to signal disruptions in enterprise manufacturing workflow was considered shameful, and the kanban should be eliminated. I have certainly seen enterprises that cannot effective scale Scrum yet with broad product definitions, so I might be ok with using Kanban in the meantime. But again, like Toyota, Kanban for this purpose should be seen as a bandaid on a dysfunction or impediment that needs to be resolved as soon as possible. If you leave the Kanban there for too long or without the "bandaid" caveat, you could be codifying a dysfunction.

Another place that Kanban fits well is software that is being sunsetted, or jettisoned, because it is no longer needed or is being replaced by other systems. It is at the end of life stage. In this case, there is no "product vision" needed from a Scrum Product owner. The only vision needed here is "rear view vision", as in, viewing the sunsetted system in the rear view mirror because you'll be leaving it behind relatively soon. Note that while the work here is software work... it's not really "software development" per se -- because we're no longer "developing" the product. The product is on life support -- we're just keeping it alive until it's time to pull the plug and move on. One small caveat on this case. If the end of life system is being jettisoned because it is being re-written, you need to look inward because this system got out of touch with value somewhere along the way. Usually it's technical debt, but sometimes it's because you didn't see a marketplace trend soon enough to pivot effectively. Both of these situations are usually as a result of a bad pattern of company behavior or culture. As such, when you're rewriting the system, you'd sure better solve that root cause problem, or you'll be in the same place again in a few years, with another need for a re-write. This is a vicious cycle that will cost your company millions or even hundreds of millions of dollars. Beware!