Recorded at Lean Agile Manchester on 21st June 2017
Matt Turner delivers a lightning talk called Selling WIP limits with a single drop of H2O
My talk is selling lip wimits, lip wimits, I can't say it. Selling WIP limits with a single drop of H20. My background is in helping IT ops teams that have large volumes, lots of demand. A few people have heard me say this before when I've been up here in the pit, helping them use Kanban. I've been practising in terms of practising with the stabilisers on and stuff like that, practising Kanban for a number of years. And I've worked with a lot of teams that have demand that's shaped like that. Full on at them.
So, for me I'd probably say, for a long while, I was doing Kanban sort of well. Doing lots of aspects of Kanban, but I always didn't never really needed to go into this thing. How do you do it? It's not a test. I'm not going to shout like Sunil did. It's not a test. I didn't know what this was until someone told me either. That's the Little's Law. So the whole thing about limiting WIP for a reason, other than Little WIP Limited, other than me going to teams and saying, you know, that easy question where they can all get involved and say yes to me. 'You've got too much work, haven't you?' And they'd all say in the teams that I was dealing with, they'd all say, 'Yes, yes, yes, yes, yes.'
So that was never really a big sell, and it was always a bit of a 'Oh, what does that mean?' Especially in terms of the fact that the confusing part that's WIP, and that's lead sign. Just like, I can't really, it doesn't trip off the tongue. There's this whole sort of theory around, you should limit WIP, and then you will get more out of, you'll shrink your lead time, and you might get more throughput and so on.
But of late, what's been really, really nice for me, and this is why it's a nice thing to come and share. Of late, I've been working with more development teams, I'm moving more away from IT ops. I'm combining the two action. I'm bringing IT ops teams together with dev teams and helping them understand one another a bit more.
Having the opportunity to work with dev teams is really, really nice. What I'm finding now is, I'm working with more dev teams that are very, very comfortable with things like Scrum. I've got a few at the moment that I'm working with and they're very comfortable with the elements of Scrum, the practises of Scrum, the ceremonies. They like delivering cricket because before Scrum, they didn't have anything, they had Waterfall.
Even in terms of Scrum and at Timebox and agreeing to deliver certain things, that's them limits in width, so they're getting a load of that stuff, a load of good, agile stuff. But in the three teams I'm working at the moment, there are two that their demand channels are too much.
There's one that's really, really happy with Scrum and the others, they're starting to think like, 'What are these width limits?' And it's alright to say, 'Come in and do this till we turn it into that, to make a little bit more sense in the equation.'
You've got your lead time, is your width divided by your throughput, and it makes it a little bit better than the whole Lander thing and the L and the W. But they really need some sort of story. What does that mean? Some sort of emblem for helping them to understand that this basically, got a load of people giving them work and when people give you work, their second question is always, exactly, 'How quick? Give it me now. How quick?'
What I've done with them, in that they're interested, and they understand that there is a relationship here, but how do you explain it properly, that they can really feel like, 'Right, we'll take the risk and we'll start to limit this width.'?
The easiest ones for me was, and the ones that made the most pennies drop, was you have some H20. You have a bucket and it's filling up and ... Where's my blue? I'd use a blue here. Oh, it's in my other hand. There it is, hiding. You have a bunch of water in here, and you might have water coming in here, that may be truly is and you've got water flowing out at two litres per hour. You might have five litres in here.
I've done this the wrong way around. Let's have twenty litres in here. There's lots, there's lots and lots of ... This is our work in progress. The throughput is two litres per hour, which means our lead time, twenty litres, which means our lead time is going to be ten hours. That's the pretty simple equation to understand.
What we want to is, we want to limit width, and why? What does that do to us? Let's say we've got the five litres, and let's say we've got water still coming in, that's two litres per hour, and going out as two litres per hour. So our throughput is still the same, but with five litres worth of width, we've got five, we've got to this lead time now becomes two and a half hours.
For that water, for that particle, that little drop of H20 to go through here and effectively for that whole lot of water to be new, to be replenished and everything else to go out, it's gonna take us two and a half hours. Our throughput might be the same, but everything's taking less time.
When we take less time, then we're delivering more value because we're getting to things quicker. That's why when people ask us that question, the second question they always ask is, 'When can it be done?' They always want the quickest answer.
That wasn't rehearsed by the way, it may have come out like that. It was a last-minute call, but I hope that might help with some people, explaining teams to WIP, that simple equation, how that works. It always seems to me to be something that's a little more simple than backwards, LW and Lander.
Thank you very much.