Dear Gemba Coach,
How can kanban be useful in software since we never produce the same part twice?
Fair point. However, we see kanban cards on Toyota cars on the assembly line when no two following cars are identical – different models, different options. The cards do two things:
- Tell you which parts to pick to assemble a unique car
- Send a resupply message for the parts bin you’re drawing from
Granted, the bins themselves are full of identical parts. But if we take a step up and think car development, we can distinguish three types of functions:
- Functions that you know how to get it right the first time because you’ve done them several times in the past – they’re repeatable.
- Functions where you’re not sure you’ll get it right the first time, but know you’ll get there in the end because it doesn’t look too hard – not repeatable, but closed problem. Closed problems are problems where you don’t have a complete solution yet, but you know you’ll find one.
- Functions where you have no idea how you’re going to solve it – or whether it’s solvable – but need to try stuff and see how it goes – nonrepeatable and open problem. Open problems are problems without any easy solution in sight, currently, and you need to explore and hope you crack it.
Kanban doesn’t help you to plan – it helps you to see problems where they are.Anything you do, whether a car, software, or writing this paper can be seen as the relative proportions of A, B, and C functions. The secret for a successful mass product is only A and B functions, and 99% A if you can, while still offering something sexy to users. To be able to do so, you need to explore new ideas with Cs offline, to learn to turn Cs into, at least, Bs.
Kanban doesn’t help you to plan – it helps you to see problems where they are. Imagine you’re working with a small team of three people: Jane, Jim, and Sue.
You’ll start by planning the work so that it comes together and does the job. The challenge at this stage is to spot the “Hail Mary Passes,” the C jobs masquerading as Bs. Kanban makes sense once you’ve taken these out and solved them before you plan the rest of the work.
When you design the work, you’ll try to arrange the jigsaw puzzle so that each person is responsible for a flow (a sequence of jobs) that the sequence makes sense in itself:
If we’re clever, we can also plan the job according to cross dependencies:
Now, once we’ve done our planning, the natural thing to do is to put all the jobs we know they’ll do eventually on each of the devs desks:
And let them get on with it:
With kanban, There’s only one job on each desk:
So that when someone struggles:
It shows and the rest of the team can come and have a look:
To understand where the snag is and why something we thought was an A turns out to be a B (quickly corrected with help) or a C (let’s take a step back and think this through).
That’s it.
It doesn’t solve the world’s problems. It doesn’t help if the plan was poorly done. It’s nothing to write home about. What it does do is avoid having people keep slogging on with an unsolved difficulty without their colleagues knowing about it.
What this does, however, is enable bringing in value by capillarity, one increment at a time, and structure learning curves for long-standing productivity. It doesn’t look like much, but it is a pivotal tool to seek economies of learning from problem-based training. Probably the most powerful idea to come out of Toyota.
Kanban is not a magical tool to smooth the flow. Kaban is a practical tool that causes you see when something is not as expected, stop, and look more deeply into how to fix it.
Obviously, if tasks are mainly Bs and Cs, kanban doesn’t make sense, because it would crash all the time and nothing would get done. But on the other hand, if all jobs are Bs and Cs, you’d better have genius devs and cross your fingers for the product to work in the end.
The question you’re asking is not so much that we never make the same part but how much of it is not the same part. For instance, I never write the same gemba coach, but many aspects of the column are predictable, such as topics, length, research time, etc. So kanban makes a lot of sense, even though each part is different (and indeed, I work with a kanban from my editor). On the other hand, to write poetry or an entire book, kanban doesn’t make sense because we don’t yet know what the pieces will be, how they come together and which are predictable and which are not.
As so like many things in lean … it depends. But the only way to know for sure is to try to put a kanban in place and see what happens. Then you’ll know more.
