How do we deliver value in Kanban and isn’t Kanban just about outputs?
Isn’t Kanban just about outputs? Isn’t Kanban missing a trick with value and organizational capability?
First of all, I want to give you a little bit of context because there’s a wonderful framework called evidence-based management from scrum.org and it has two aspects.
The first aspect I won’t go into so much today is about goals or your direction of travel. You can have a strategic goal, intermediate goal, a tactical goal, and they’re all good things.
But what I want to zone in on today would be the four key value areas of evidence-based management. Two of those key-value areas are about organizational capability. And two of them are about what value you’re delivering to the market.
In terms of organizational capability, what a lot of people focus on is:
- Time to market = speed, how often am I getting this product out to the market?
2. Then you’ve got ability to innovate, which I prefer to label ‘inability to innovate’. What’s slowing us down from delivering? Do we have some dysfunction in the way we’re operating? For example, if we were managing a queue of people at a border with Ukraine and there was some dysfunction in terms of the way the queue was being managed, that might be something that’s slowing us down.
In terms of value, evidence-based management looks at two other key value areas.
3. One of them is called current value, which is, metaphorically, the equivalent of milking the cow we already have.
4. Then there’s unrealized value, which is really potential value, trying to reap rewards from unmet customer needs, previously unmet customer needs and now we’re trying to reap those rewards and make those available to customers then hopefully expand our market share and so on.
So when you look at these four key value areas, current value, as in how well we’re serving the current customers, if you like. Unrealized value, the potential value that maybe we haven’t reaped yet, maybe that could be coming from new customers, not even our existing customers, but it could also be unmet needs of our existing customers, time to market, and ability to innovate.
So now let’s look at Kanban in the context of those four key value areas and let’s see how is Kanban doing and what things could you do to your Kanban that might cause harm actually to your ability to deliver value?
Kanban is a strategy to optimize the flow of value through a visual pull based system. Value in Kanban can mean customer value, end user value, could be some kind of market value, organizational value, maybe we’re cutting costs, we’re protecting the reputation of our organization, something like that.
Could be sustainable value like maybe you want to reduce plastic or we want to reduce carbon or it could be about reducing risk.
Maybe there’s a lot of risk in what we’ve already delivered to customers and maybe we need to do something a bit better. John Seddon talks about failure demand, which is the failure to do something right for the customer.
I think we need to be careful about driving things to deadlines and then basically messing up the customer experience, this is something we really need to be watching out for.
Kanban, if it’s really about delivering value, then you could have an input queue.
Some people would have a backlog and that backlog in Kanban doesn’t have to be ordered by the way. A lot of people think the backlog, has to be ordered, it actually doesn’t.
So you might select something from some input queue or options queue or whatever, and you bring those items in, you could have all sorts of ways of prioritizing that value.
You might come up with some formulas. I find they’re always wrong anyway, but you might use some kind of formula. You might rely on the highest-paid person’s opinion in the room. You could be using evidence, based on what experiments have you already run, do we already have some data that we should deliver these things?
You could use cost of delay. The jury is a bit out about whether you should use that or not. I personally find it useful.
You can use all sorts of techniques you want to prioritize something, but in Kanban, once you start something you should just finish it.
A classic error that a lot of practitioners make is they start something. And so let’s say my boss asks me to do something three weeks ago that he says is urgent. And then I get asked today to do something else. That’s the new shiny ball, the new urgent thing. And maybe the person’s forgotten about the item that was urgent three weeks ago.
That item that was urgent from three weeks ago is now rotting on my Kanban board unless I’m a good practitioner and I say, hang on a second. Let me just finish that one and then we’ll do this one. I’m not saying you shouldn’t leave frog items, but there’s a price that we pay when we allow items to get older in our system, after we started them, eventually, they will have bad cycle times. If you leave enough of those cycle times to go badly on you, then what could happen is your throughput will eventually go down and when your throughput goes down, it’s already almost too late.
It’s a long recovery and the recovery is to reduce, to focus what you’re working on and to finish items.
So a lot of people are wondering Kanban’s really about finishing stuff and that’s true to an extent. Kanban guide does support discovery and research. So it’s completely okay to have some of your items actually running experiments. Some people are just in delivery land, a couple of them they’re in feature factories and they’re delivering stuff and that’s their world and that’s fine. It’s not a very nice world to be in because you don’t know whether you’re making a difference, whether you’ve made a difference in what’s going on.
The classic mistake is that people prioritize work that’s already started. And so they’re just messing around. What they don’t realize is that the shape of their cycle times, if you imagine cycle times as shapes, there’s more frequency on one, there’s less frequency in another, it starts getting wider and wider, or you start to see longer and longer cycle times.This can be quite problematic.
If you really focus on finishing what you’ve started and if you use a policy, like for example, that focuses maybe on aged items and blocked items and items that maybe we’ve forgotten about, by keeping on top of that, that actually helps you to limit work in progress through the back door, because you might not even notice if you do have work in progress limits, you might not even notice them because you’re actually naturally going under them, because you’re focusing on finishing work.
There’s a bit of a dance, you’re not just trying to finish work, you’re also trying to make sure there’s nothing artificially aging or relatively aging compared to something else or you’re making sure that something’s blocked, to see if it’s getting unblocked, which is possible, but you also need to make sure that the system isn’t starving.
So it’s like a bit of a dance of these three kinds of compromises, a trade-off if you like, I’m oversimplifying now, but that’s the dance that you have to do to try and deliver items. The dance becomes a little bit chaotic, almost like an Irish Cèilidh when you’ve got more items in the system than people doing the work, because it means there’s always something that you’ve started that you’re not working on. This means things are aging, which means cycle times take longer, which means eventually your throughput goes down. So the sweet spot in my experience is actually lessen the number of people on the team but context is of course king. It just depends on what you’re doing. There might be some special circumstances in your situation.
The Kanban view of the world is we try to deliver things as quickly as possible, so you can get feedback sooner, so you can find out if you’d had outcomes, if they’re positive outcomes, if they’re negative outcomes, have you got outcomes? Has it actually made a difference? And that really is where Kanban helps you to deliver current value.
It also helps you with your time to market because if you’re implementing those practices of defining your workflow: here’s your work, this is how the work goes through the system, this is how we control work in progress, this is how we decide what work goes into the system, this is how we decide on a daily basis, which item we’re going to focus on today.
If we have a service level expectation saying, maybe for example, 85% of the time, items finish in 15 days or less. We have a policy almost in terms of how long things should take.
If we’re really disciplined with our Kanban, Kanban will improve your current value. And it’ll also improve your time to market.
I want to go back to evidence-based management because there’s two other key value areas that a lot of people think that maybe Kanban isn’t so good at.
One of them being inability to innovate and the other one being unrealized value.
Let’s go back to the earlier example. Imagine you’re in a queue, you’re a refugee in a queue and you’re waiting to cross the border into some country bordering with Ukraine and you’re trying to get through, and some genius has decided that there’s going to be different priority queues. There might be very good reasons for that. But they don’t realize what they’ve done actually to the queue. Believe it or not, it’s usually better for the common good, for everyone to go through the same queue and for all people who are servicing that queue to be working together on that queue.
So when people come through, it might look like a very long queue, but if the team is so focused and they’re getting through people more quickly, processing the paperwork more quickly and processing whatever donations they’re giving them more quickly, it leads to a more fluid situation.
Now, it depends on the workflow as well of course, I’m not on the ground. I don’t know what’s going on, but purely theoretically what can happen is if you start having preferential queues for going across the border while some people are getting across the border more quickly, what happens overall is the cycle times for everyone gets longer and more unpredictable actually. This means that when new people join the queue, it takes even longer and it’s less predictable. Then cheating starts happening and people are jumping queues.
In Kanban, when you’ve got work in progress and you got priorities changing in terms of what’s going on, that makes the flow even worse.
I’m not a big fan of classes of service in Kanban. Some people think it’s a good idea because it leads to preferential treatment for certain types of work. In this case, I’m talking about people in the queue. That might be a good thing or a bad thing. I don’t have enough context, purely theoretically it can cause problems if you have say this is the emergency queue, and this is the standard queue, and these people have to be across by that particular day because their passports are running out on that day. There might be very good reasons why that’s actually a good idea, particularly if their paperwork is running out of date, that might be something you need to do. You just need to be aware the trade-off is that people will take longer to process across the border and people’s lives are in danger and people joined the queue and the queue won’t be safe forever. So it’s generally better to have everyone going through the same queue.
The one class of service that I actually do like though, is intangible. Not everybody agrees with me on this. This is just my personal opinion. Intangible could be a couple of things. It could be, maybe there’s some long-term work that needs to be done at some point, but it could also be some improvement to the system. So, if for example, we understand that the queuing system for people going across the border is badly organized, the fences or the ropes aren’t working properly, or they’re not correctly protected or discipline isn’t being preserved in the queue or whatever it is. These are things that affect our ability to innovate in a sense and that way it’s making it difficult for us to actually do more work because the system needs to be improved. Then tangible work can really help you to basically improve the system. Sometimes it’s a good idea to have some work in the system that’s for improving the system for the common good if you like to make the system better. In a sense, what you could do with Kanban, it helps with your current value, helps with your time to market, you tried to finish work once it started. You can even get it to help you with your ability to innovate, you could do all sorts of improvement work basically. Long-term work that would help the system for everybody.
In terms of unrealized value, I think that’s fairly easy to sort out with Kanban as well because really unrealized value is about trying to discover what’s the next product, what’s the unmet need that we’re not serving. A lot of the time, we need to run lots of experiments to figure that out. If you over-index on it, you’re experimenting forever, and your current customers aren’t happy. You could over-index or under-index in all of these four key value areas in evidence-based management. But if you have some kind of balance in your portfolio in terms of the work, and you also do some experiments in terms of some new design that might have better flow.
Going back to my earlier example, maybe if you get over the border, but then there’s another problem. Maybe the fourth flow needs to be extended to what happens once people cross the border, how are they handled? Where do they get their food? How do they rest? How do they get served in buses if they do that?
Maybe we can extend the workflow, things that we can improve, and we can do experiments on that as well in terms of how we can make that better. So it’s a bit of a stretch using the example at the border, but I’m hoping it kind of rings some bells with people.
So for me, Kanban isn’t about outputs, it’s a strategy to help you to optimize the flow of value.It does that really well. I’ve seen it time and time again, not only does it deliver more value, people have more time to think and hopefully they produce better quality, which might also improve ability to innovate, what I call ‘inability to innovate’ because we’re delivering better quality.
Maybe we’re not getting less noise coming back into the system about things we didn’t do right the first time.
As a wise man said to me years ago, take the time it takes so it takes less time.
https://linktr.ee/johncolemanxagility — social and podcast links
https://linkpop.com/orderlydisruption — order training from right here
