This is a transcript of episode 125 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Clarke Ching has been studying bottlenecks and constraints for thirty years, and has lots of stories and insights for us. He explains why bottlenecks are important, why your developers should always be your bottleneck, and how to explain the theory of constraints using a herd of buffalo.
Show links: Our Sloan Management Review article
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:14
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi Squirrel.
Squirrel: And hi there, Clarke. We have a special guest today, Clarke Ching, who is known as The Bottleneck Guy. We’re gonna talk to him about all kinds of things to do with bottlenecks…and drums and buffers and ropes and theory of constraints and all kinds of good stuff. Before that, we did want to let listeners know that just yesterday we were in the Frontiers section of M.I.T. Sloan Management Review, with an article on siloed I.T.; which is really actually about walled gardens and one of our favourite theories we’ve talked about here before, and some of the difficulties that come up for your Agile team when they wall themselves off. So if you’re interested in that check the show notes, or just search for ‘Walled Garden’ and us and Sloan, we’re very excited and proud to have made our way into that prestigious journal. Right! So we have Clarke with us, all the way from New Zealand, where I hear it’s cold. He is shivering in his house because it’s winter there, which is very strange for us. Clark is an internationally known expert on bottlenecks, constraints, all of that kind of thing. So, Clark, do you want to give us a more proper introduction? Tell us about yourself and what you’re interested in!
Clarke: Yes, Hi, Hello. Lovely. First off, congratulations on your article. That’s a rather prestigious! Good service to the world, too. Lovely. So, my name’s Clarke Ching. I am in New Zealand. We’re in the future at the moment! It is winter and we’re a day ahead of you and it’s cold and I’m just out of my bed. So if I start shivering, that’ll be the funny sound. So the thing I’m best known for is I’ve been doing the Theory of Constraints since the 90s. I stumbled in to Agile in about 2002 to 2003. So I have come at Agile from an unusual background in that I already knew a lot about Lean. I already knew a lot about the quality movement. Already knew a lot about, you know, a lot of logistical clever stuff that has kind of now sort of snuck into Agile over time. And I came to Agile as a programmer who became a project manager, who became a business analyst, who became a consultant. So I’ve got this whole big mix of stuff going in there. But the thing I’m known for is the Theory of Constraints. And my last little book, I think you have a wee note in your show notes if anyone wants a free copy of it, it’s called The Bottleneck Rules. And the link to it is SHARE.TOC.GUIDE and it’s been in The Spectator magazine, its been in The Guardian. And just for a couple of days it was the second best selling leadership book on Amazon.com. And if Stephen Covey wasn’t already dead I probably would have had to go out and…we’ll leave that.
Jeffrey: See you could move yourself up in the ranks?
Squirrel: No threats on the podcast. Cool.
What is a Bottleneck?
Listen to this section at 03:29
Squirrel: But what is a bottleneck? So the book’s about bottleneck rules. That’s what you’ve been doing for what sounds like 30 years. Can you tell our listeners what do you mean by a bottleneck? And why should they matter to an Agile team?
Clarke: Okay. So every team, every workplace, no matter what you do or where you are has a bottleneck. The bottleneck is the narrowest point in the flow. If you actually literally grab a bottle and look at it, and whatever it got inside, then turn it upside down? The bottle’s neck limits how fast that stuff will flow out. So, like, if you’ve got a little bottle of Tobasco sauce and you shake that out, the neck is deliberately very narrow and it controls the flow. If you have a bottle of wine, much wider neck, you pour that out and the wine will come out faster. They’re really handy, though, because bottlenecks control the flow and they’re a good thing. if you know you have one, and you are managing it. But if you don’t know you have one, then it’s actually managing you, because you do have one. You do have a bottleneck. But if you’re not managing it, then what it’s doing is it’s sitting there very sneakily causing lots of rework, causing lots of stress, slowing everything down and really limiting your productivity. But because you don’t know it’s there and you don’t know that that’s what the cause is, you blame each other and you blame other things.
Squirrel: So what would cause rework? How would that work in an Agile team? I’m working away with the rest of my team. Why would I be getting rework as a result of having, as you say, the necessary thing, a bottleneck? Somebody is a little slower than everybody else.
Clarke: Right. So a lot of rework comes from cutting corners. OK? So you’re in a rush. You don’t do something right. So it could be perhaps an analyst. An analyst is working on stuff, but the analys is the bottleneck, they’re the slowest. And so the rest of the team is saying, ‘Hey, speed up, speed up, speed up, come on feed us, feed us fuel!’ You’ve got hungry developers there. ‘Feed us fuel!’ So that the analys goes. ‘Oh, great. Okay. I need to go faster. What will I do? Oh! I’ll cut a corner.’ And they’ll hand something over and it might not look like it’s wrong, but with a little bit more thought, you know–which is our main tool, thinking–they could save a lot of rework because it goes through the developers, gets tested, the tester looks at it as well. Thinks, ‘that’s not right.’ Comes back and they have a bit more chat. They had that thought after its been built, and they realised a change could have been prevented.
Why Busy is Bad
Listen to this section at 06:21
Clarke: So it’s really common. There could be variations on it. Say the testers testing is your bottleneck resource. And again, you’re under pressure. You’re under pressure. You’re under pressure. So there’s two sources there. One is that the testers go ‘Okay. I’ve tested it.’’ And maybe they’re not as thorough they could be. And then a defect gets found later when it’s a lot more expensive and hard to fix. Or maybe when the tester is the bottleneck, the developer’s going ‘I need test feedback. Give them to the testers.’ But they can’t keep up, they’re not fast enough. So they will start something else. So they start something before it’s ready and then they increase WIP. And that leads to a whole lot of chain of cause and effect. That increases not only WIP, but it slows everything down. And it actually in turn, hides the bottleneck. So there’s a whole lot of very complicated stuff that happens because it’s hidden and it’s happening inside people’s heads so we can’t see it.
Squirrel: Got it. And you used a term there that our listeners might not know which is WIP. And that stands for a work in progress.
Clarke: It does indeed! Well in the old days. It used to be work in process or work in progress.
Squirrel: And I never know which one. You’re the expert. I’ll try.
Clarke: I never know! No, I don’t know. I don’t know.
Squirrel: Okay, then I won’t feel bad if I don’t get it right. But it’s stuff that you’re working on that maybe is the backlog for that analyst or the list of features that the testers are trying to test. And that gets longer and longer because they’re a bottleneck. And the other thing that it seems like is if I understood you correctly, when the rework starts happening, the rework makes the bottleneck worse because the testers suddenly have more to do. They have to test the old thing that was broken that they released, and then they have to test the new stuff to try to catch up. So they’re going to take even more shortcuts. This feels like a vicious circle to me.
Clarke: Absolutely. The secondary and tertiary effects that that happen because of this come back to bite us. But because it’s time delayed, we don’t realise that the cause is just so often, simply, that one of the resource types in our software development process is slower than the others. It has less capacity relative to the others, but everyone else keeps busy. And if you look at a team and everyone’s busy, it means that they’re actually not productive. That’s not some opinion, that’s a fact. If everyone is busy, then that means by definition, the team is not as productive as it should be because all they’re doing is starting stuff, but they’re not able to finish it any faster because the bottleneck limits the capacity, limits the throughput. And when you can just suddenly go, ‘Wow, oh, wow! Bottleneck. Oh.’ You start to see things entirely differently. You remember that movie with Bruce Willis in it and the little boy that could see ghosts?
Jeffrey: The Sixth Sense.
Clarke: The Sixth Sense. He had a sixth sense, which I find hard to say this early in the morning. He had a sixth sense where he could see ghosts and you watch that movie and then you get to the end of it. And so–spoiler alert, even though this is probably 20 years ago now–
Squirrel: It’s old enough, I think we’re safe.
Clarke: We’re safe! You get to the end of the movie and you get, ‘oh, wow, he can see ghosts’ and then you go back and you play that movie back and you watch it again later. But you know about ghosts and it’s an entirely different movie. You go have a look at a development team before they know about bottlenecks and then look at them after. Once they do, they see how things work together so much more differently. Just through that one little bit of knowledge.
Squirrel: Is it just a matter of telling them? Once you know about it, you’re magically able to avoid bottlenecks? Or are there skills and tools and things that you need to know about?
Clarke: So it’s actually really hard, well, no, that’s not true. It’s hard in that we have to fight this thing: to keep people busy. We are all wired to be busy. And if we’re not busy, we actually find it difficult. It is a medical–my wife’s a psychiatrist and she works with old people, and she says that sometimes when they have dementia, some people will just carry this need to be busy with them. They might lose so many other faculties, but they have to keep busy. And they call it Utilisation Syndrome. Got to keep busy. So if it’s built into us and even though logically I know that not everyone has to be busy, I find that very difficult. I think everyone does. So there’s kind of like the bad guy. There’s the enemy that we have to fight, our true natures.
A Learning Experience
Listen to this section at 11:24
Clarke: I’ll tell you a story. I had about 120 people working on a project. I came in, I found the bottleneck. It was testing. Over time, I moved it to development, or the team moved it to development, and it took a few months. Development’s the right place for a bottleneck. If you’ve got it there, you want to keep it there. And then they realised–I think this might play into your walled garden analogy if I have read it–eventually, they got the team set up right. Analysts weren’t at the bottleneck, they could feed the developers good quality stuff. Testers could test really quickly. Perfect. That’s exactly what you want. And then they had a new customer come in and the customer, the internal sponsor, the Uber product owner, he was new to this organisation and he hadn’t seen what they did. He also had two jobs! So he was actually the bottleneck for this 120 development team project. And he was torn between doing his day job, which has urgent needs and urgent effects, if he doesn’t get his day job people performing that means, you know, another 200 people in a call centre. So he didn’t do a very good job. He was the bottleneck in terms of the flow of work into the development team. And so the development team knew that this was happening. The manager went and talked to him. The new guy didn’t like being talked to and asked to do this. He was in a bind. He didn’t know how to operate with the team. So he pushed back. In fact, he did two things. One is he just started feeding them low value stuff that will keep them busy, but didn’t require much input from him and his team, which is really common. So you look at the development team, ‘hey, look, they’re really busy. Great. Excellent.’ But they’re working on low value stuff, which is just so sad because it looks like it’s really productive. And that’s why people say Agile’s slow. You know, they’re really busy. But the slow is working on low value stuff, it’s that low value stuff that takes a long time. And the second thing was that he pushed back. They got in a fight. He demanded with the programme manager to implement utilisation measurements across the I.T. team because they were so slow.
Squirrel: Because of course, if they were busier, that would be better.
Clarke: Got to have them busy. So he got everyone.
Squirrel: But in fact, as we’ve just been discussing, busy is bad. We don’t want busy. So we’re measuring for something we don’t want. Okay. I’ve heard this story before. But I’m not sure where it’s going to end, so how does it end?
Clarke: So what happens is that all the good work kind of just just slowly crumbled away. The customer became convinced because the evidence showed him that although everyone there was, say, 80% busy, they were just still really, really, really sluggish. The relationship between I.T. and the customer. It got worse and worse and worse. The team got busier and busier and busier and slower and slower and slower. They couldn’t focus on running it correctly because they were just so busy trying to fill this spreadsheet to prove how well utilised and productive they were. And it’s actually a huge disappointment for me because it was my one of my great success stories when it hits a book at some stage, depending on whether it’s fiction or non-fiction. In the non-fiction version, they couldn’t fix it. It just became too unpleasant, too hard to fix. The project eventually sort of wound down, and that was it. In the fiction version, the programme manager. Will be a slightly stronger character than he was in real life. And he will sit down and say, no, actually you guys who go to work together, your job is to make sure we do this. Let’s make it easy for you. We’re not measuring utilisation. But if you look at it, that’s part of my learning. I didn’t give them enough understanding so that the managers could actually have that conversation. I’ve grown up a lot since then. Unfortunately, you learn this stuff by doing it badly when you’re younger.
Jeffrey: It sounds like the your character in the book may have gotten a good copy of Agile Conversations to help him with that difficult conversation. Help build a relationship.
Clarke: Yeah. You know the skill set that is most missing in I.T.? I think you take the knowledge from theory of constraints. I think there is a huge amount. But then the skill set that’s missing is the ability for managers in particular and leaders, if you prefer that angle, to have hard, difficult, grown up conversations with their customers and with their I.T. teams about what’s right. So I love that the gist of your book is, I think, targeting the one weakness. And I’ve always used this analogy of the Rambo movie. Remember, John Rambo comes back from war and he excelled as a soldier. He comes back. He can’t cope in civilian life. Often a lot of managers in I.T. and in the business, they’ve been at war. They’ve spent years at war with each other. So they’ve gotten really, really good at that. And so learning how to have peacetime conversations or peace talks, to rebuild trust is not in their skill set. So I think it’s wonderful you’ve written your book. I hope everyone reads it because it is a huge gap and it’s a skills that you can learn over time. Often we can’t learn it from the people we work with because they either don’t have those skills or they don’t know how to teach them. So good work on that.
Jeffrey: Thank you. And certainly we like this combination: you need the knowledge of how to have the conversations, you also need the knowledge of what to do. And as you say, coming back to the bottlenecks for a minute, even if you have the conversations you need to have the skills. You’re in a situation where the skill which that team had was knowledge of theory of constraints, knowledge of bottlenecks. People who have listened to us may have knowledge of conversations, but maybe not knowledge of bottleneck or of the Theory of Constraints. When you first introduce these concepts to a team, where do people start?
Clarke: So you have one bottleneck. The first step is to find it. Now, the way I find it, can I tell you the exact words I use to talk about it?
Jeffrey: Absolutely, please do.
Finding the Bottleneck
Listen to this section at 18:42
Clarke: Okay. So I tell them a joke, and I have found that this joke–it’s quite funny–but what it does is it explains the ideas of limiting work and of finding your bottleneck. And how a team or an entire workplace runs at the speed of the bottleneck, via a joke. So you remember the Cheers TV programme.
Jeffrey: Norm!
Clarke: Norm! Exactly. I teach this stuff at business school over here. And I say that. And they all look at me going ‘What? Huh?’
Squirrel: The younger ones don’t know.
Clarke: Shocking!
Squirrel: By the way, anyone who is having trouble with the accent, it’s Cheers.
Clarke: Cheers. I said it properly, I assure you.
Squirrel: You did absolutely but it still sounded like ‘Chairs’ to Americans. Anyway, carry on.
Clarke: Indeed. So this never actually happens in that TV programme. But in the early 2000s, it was a joke that went around via email, which is also an unusual thing for a lot of people these days. But it went round by email and it sums up TOC Bottleneck Management beautifully. So Cliff Clavin, who’s the unusual postman, walks into the bar and he says, ‘Norm, Norm, Norm, Norm. Did you know that when buffalo, meaning bison, when buffalo roam across the plains they run. The entire herd will run at the speed of the slowest buffalo. Obviously Right? Because otherwise they’re spread apart. And then they’ll be very easily attacked if they’re individuals. And they so they roam together and they run at the speed of this last one. And that speed, the slowest one stays at the back and the rest of the herd runs in front. But at the same speed of the slowest one at the back.’ Oh, OK. Right. And he says ‘did you know that when they run like that. Not only do they keep together, but they have an improvement mechanism built in. Which is that wolves find it easiest to attack the herd from the back. The safest place to attack. So what they do is they attack and they take out the slowest buffalo: the guy at the back, which is very sad for grandma, but it makes the whole herd stronger; the whole herd can run off, because now the slowest buffalo is faster than the previous one. So it’s an interesting, well-known scientific fact that when we drink alcohol, it kills brain cells. And naturally, because this is how nature works. Like with the buffalo, it kills the slowest brain cells and they’re the ones at the back. And this, Norm, is why you why drinking beer always makes you more intelligent because it kills the slowest brain cells.’ So I tell that joke, you know. It’s moderately funny, but there’s a lovely effect to telling a joke versus telling a fact. Tell it to a group and they all go ‘ha ha ha,’ and then they point to the big drinker or drinkers in the group and they will have a little bit of a laugh. And then they look back at me, go ‘Why has he told this story? What was going on?’ I said, ‘Well do you guys have a slowest buffalo?’ And they always got oh, they always look at the testers–because it’s almost always the testers–and they look at them going ‘Oh, that’s you guys.’ Okay, so what would you do?
Squirrel: I hope you don’t tell them to kill the testers.
Jeffrey: Feed them to the wolves.
Squirrel: Kill the slowest tester!
Clarke: Someone always says that. Yeah. And then they have a second laugh. And there’s something about laughing like that, especially the one-two laugh that gets people so it’s almost like they are in the pub, and they’re sitting round and they’re having a little bit of fun and the whole mood changes, and they go into this very creative kind of collaborative problem solving thing. And at that stage, my work is usually done. Now, I’ve got to tell you this. I’ve been telling that story for probably 20 years. 18 of them to Agile people. And only once have I been told this answer when I asked them, ‘well, how do you speed them up?’ Normally someone says ‘well, shoot them, shoot the testers.’ Someone says, ‘Oh, give them alcohol.’
Squirrel: Fantastic. Our listeners should consider drinking as a solution to their Agile problems.
Clarke: Yeah. Yeah.
Squirrel: OK. You heard it here. This is Clarke’s official advice. No, I’m sure that your official advice is read your book and understand the bottleneck. And by just understanding things like the slowest buffalo rule, you’re going to get to the stage where you can actually eliminate your bottleneck or manage it more successfully. And that’s going to help you.
Clarke: And that’s it. Can I tell you really quickly?
Squirrel: Yeah.
Clarke: So there’s a strategic version of this. And this is what I teach. And it’s not obvious, you can’t find it in any other book. But I’ll tell you what the strategy is. The tactics take a lot longer to get there. But the strategy is you always want your bottleneck to be development. And when it becomes development, that means that everyone upstream has time to do the job properly, provide high quality, high value fuel into the developers. And it means that the developers get fast feedback from the testers because they have the capacity to do their job well and give fast feedback. Any other arrangement results in the developers having spare time and making themselves busy. And that’s really, really bad. So quite often, if I give a talk about this, I often get notes back from people and they almost always say the same thing. ‘Hey, we were going slow. We just got money to get some more developers. We heard your talk and we realised that testers were a bottleneck. So adding more developers would actually make the situation worse.’ And it’s really counterintuitive. If you want to get more development done, make sure that you have the resource capacity. Make sure that everyone that’s before them and after them has enough time to do their job properly.
Squirrel: That will actually speed you up instead of making you slower.
Clarke: Yep! You will not need to spend any money. You just think yourself into that position over time. But don’t get more developers. No offence to all the developers in the world, but the developers need the right inputs and the right support from testing to do their job properly. And it’s really disrespectful not to because otherwise it just puts them in very busy teams that are just getting slower and slower and slower, and it’s so counterintuitive, but don’t get more developers to speed up. When you get your developers to be the bottleneck? Protect that. And my little story of the 120 people, that devastating, truthful story. I didn’t do enough to protect the bottleneck once it got there, because I thought once it got there, it would stay.
Squirrel: Got it. Ok, well, those are fantastic stories. Some good ideas for our listeners to pick up on. We couldn’t possibly cover all the ideas. We didn’t even get to drums and buffers and ropes, which is one of my favourite topics from Theory of Constraints. But I’m sure all that’s in your various books, including The Bottleneck Rules which listeners can get a copy of at the link in the show notes. Clarke, anything else you’d like to say to listeners, any place they can find you? What’s your favourite way to hear from our listeners if they want to hear more?
Clarke: Come and find me on LinkedIn. I used to hate LinkedIn. But now I actually find that it’s got a lovely little format where I could share short posts every day and I get everyday notes back from people that they kind of like the angle of what I’ve shared. So if you kind of like the stuff I’m talking about, it’s a really easy way just to get a little tiny drip of this stuff. And just joined up. Say hello. I’d love to say hello to anyone on LinkedIn.
Squirrel: Fantastic.
Jeffrey: Link in the show notes.
Squirrel: Indeed. Show notes will have a link to Clarke’s LinkedIn and other places to find him and a copy of his book and other fantastic stuff. Thanks very much for being with us.
Clarke: That’s lovely. Thank you.
Squirrel: Sure. If listeners are interested in getting touch with us about these topics, you can always find us on ConversationalTransformation.com. There’s links to the Agile Conversations book, our Twitter feeds, our videos, the Sloane article, all kinds of fantastic stuff is there, lots of it free. So feel free to visit us, find us, get in touch with us. And of course, we also like it when listeners hit the subscribe button. Whatever kind of tool you’re using to listen to us, if you use the subscribe button, you’ll get to hear us every Wednesday. We’ve been coming out for one hundred and twenty five episodes. I’m sure we’ll be there for one hundred and twenty five more. So pick us up next week. Super.
Squirrel: Thanks, Jeffrey and Clarke.
Squirrel: Thanks Squirrel.
Clarke: Thank you.