A month ago, my employer arranged two days of Kanban training.
We've long used a kanban board, so we were a little surprised to hear we weren't already "doing Kanban". Our trainer drew the distinction:
- kanban (little-k) - a representation of work flowing through your team;
- Kanban (big-k) - the act of listening to your board, using what it says to deliver value more predictably and efficiently
Fundamentally, we weren't "doing Kanban", because Kanban is not a software development process; it is a process improvement process.
Kanban is not a software development process; it is a process improvement process.
At its core, Kanban is the application of the Scientific Method to your development processes. Start with what you know, make a modest hypothesis, test, measure the result, and repeat.
There's a little more to Kanban than that, of course - there's the Kanban Method with its Six Core Practices. If you decide to use Kanban in your team, I'd recommend re-reading this definition from time to time (revisiting them just now to write this post I realise we've strayed a little).
Limit Work in Progress
The most controversial (and perhaps most well known) Kanban Practice is to Limit Work in Progress (WIP).
Software Developers like to be busy, and Managers like to see their teams hard at work. It is intuitive to prize utilisation, but Kanban tells us to optimise for throughput instead - development teams don't exist to do work - we exist to add value to the business.
This road is fully utilised.
Fully utilised teams deliver slowly. Context-switching takes its toll. Slow delivery results in slower feedback, so what you deliver is more likely to be wrong - if it's still even relevant.
Your First WIP Limit
Soon after you impose your first WIP limit, you'll hear an unfamiliar complaint: "I've got nothing to do!". The board won't let the team start another work item. Don't panic - listen to what your board is saying - look for the blockage and try to resolve it. Are there items stuck in code review? How could they be reviewed more quickly?
We haven't mentioned it so far, but there's another artifact to applying Kanban to software development - the relentless simplification of your development process model.
The effectiveness of Kanban (like the effectiveness of the Scientific Method) rests on our ability to measure our results. This is a HardProblem™, and the deeper you dig the harder it gets.
Say you want to measure your lead time for developing widgets. You have a team of six developers, building not just widgets, but sprockets, geegaws and doodads, too, and in whatever ratio happens to be selling that month. Six developers working across four task types, that's... 46 possible team/task permutations! Not to mention holidays, or sick leave...
What sense is there in measuring lead times across a fundamentally chaotic system?
The question I kept asking myself was: what sense is there in measuring lead times across a fundamentally chaotic system? Last week's widget lead time was achieved against a unique and complex backdrop of whatever else we were doing last week - what relevance can it have this week? Or next?
Our trainer had an answer - simplify your model as much as you can. Forget about your lead time for widgets, treat all work items the same - the real world subtleties and complexities will average out over time.
If you find that hard to swallow, I understand. At the end of the training many of us remained doubtful, myself included. Our trainer concluded (somewhat limply, I thought) - the only way to be convinced is to see it working; give it a go and see what happens.
30 Days of Kanban
Not everything that's intuitive is right, and not everything that's right is intuitive - the simplified model had the faintest whiff of plausibility to it, so we drank the Kool-Aid and committed to Kanban.
30 days in, it's hard to draw any firm conclusions. We've simplified our model (we could go further); we've used that model to record metrics, and we've applied those metrics to predict delivery dates. And we met those delivery dates, too: so far, so good.
It will all average out, in the end.
"It will all average out, in the end!" is the new team mantra, though we weild it with ironic desperation - whenever the software development butterfly beats her chaotic wings, gifting us another unwelcome tornado.
Whatever else, we certainly spend a lot more time talking about refining our process. But evolutionary change is maddeningly slow; we struggle to resist the temptation to meddle constantly. For now, we just have to try and be patient - to keep on gathering data, meddling modestly and observing the results.