There are no flavours of Scrum

Here's a great posting from Jem D'jelal on the trials and tribulations of a London Scrum Master "Since When Did Ben & Jerry's Create Scrum?" I smiled throughout and recognised some of the frustrating situations that I also hit as a Scrum Master. However I realised Jem was also eloquently expounding some of my uneasiness with Scrum. Here's the stand-out section for me:

Whoever you are, please read and repeat the following mantra after me:

There are no flavours of Scrum. 

There is no chocolate flavoured Scrum.

There is no Caramel chew chew flavour of Scrum.

Scrum is not an ice cream.

It does not come in bloody flavours.

If you want to pick an Agile framework, methodology, technique, or approach which comes in different flavours, go for one which is less prescriptive than Scrum. That is completely fine. Kanban for one example (There are only 2 principles, it leaves almost everything open. The only rules are you need to visualize your workflow and limit your WIP).

But Scrum does have rules... if you do not follow these 9 rules then you are not doing a different ‘flavour’ of Scrum – you are simply NOT doing Scrum.

But doesn't this make you uneasy Jem? Don’t you worry (like me) that as agilists we want to embrace change while at the same time saying these particular practices are eternal? Many changes from a good method like Scrum are bad (measured say by a reduction in the flow of value in this context). But does that imply every conceivable change, even from a process that is working exceptionally well, will always be bad?

And where does the idea come from that Kanban has two principles (see my post "There are 3, no make that 4... no really, shouldn't it be 3 Principles of Kanban?"). The two rules (i.e. practices that if you are not doing, you are definitely not doing Kanban) come from Jim Benson's Personal Kanban book which is just the starting point of exploring this method. Don't be fooled this sums up the whole approach. (These "rules" are the first two of the six practices of Kanban.)

Since none of the principles of Kanban (whether there are 2, 3 or 4) mention WIP or visualisation shouldn't we take a look at the principle that is relevant here, and the one that makes me comfortable to be a Scrum Master using Scrum with all its rules intact (except the one about the rules being immutable).

The principle is “agree to pursue evolutionary change”. This implies you’ll try some changes that don’t work and don’t get amplified. But also if some changes work, you’ll amplify them even if they break the previous policy you were applying.

We use this in the Retrospective (which incidentally we still do every Sprint) to encourage each other to find small changes - for example to the Definition of Done (DoD) - that might improve the situation we're in. For instance if there are too many bugs coming back at us from the Release process or the field, we ask whether a tighter DoD might help. If the change works we keep it and tell other people about it (select, amplify). If we can't tell whether it's better, we'll probably keep it (diversity in the ecosystem). If it makes things worse we regress (deselect). In other words we're using an evolutionary change mechanism.

Our Scrum team limits work in progress by not putting too much into the Sprint Backlog and by focusing on finishing stories we've started rather than starting new ones. And we visualise most of our work using a Scrum board and burndown charts. Why should anyone tell me I am not using both Scrum and Kanban just because there's one Scrum rule that I refuse to accept in my context... that the rules are immutable?

Now our use of Kanban is not very deep at this point and there are several practices where we're certainly deficient. (Not following all the Kanban practices doesn't mean we are not doing Kanban by the way, which is a key difference from Scrum). Take Kanban practice number 3:"Manage Flow". We've begun to gather metrics on elapsed time for stories from entering In Progress to Done (Development Lead Time), but we haven't gone wider yet in the value flow, nor used this to ensure smoother and more flow-efficient ways all the way from "bright idea" to released, which is our ambition. There should be some good improvements we can get here in the future.

I admit after some period of time of changing our process, you may tell me Jem that I'm not even using a flavour of Scrum, it's just not Scrum. Probably at that point I won't mind too much (unless of course you were to interview me and not give me a job as a result!).

What is Scrumban?

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":

1. See work as flow (Lean Flow Paradigm)
2. Start from here and improve (Foundational Principles)
3. 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?!