How a Product Team is improving value delivery rate with Kanban

Here are my slides from #lkuk14. Full video available soon from Lean Kanban UK.

x-Banning a process

I've just proposed an experience paper for LKUK14 - "x-Ban the process! (or how a product team is improving value delivery rate with Kanban)". Feel free to vote for it by the way here!

Scrumban, Xanpan (XP-ban) - even Prince-ban and DSDM-ban - have all been used as portmanteau words to explain the journeys from a particular named process or framework to a continually evolving and improving process, guided by the principles and practices of Kanban. If you are trying to apply a named process but frustrated by a patchy track-record of improvement, consider the alternative: x-Ban it!

When I was asked in early 2013 if I would work with Clearvision's product development team, they had just adopted Scrum (a matter of weeks before). Their process, like most I've reviewed from teams claiming to use Scrum, was not compliant with a large number of Scrum rules. It was pragmatic, constrained, variably applied and ripe for improvement... but it certainly wasn't Scrum. We had two choices - apply Scrum rules as soon as possible (defining the backlog of necessary changes and a timetable to apply them), or “x-Ban” it (use Kanban to attain evolutionary changes that we kept only if we were confident they resulted in improvements). We did the latter.

There are many lessons I've learned from this experience: some things that worked - and some that didn’t. They're lessons and general principles that others can apply on a similar journey. It has taken much longer to adopt some practices than I expected, the current process is quite different than I expected when I started 18 months ago (it’s more Scrum-like now than when I arrived for example!), but it is a route I would recommend to others.

Start x-Banning your process now!

What is Kanban?

"What is Kanban?" you ask.

Well really that is three questions. Firstly what is a kanban?

1. A kanban is a visual signal.

It is a Japanese term meaning a card, brand or sign. In lean production systems it's used as the signal to an upstream part of the process that items are required by a downstream part of the process.

Which leads to the next question. What is a kanban system?

2. A kanban system is a system for managing work that uses (real or virtual) kanbans to control the flow.

Kanban systems were first used in Toyota for manufacturing but are now widely used in a wide variety of applications including health services and knowledge-based work such as software development. In principle a kanban system is a "pull-system" where work is triggered by demand from a downstream part of the process - ultimately by the demand of the consumer or commissioner of the product. The systems use kanban signals to prevent over or under production in various parts of the process. The kanbans may be "real", for example an empty hopper which is sent back on the production line to indicate that more parts of a given type are needed, or "virtual", such as the signals derived from a kanban board when a "story card" is moved out of a column. In both cases they indicate to the upstream process that another item should be produced, processed or selected.

"But hang on! I thought Kanban was a method."

You're right. That's the third question, the third part of what is Kanban. To be crystal clear, we should ask "What is the Kanban Method?"

3. The Kanban Method is an approach to defining and improving kanban systems.

The Kanban Method emerged from work being done by many practitioners in software management, agile and lean methods and new product development  during the first decade of this century. The author of the method was David Anderson, but many others contributed or were doing similar work which fed into the method, including Drago Dumitriu, Jim Benson (co-author of Personal Kanban), Don Reinertsen (author of Flow), Karl Scotland, Corey Ladas (author of Scrumban), Alan Shalloway, Arne Rooke, Mattias Skarin... there are many more than I know about. Kanban was first formulated as a method in a paper presented by Anderson at the Agile 2007 conference in Washington DC, and in 2010 Anderson published what is still the principal authoritative text on the method, "Kanban: Successful evolutionary change for your technology business".

As Alistair Cockburn has observed the word "method" may confuse here - he suggests "reflective improvement framework" is closer to the intention (if it weren't such a mouthful I might agree with him!). I would say Kanban is a method, but a method for defining and improving a process, not the process itself or even a process framework. As such people are often confused by what they think are properties of the Kanban Method, whereas in fact they are simply characteristics of a particular kanban system that they have observed. Try not to be confused or you may miss the crucial value that Kanban can bring to your organisation - continuous evolutionary improvement. A method such as Scrumban for example is an application of the Kanban method to a process that starts off as Scrum or Scrum-like. Scrumban is Kanban, but in a particular context!

Elsewhere in this blog I discussed my shortest possible guide to adopting Kanban, based on the underlying paradigm, the principles and the practices of the Kanban Method. Here it is again:

1. Change your viewpoint (lean flow paradigm):
   See work as flow
2. Change your mindset (foundational principles):
   Start from here and improve
3. Change your process continually (core practices):
   Make work and policies visible; make validated improvements

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?!

Scrumban - How to win friends and influence people?

My guess is that Ladas provokes extremes of like or dislike to his writing, depending on whether you happen to agree with him or not. Nevertheless I fall in the middle (well three and half stars rounded up perhaps!) as, while I do find the uncompromising ridicule of non-lean/less-lean processes somewhat wearing, I do think he's got some important ideas to share.

So I'm with the author on the main thrust of his argument, but just to dismiss eXtreme Programming for example as a reinterpretation of the V-model, seems less than just for one of the key advancing influences for agile in the first decade of this century. Similarly Scrum comes in for some merciless treatment - many people are going hate this book on an emotional level long before they parse the content - and especially if they interpreted the title as a description of an agile method that combines elements of Scrum and Kanban. That's not what Ladas means by Scrumban. He's discussing instead what evolution of process would take place if a team was using Scrum and adopted Kanban, while relaxing Scrum's rule-immutability. His answer is that many of Scrum's practices will change and you will end up with a much leaner process, with less work-in-progress, and independent cadences for queue replenishment, improvement events and releases. In other words you end up with a typical Kanban system. Hmmm... take care what you assume is in this book when you read the title!

Any way if you can get past his style, Ladas gives us some very interesting observations on Lean software development systems. In particular I found the "feature brigade" section fascinating - a discussion of how a Kanban process for software development could be built by analogy to a fire brigade's chain of buckets. The point about such a system is that it is self-levelling, since the point at which the fireman with an empty bucket meets the one with the full bucket is variable, depending on the current rate of working of the two participants. Such self-levelling of Kanban systems, if it can be achieved with simple feedback mechanisms like this, will lead to real advantages as they are scaled.

This is an idea worth persevering with the book for!