What is "Scrumban"? The name seems to offer a simple answer - surely it's a mixture of Scrum and Kanban? So you think the rules of Scrum are a bit strict. You think Kanban doesn't offer enough guidance on things like roles and when planning and retrospectives should take place? Why not just mix the two and things are bound to be better!
The only snag with this is that Scrum and Kanban already have definitions which are not really compatible with this mixture idea. And Scrumban, at least in the original usage of the term, was coined with a different meaning than mixing the two methods (see
Scrumban, Corey Ladas 2009).
The definition of what is and isn’t Scrum is well understood, thanks to the concise publication of its “rules” in the
Scrum Guide. Scrum is a process framework – a set of guidelines and constraints within which your team can define and improve the process you use for developing products. It’s not a process as such - it is silent on many of the aspects a process needs (it says you need a “Definition of Done” for example, but not what it should be). However it is a framework that is very specific about some aspects of the process, such as when planning meetings take place and how long they should last.
Scrum is often
contrasted with Kanban, also a framework, but more accurately described as an improvement framework; that is the approach for assessing and improving your process. Kanban has fewer constraints or rules than Scrum, allowing a wide range of processes from those based on Scrum itself to many variants – agile and less agile – which can be the process's starting point . As
+David Anderson explains, "A Kanban system is overlaid on an existing process." Provided you can look at your work as a flow of items - usually this is simply a case of changing the way you look at your work - you can use Kanban to assess and improve your process.
As yet there is not the simple definition booklet that defines what is and is not Kanban, so the best starting point is the “Blue Book”,
Kanban (Anderson, 2007), plus the summaries - published informally since that time - of the foundational principles and core practices. Because I like short definitions, I've summarised these as "
how to adopt Kanban":
- See work as flow (Lean Flow Paradigm)
- Start from here and improve (Foundational Principles)
- Make work and policies explicit;
Make validated improvements (Core Practices)
If you are doing this, you are doing Kanban, even if your policy for work in progress (usually cited as a key difference between Scrum and Kanban), is to limit work in a Sprint to that which the team believes it can complete (the policy that Scrum applies)... or if you decide not to limit work in progress at all.
In fact there is nothing in Scrum that is incompatible with adopting Kanban as well. Nothing that is except the “rule” that the rules can’t change. If you can validate that it would be an improvement to do planning more or less frequently, or to decouple the frenquency at which you do retrospectives from the frequency at which you do reviews, Kanban would say you should make that change. Scrum might say okay make the change too, but if you do so you are no longer doing Scrum.
So this is the key to what Scrumban is. Scrumban is a process being improved using Kanban, which probably is no longer strictly Scrum. Some part of the strict Scrum framework has been modified (or maybe was never tried) because it is believed the change is more appropriate, brings more benefits or incurs less cost than pure Scrum. Such processes used to be referred to, somewhat derogatorily as “Scrumbut”. Scrumban is the more acceptable, less pejorative alternative... and it's also more positive because it implies you're using Kanban.
In his book on Scrumban, Corey Ladas describes a possible trajectory for a process that starts off as Scrum and changes as Kanban improvements are applied. This is what he meant by “Scrumban”. At the end of the story the process has very little similarity to Scrum and few people would even describe it as “Scrumban”. It is simply a flow-based process, as near as possible to
single piece flow, with a typical Kanban improvement process around it. Is this process still Scrumban? At the point when the similarities to Scrum have disappeared, I’d suggest the label is not helpful. Many have concluded the label itself is not helpful
anywhere since it causes the kind of confusion that is visible in statements like "I prefer Scumban to Kanban" or "Kanban is a better process than Scrum". Look at the definition of these terms and it’s clear such statements are not really meaningful.
I think though that a commonly accepted definition of Scrumban would be useful, at least to reduce the confusion in discussions around this topic. So here’s my attempt:
“Scrumban is a Scrum or Scrum-like process which is being improved with Kanban.”This definition implies that if you are doing Scrumban you
are using Kanban! Maybe that will be difficult to accept for some people, particularly if they believe their approach is "better than Kanban". Maybe a Scrumban community will emerge and wish to define distinctive practices from Kanban, just as most Scrumban processes differ from Scrum in some (albeit different) ways. In the meantime I’ll continue to use the term Scrumban - guilty secret: yes I do use the word! And when I do, that’s what I mean by it.
Postscript:
You can't do Kanban in a vacuum. You need a starting point. If your starting process is based on Scrum or is Scrum-like, then according to this definition it is Scrumban. If the starting point was Prince II or XP or DSDM should you call it Princeban, XPban or DSDMban?!
What is worthy of our fear? Is Death? Surely not. He who lives will die, and such inevitability must be respected and known, yet not cause dread. No more fear taxes, since he who earns can scarce keep it all, can he, any more than he can take it with him? For what purpose would you keep it all? I grant you death and taxes should be avoided - where it's possible to do so with honesty and honour. But they are not worthy of our fear.
