Skip to main content

Kanban: How to Start; How to Scale

How to start...

Several years ago I published my shortest possible advice on "How to start using Kanban". Not being restricted by arbitrary limits like 140 characters, I would express these steps today as:
  1. See your work as a flow of value to your customer
  2. Start from where you are
  3. Visualize your work, your process and your policies
  4. Adopt validated changes that improve things
Note that the first three of these steps do not involve changing what you are currently doing, how you are doing it, who is doing it, or what their role is called. The changes are: to your viewpoint (Kanban is a way of seeing, as much as it is a way of changing); to your approach to change (in an evolutionary way, from where you are); and to the use of visualisation (to make invisible knowledge work visible, as well as the process and policies - like controlling WiP - that apply to it).

The fourth step though, is to start improving things. It's good to see that previous critics of Kanban are recognising the value of these lessons, even where some of a process's previously inviolable "rules" might be breached. Provided we have a clear idea of what makes a product, a process, or an organisation fit for purpose, and provided the changes proposed can be shown to improve things, it's foolish not to change.

Kanban is often caricatured as only being applicable to small teams (say 3-12 people), or to processes with only small work items. In fact, this process of visualising the work and process, and improving the flow of value using Kanban's general practices, is applicable across a wide range of scales, contexts, and organisational maturity.

So if you're starting from a few teams using Kanban at the team level (a reasonable place to start by the way), how do you scale to using Kanban across an organisation?

How to scale...

We can express the answer to that question with 4 quite similar steps:
  1. See your organisation as a network of inter-dependent services
  2. Scale out sequentially, service by service
  3. Design each service independently from first principles
  4. Use feedback loops through the management system to achieve balance and improve service delivery to customers
Like the first "how-to", this one starts with changing how you see. I've spoken more about this in my sessions on the Kanban Lens. The way we "see" - our instinctive way of modelling the world around us - has the greatest impact on our interpretation of new situations and ultimately our behaviour. Letting how you see change is a most powerful door into new possibilities.

Specifically "seeing services" is not instinctive. We're more likely to look at organisations through a "departmental" lens (people with similar functions or roles in the the organisation), or through a "small team" lens (the groups of people that get things done together). What is often missing is how departments and teams fit together to deliver value to the organisation's "customers". Changing to that as your default viewpoint, brings quite different issues into focus. It has a powerful impact.

Scaling out service by service again may not be management's instinctive approach. If we've found a better process, why not roll it out across the whole business together, in the shortest possible time? The answer to that question lies in Kanban's foundational principles, specifically the change management principles. These can summarised as "start from what you do now... and change in an evolutionary manner, learning and applying the lessons learned as you go." In practice, that's what the most successful organisations have found as they roll out Kanban. It is not slower to move incrementally. You get there faster because you don't generate massive fear and resistance within the organisation, and most importantly you learn as you go, while it's still not too late to apply the lessons.

If you want to know more about the third step - often referred to as STATIK (systems thinking approach to introducing Kanban), we discuss it (albeit briefly) in Essential Kanban Condensed. It's one of the main elements in the KMP 1 training syllabus - see this course from Huge.IO for example, Kanban System Design.

Finally the fourth step - using the Kanban Cadences, is the subject of the next blog (as well as the follow-on training . Watch this space.

References and Credits
Anderson, David J. 2016. "Kanban’s Change Management Principles", Lean Kanban
Anderson, David J., and Andy Carmichael. 2016. Essential Kanban Condensed. Lean Kanban University Press.
Carmichael, Andy. 2013. “How to Adopt Kanban”, Improving Projects. 2013/05/how-to-adopt-kanban.html
Carmichael, Andy. 2013. “There are 6 general practices of Kanban...”, Improving Projects.
“Kanban (development)”. Wikipedia. Retrieved July 7, 2017,


Popular posts from this blog

Does your Definition of Done allow known defects?

Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?
... the Story will contain defects of level 3 severity or less only ... Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.

Let's look at the consequences of this policy. 

Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…

Understanding Cost of Delay and its Use in Kanban

Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to maximise the flow of value to your customers.

Don Reinertsen in his book Flow [1] has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most urgent items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of urgency (or CoD) divided by the time taken to implement them. Reinertsen called this appro…

"Plan of Intent" and "Plan of Record"

Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many successful ventures and in a number of SIGs and conferences in which he is active. In spite of knowing Ron by correspondence over a long period of time it was only at JavaOne this year that we finally got together and I'm very glad we did.

Ron wrote to me after our meeting:

I told a number of people later at JavaOne, and even later that evening at the Software Engineering Management SIG, about xProcess. It really looks good. A question came up: It's a common technique in large organizations to keep a "Plan of Intent" and a "Plan of Record" - to have two project plans, one for the business partners and boss, one you actually execute to. Any support for that in xProcess?

Good question! Here's my reply...

There is support in xProcess for an arbitrary number of target levels through what we call (in the process definitions) P…