I sometimes find that teams struggle to plan with any degree of accuracy even a week or two ahead. Teams working on products with a high degree of complexity, or operating in chaotic environments (e.g. support) struggle to forward plan to a level of accuracy that adds much value. If you can’t believe in or commit to a plan — is there any reason to do it? For these teams, I find taking a leaf out of the lean cookbook can be useful and Kanban provides a simple method to do just that. Here is my quick guide on how to do it …
Lets address a common misunderstanding first …
You will notice I called Kanban a method rather than a process or framework. Kanban is an approach to visualising and optimising work within your existing workflows. As such it is complementary to your current processes. For example it is complementary too, and can be combined with, Scrum and other agile approaches. What this means in practice is that you don’t have to choose between Scrum and Kanban — you can enjoy the best of both worlds (for more details see here). In fact, many high performing Scrum teams will likely benefit from combining the two in order to understand and improve their performance further. You should definitely not see Kanban as an alternative to what you are currently doing.
So how does it work?
Kanban is super simple in theory — but it obviously gets more involved when you apply it to the real world and use it to uncover unrecognised issues. Here is a super quick summary of how to apply Kanban to your existing workflows:
- Visualise your workflow
- Limit work in progress
- Manage flow
- Make policies explicit
- Inspect and adapt your workflow
As a quick gotcha — before you start implementing Kanban — agree that pursing incremental and evolutionary change is an agreeable strategy. A “no brainer” for most, but best be on the safe side — if you can’t get buy in for change there is limited value in starting down this road …
1. Visualise your workflow
Starting with your existing workflow, visualise this in a Kanban board. As mentioned above — you are not changing to Kanban, you are using Kanban to evolve your existing workflow.
Your Kanban board may look very similar to a Scrum board, but there are some important differences.
- A Scrum board is purely focused on a team’s work within a sprint — as such, it is often a simplification of your underlying workflow and who can alter it is tightly limited to the team
- A Kanban board is likely to be a more detailed representation of the steps within your workflow — in fact it is likely to evolve and get even more detailed over time. The board also has wider ownership — it may not just be “owned” by a single team. Going forward, your Kanban board is likely to be the focus of attention in a way that is simply not the case in Scrum
Many people stop with the board and say they are doing “Kanban” — they are not. Don’t be tempted to follow the herd — the next steps are critical ….
2. Limit working progress
Chances are your workflow will have issues and bottlenecks. Let’s face it most people will be inspired/interested to adopt Scrum or Kanban because of delivery issues with there As-Is workflows. Even if you are high performing, you are likely to want to know where your workflow can be further improved.
By visualising and tracking work through the Kanban board we are likely to clearly see where our workflow is not working optimally — and generally this will take the form of work items getting stuck in a particular step for some reason or another.
To deal with this initially, we setup work in progress (WIP) limits to constrain how much work we can “pull” through specific steps in our workflows. This is a critical tool for Kanban, if you have not setup WIPs, you are probably not really doing Kanban.
3. Manage flow
In managing flows we will want to respond to blocked work, pull items into the next step at sustainable pace using any defined WIP limits, and generally keep the work items moving. We all (hopefully) know that Agile and Lean is focused on empowerment. In Kanban terms, we want to manage the flow of work not the workers. We want to keen them busy and productive, and as they know the work space better than anyone, we will let them crack on with things.
4. Make policies explicit
There are likely to be some existing policies around the work being done that need to be understood and socialised e.g. quality statements, rules etc. Sometimes these are unwritten and hence subject to a degree of interpretation. All the policies that affect the workflow steps should be made explicit so they can be consistency understood, adhered to, and ultimately adapted if required.
5. Inspect and adapt the workflow
If the above is performed just the once, you are likely to have a better understand of your workflow’s issues but that doesn’t help you improve your performance. The final ingredient to successfully applying Kanban is to ensure there are regular and frequent meetings to encourage a collaborative inspection and adaptation of the workflow. With the aim of improving throughput, these events are likely to focus on issues within the workflow and it’s constraints. Improvements could be obvious, but often a degree of experimentation will be required to opines it. This is why the buy-in for change I mentioned at the start is so important.
Key Measures
There are many metrics associated with Lean, but fundamentally they all characterise how performant the workflow is. One of the key rules underpinning Kanban is Little’ Law which draws upon an observed causation between quality and lead time — the longer the lead time, the lower the quality. Little’s Law can be defined as:
Average Cycle Time = Average Work in Progress / Average Throughput
Basically speaking, the more you take on, the longer things are going to take. Therein lies the classic management mistake of throwing more bodies at a problem (read Brooks’ “The Mythical Man-Month” book) — when things start taking too long, they start more items off which often compound the problem further.
Other important measures that people implementing Kanban will look at:
- Work in Progress — how many work items are we servicing
- Cycle Time — amount of elapsed time between when work items “start” and when they “finish”. Cycle time is a lagging indicator as it is based on what we have observed
- Work Item Age — the amount of elapsed time between when a work item “started” and the current time
- Throughput — the number of work items “finished” per unit of time.
Getting “Medieval” with Kanban
Once we have established the above, you can go as deep and scientific as you like optimising your workflows. A great place to start drilling into specific bottleneck or issues is the theory of Constraints. Ultimately, in a software development context, this will lead you to the wonderful world of DevOps where you can also find many more metrics and techniques to explore your performance even further …
Final Thoughts
Kanban is an invaluable method for examining the performance of your workflows. It is complementary to, rather than an alternative for, the way you currently work. Kanban is not going to make a poor performing workflow great overnight — so don’t expect a silver bullet. I do worry about Kanban from a phycological point of view, as I believe humans benefit from having longer term goals, and unless Kanban is coupled with something like Scrum, it can leave you feeling a bit like a hamster on a wheel. scrum.org has got some great advice on the value of the two combined even in chaotic environments like support. That said, not many people like to see wasteful processes, nor their suggestions for improvements ignores — so it can be a great place to start when change is needed.
I hope this mini guide is of value, and if you have any comments please place them in the responses section below.
