The result is confusion with people asking themselves: Am I doing Kanban right? If you’re asking that then you’re misinformed on what Kanban is and how to best harness its power. It’s really very very simple.
You’ll find many definitions of Kanban out there, Joseph Hurtado provides a useful summary of alternatives, David Anderson has his own unique definition and there are many other attempts to define it, some solid and others still evolving.
I don’t like many of them much because they tend to overlook theory and jump straight to defining a cobbled-together set of activities, each one somewhat different to the others. They ignore the fact that these activities are just a small subset of many possible activities, practices, techniques that can naturally follow if you understand the simple theory behind Kanban.
Understanding the theory frees you to create your own activities, practices and techniques that may be better suited to your environment than any “standard” ones you are “supposed” to follow because they are some consultant’s or trainer’s preference. That freedom is what Kanban is really about.
Read on for freedom.
Kanban has a very simple theory at its core:
Visualising work can directly help to improve it
From this simple theory follows just 2 core practices (yes, just 2, not 5, 9 or 26!):
1. Physically visualise all end-to-end work in the system
2. Regularly use these visualisations to improve how work is done
That’s it. That’s my definition of Kanban. All else is “how”.
If you follow the theory and stick to those core practices (once you’ve explored their common consequences – see below), then you are doing Kanban.
Of course there’s a lot of interesting ways you could do those two things and plenty more you could be doing alongside, as we’ll explore. But all of those things naturally follow from this core definition of Pure Kanban.
This is really important to remember any time you might be struggling to implement a “standard practice” (oxymoron) with Kanban: Is what you are trying helping you to do these two practices? What could do you instead that might fit your needs better?
At this point, you’re probably thinking: “Yes, but what about Kanban boards, WIP limits, stand-ups, pull-not-push, etc…”.
These are all techniques that naturally follow on in some form if you stick to the central theory and core practices:
To visualise end-to-end work you immediately need a large space, like a wall or whiteboard to fit everything in. You need a way to represent work items and their place in the end-to-end workflow. A common solution is to use a Kanban Board (or “Project Board”), or as I prefer to name things by their outcomes: a “Control Board”, because that what it can give you; control of work. Or perhaps you’ll design your own improved version.
Once that is up and running, it acts as an “information radiator“: letting everyone know what is going on: live and persistently. This dramatically increases awareness and acts to improve alignment and reduce confusion.
Even without a formal mechanism, people start to visit the Kanban Board and it naturally begins to bring people to where the work is happening to understand what is going on. This in turn acts to reduce the average “distance from the work” within the organisation.
Of course, to implement the second practice people need to come together around the Kanban Board: enter daily & weekly “stand-up” meetings (everyone stands up and they last 15-20 minutes). Doing this regularly highlights the benefits of colocation (sitting the team together) which in turn pays dividends through faster communication and better collaboration. Or perhaps you’ll invent your own improved version of stand-ups.
Lots of waste is also eliminated through no longer needing to book meeting rooms, compose agendas/presentations and write up minutes. Many of the written reports to superiors/stakeholders are dropped in favour of bringing them to a regular stand-up where they get to know exactly what they need (and how they can help) without the pain of preparation.
Improving the work means constantly asking the question: “What could we do better?”. That also needs a more considered mechanism; so techniques such as retrospectives (regular structured look back at recent events), regular reviews and strategy meetings quickly become deployed.
These together with stand-ups are often found to be ideal for the live training of new team members: bringing them far faster up to speed than a training course. The best mix and learning structures for your teams will no doubt emerge; if you get on and experiment with them.
Once work is visualised it is natural to start measuring it. Obvious generic measures include throughput, cycle time (end-to-end delivery time), lead time (how long a new request will wait to be fulfilled), percentage right-first-time (key quality measure), value delivery and derived factors – e.g. The cost of delay of one item over another as an aid to prioritisation.
These are all examples of simple and direct leading measures of how well work is being done. They can directly support rapid learning and further improvement, the right ones for you will depend on your context.
With measures in place, predicting and forecasting can take place in simple, useful, broad-brush terms – that take into account the limits of current knowledge. Thus traditional expensive-to-maintain project planning artefacts (including Gantt charts) are largely dispensed with, further decreasing waste and reducing management overhead.
They are replaced with predictions of team (rather than individual) capacity, velocity and pipelines; getting much more quickly to the key information at lower cost. The precise form that suits you is something you can develop iteratively.
And of course pursuit of improving the work naturally leads to iterative working, studying its flow and a host of possible tools then appear: decreasing batch size (more smaller projects/tasks), managing work-in-progress levels (do a few things well and quickly, rather than a lot of things slowly and badly), pull-not-push together with queues (only pull a new task when you finish one), classes of service (urgent tasks get a priority route). How much each of these matters depends on your local needs.
Thinking about “process” as a BPM problem (i.e. idealised design through process flow charts) becomes replaced with live tuning of what is actually happening for faster and more incremental improvements; an approach that delivers more change more rapidly with lower risk.
The narrow functional specialisation of domain experts becomes greatly augmented and balanced by a collective understanding of the end-to-end delivery of outcomes, helping to produce T-shaped people.
Often overlooked are how much visualising work helps de-personalise tasks and promotes flexibility. Instead of individuals chasing individuals, the whole team looks at where the problems are and how they can help out with them, defusing tensions. Visualising everything also means that there is nowhere to hide, pinpointing problems much more quickly. You’ll probably spot all sorts of ways in which this could help your environment.
During the above, you might be thinking: “Are some of these techniques part of Kanban or not? Where’s the line?”. That’s not the important question. The important question is: “What will help me make a real difference to my team?”.
What I’m trying to get across is:
I’m sure some will say that what I’ve defined isn’t right, isn’t complete, doesn’t include X, Y or Z, doesn’t reference history, etc… Some have even called for a new name for Kanban to reduce the confusion.
Fine, but what I think matters is not some “official specification” but whether a concept is simple enough that people can learn and understand it quickly and be able to immediately use it to make a meaningful difference to how they work. I believe Kanban as I describe it delivers just that – without the need for anyone to go on a training course.
That’s not to say that people become experts overnight. Advice and guidance on specific techniques can certainly be useful, but let’s first dispel the mystery: there’s no great complexity here and you certainly don’t need to be “certified” to use Kanban (in fact, given all the benefits that follow, you should probably be “certified” if you don’t!).
Good luck implementing Kanban where you work. Start simple and start small and don’t be afraid to try and then learn.
Licence and Terms of Service