The First Episode, and Theory of Constraints
0:00Well, hello, everybody. It's the 3rd of April, 2009, and this is actually the first in the Agile Executive podcast series. And this is Michael Coté, available at peopleoverprocess.com, and also, of course, occasionally when I get around to posting to it, over at theagileexecutive.com. And we've got, as our first guest, we've got someone pretty exciting. Would you like to introduce yourself? Exciting? Wow. Why not? Hi, Michael. Why not, indeed? Exactly. My name's Clark Ching. Clark Ching. I always say it sort of slowly, like that, because most people get confused by my surname. I'm an Agile person, I suppose you could say. I work in Agile, though. I specialize in Agile with using the theory of constraints, Goldratt's work, that I guess a lot of people have read about in his book, The Goal. I'm writing a similar book. It will be out hopefully later this year. It's been published by the Pragmatic Press, which is quite cool. So it's a business novel. It'll be out sometime soon. I'm working through the reel right now.
Two Books, and Writing Them in a Recession
1:22And trust me, that's a lot harder than writing. That's right. I didn't realize. You know, in your email signature, you have your, I think, isn't it like turning rocks into gold or something like that? Yes, yeah. I've got two. Where am I? I'm just trying to look at them here. I have them printed off already. I have two books. One is the big book, which is the business novel. Be 200, 300, 400 pages, sort of when it's finally printed. Full-size novel, the full story. About six months ago, I'd just come off a consulting engagement. And I suddenly went to try and find more work. And the economy had disappeared. And I sat down and thought, well, the stuff I do, this agile stuff, is really good because people can deliver more projects in less time. They can deliver more projects in the same amount of time. Surely this must be a good thing. And I was looking at it going, hang on, the recession is disappearing. I must have something. There's something in agile that's important here that should be able to help during the credit crunch.
Why Smaller Releases Need Less Cash
2:41And that's what spawned the idea for Rocks Into Gold. It's a business parable. I describe it as being like the one-minute manager or who moved my cheese crossed with the goal. So it's kind of a small book. And it's got a really important lesson, which I think a lot of people in software development don't actually realize, which is that if you break big projects down into smaller projects and deliver several releases to a project, which is one of the key outcomes of agile generally, then you actually require an awful lot less cash. In most cases, not all cases. So agile is a way of developing software that requires a lot less cash. And that's one of those things we need at the moment. So, sorry, very long answer there. Two books, Rolling Rocks Downhill, the big book, Rocks Into Gold, is a small book, different characters, different setting, written very quickly. You can read it between 15 and 60 minutes or so to read it.
Explaining Agile Without the Word "Agile"
3:56And the best comments I've got about that are that it explains agile without actually using the word agile and people get the benefits of why they should do it. And if you want to read it for free, the best way to do that is to just search for rocks into gold. Or go to tinyurl.com and on the end of it, put in rocks into gold as the bit that goes on the end. Yeah, yeah. That's fantastic. There's a – you know, I always think it's interesting you take it on the – you know, I mean, that's the way the goal was written, of course, as a business novel. Which, whenever you tell people about that Goldratt book, that it's a novel, you have to sort of disclose like, wait, don't tell me I'm crazy yet. Exactly. You never think that, you know, a fictionalized sort of like business book would be that interesting. But – and, you know, granted, I would wager sort of outside of the world of wanting to know about, you know, the business stuff in that book. You know, it's not like a – you know, I'm sure the mainstream audience doesn't find it extremely compelling.
The Goal Rarely Comes Up in Agile Talk
5:11But it actually is. No. It actually is. It's a good format. I should hope not. Yeah, I remember. Yeah, it's actually sold three million copies. Yeah, yeah. Roughly. And I always think it's funny that the – I mean, we're talking about it now, but, you know, the goal doesn't come up that much in discussion of agile software development. But there's a lot of – as you obviously know, working with, you know, theory of constraint stuff, there's a lot of similarity between the two. And anyhow, that's just my over-enthusiastic plug for that book. There is – the crazy thing about it is that I've realized that as I go on, my own book is actually more and more like the goal. It flows the same storyline, which you tend to expect with these things. They tend to follow a sort of similar art, the hero's journey. Right. Yeah, it's actually – it's well-documented. I've read about it when I started writing my own novel. But one of the things – if you look at agile in general, if you took away most of the stuff, there's two bits to agile. One is prioritize your stuff. And then the second is deliver it in small chunks.
Agile Reduced to Two Things: Prioritize, and Deliver Small
6:26And I know that's going to offend a lot of people, but at the end of the day, that's the core of it. Now, if you look at the small chunks part of it, that's pretty much what happens in lean manufacturing or the way which Toyota works. Now, I grabbed onto that and thought, that's fascinating. I saw the lean background. But then as I was looking at it going, well, you know, I know how to make that stuff faster with the theory of constraints. I went back and I read the goal again, which I hadn't done for this. And one of the things that I've forgotten, which is daft in retrospect, is that the first thing that they did in the goal was to break the work down into smaller batches so it flowed easier. So that's essentially what the theory of constraints with agile is. The first step is break things down into smaller batches and then figure out what within the process is slowing them down. That grossly oversimplifies it. But theory of constraints is an extension of lean, I think. And I've used it on agile projects and it's surprising how much extra work you can get out of this just by going beyond that step of looking into how to do better, sorry, better small batches or better iterations and figuring out where the bottleneck is.
Why Smaller Chunks Cost Less
7:57So I'm curious to hear more in your experience, you know, like you said a couple of times, when doing software development, you know, in an agile way or, you know, like that breaking things into smaller chunks ends up costing less than having a big chunk. And I'm curious, like, why, why you think that is or sort of like how you've come to that conclusion. Okay, well, there's two bits, two key bits to it. One is that if you look at most software projects and if you were able to get your customers in the room at the beginning of the project and force them to prioritize every requirement or feature that they had there, what you would find is that there's an awful lot of stuff that is actually low priority. And that's really hard to do because people don't want to commit to, they don't want to lose anything. But if you actually go back and look at projects that you've delivered and actually put a very, very strong eye over them that looks and says, prioritize every single thing that we've delivered there, what you find is that very, very little, sorry, a big chunk of the stuff is actually very low priority.
An Agile Rescue of 150 People
9:19A lot of really important stuff, really low priority. But we still build them in most processes. We still build stuff that's bloated. I'll give you an example. A project that I just have been working on, it was effectively an agile rescue. They'd gone in and they had this huge, it was 150 people roughly working on this big agile project. And it was a disaster. So we kind of had to turn it around and get it started again. Now, the first thing that we did is went through and got people to rank the features and the requirements and put them in order. And obviously, some stuff disappeared there. It got taken out of the project and it will never be built. That hadn't been done previously. Now, even when they start the next part of the project and actually start working on it, you can do the same again. I remember looking at a search screen, which had been, obviously, you need a search screen. It's got to be in the project. So it was a must have. But when you look at it, there were a whole lot of features on there that you could actually take out and say, well, some of these are really important.
Cutting Scope by Ranking It
10:39Some of them aren't. And just simply by getting your project, your scope to be much smaller by prioritizing, you could chuck out a lot of work. Just save yourself from building a lot of stuff. A lot of smaller project, a lot easier to test. So that's the first thing. The second thing is that there's just quite simply a focus on delivering small chunks of stuff that actually works. And it's easier to layer something good upon something good upon something good than it is to build something that's kind of tangled together and then spend a long time reworking it, trying to make it work, which is how most projects work. Right, right. So, yeah, I mean, so it seems like there's a – I mean, this is always one of those interesting implicit things about agile development methodologies is you tend to end up doing less all at once. And essentially, you get better at not overpromising at what you're doing. And that seems to be – one of the key items to sort of success in agile stuff is just not really doing as much. You know, and the thing is, like, you know, it sounds like you're doing less work, but the fact is that what's really happening is you're setting yourself up for less failure at the end. Because if you overpromise something, you're obviously going to fail at doing it.
Agile as a Promise You Can Keep
11:56So you're just more realistic than promising what you can actually accomplish. Absolutely. You've got – the difference between agile and not has very little to do with the technology. If you break it down, what it's actually saying is we're making a different promise to our customers. We're making one that we think that we can deliver on. And most projects, they come in, they want an aggressive target, one that's going to be hard to hit. They want to get people motivated by giving an aggressive, difficult target. But because it's aggressive and difficult, the odds of missing it are much higher. So we start in most software projects by never actually explicitly acknowledging it, but by saying, hey, look, we're going to make this more likely that we'll fail. So agile just says, hey, we want to deliver. We want to deliver on time. We want to make a promise we can keep. So why not make a promise that we know we can keep and we'll have to work slightly differently, but not all that much differently. So you're right on, Michael. You know, in the – obviously, from what you've been alluding to, you get around to a lot of – whether it's sort of rescue projects or just projects where you're sort of helping get agile working in larger organizations.
Coaxing an Organization That Doesn't Want To
13:18I mean, like a team of 150 is quite large. And I wonder, you know, this is like the old cliche question in agile stuff or for any idea. And it's basically just like, you know, what are – do you have any, like, great tricks that you use to sort of, like, get people who don't want to do agile to sort of, like, coax them into doing it at an organizational scale? Because this is always the issue is, you know, the – you know, and I used to be in this position when I was doing software development. When you read all these great, like, motherhood and apple pie fantastic things about agile and, you know, it's just like, oh, yeah, that's the way we should be developing software. And then you show up to work, like, Monday at 9 a.m. and everything kind of goes downhill from there. And, you know, I wonder, you know, it's impossible to summarize, you know, the answer to this sort of thing. But, like, how do you – how do you get over that, like, depressing cloud Monday at 9 a.m. when you're trying to apply these things? Well, it is hard. And agile, I think, is actually much harder work than, say, a typical waterfall project. It's much more likely to succeed, though, to be fair, a lot haven't. But it is much harder work, and that's usually actually where I start.
Agile Is Harder Work, and Flossing
14:34When I talk to people about agile, I try and do two things. One is let them know that agile does work. But it's hard work, and it's crossed it, and they're going to have that whether they like it or not. They could have those problems much later when it's much harder to fix them, or they could draw them in earlier and tackle them when it's actually easy to work – to solve them. So there's the first bit is actually setting the expectations low. All right. This is sort of what I always analogize to flossing. It's sort of like we all know that flossing is a really good idea that we should do every day, and it's going to save us lots of problems in the future. And you just sort of have to have that short-term leap of faith to say, like, all right, I'm going to start flossing every day. I like that. In fact, one of the characters is about to say that in my book. So thank you very much. Consider it stolen. That's a good analogy. That's very good. Yeah, well done. I like it. Yeah, the second bit with this – so set expectations that it's going to be hard work. Actually, before that even happens, the one thing that most of the Agile community, in my opinion, is doing wrong is that if you grab a box of cereal out of your kitchen,
The Cereal Box: Ingredients Versus Benefits
16:02and you look at it, and you turn it over, and you look at it, you'll find an ingredients list on the back of it, I guess, somewhere. And do you have Weetabix in the States? We don't, but I'm cross-Atlantic acculturated enough to know what it is. Very good. They're wonderful. I've been living on them for nearly 40 years now, and I couldn't live without. But if you grab a Weetabix box or Frosties or whatever you want, and you look at it, you'll find that they're a fairly bland list of ingredients. So I presume Weetabix – I've never actually looked, but I presume they contain wheat. It's probably a hint in the name. They'll have sugar. They'll have some sort of type of fat. They'll list down the ingredients there. They don't put on the box the process which they use to make them, but they do list down the ingredients. But if you look at roughly 90, maybe 95% of the entire box, it's all about the benefits and the reasons why you should eat them. Even if it's just to give you a good feeling, it'll have stuff about fiber and healthy and all that kind of stuff. When we talk about Agile, we tend to talk about the ingredients and how we make things rather than all the nice stuff that gives people a good feeling, the benefits, the reasons why we should do it.
Sell the Benefits, Then Admit the Work
17:26And I think that the focusing too much in the details of how we do it, too much on the process rather than the outcomes and the benefits, actually freaks a lot of people out and it scares them. So that's usually my first step is to actually try and sell people. Sell is a word that has many meanings to defend people, so maybe influence people to see that there is actually a lot to gain out of this. The second step is, hey, you're going to gain stuff, but it's going to be hard work. And the third step is to find ways of getting those benefits quickly without doing everything. Even just like in My Little Rocks into Gold, the small book, the key thing that the character did was he said, Right, dear customer, I would like you to write in as your first requirement for this project that instead of delivering it as one big project, if it takes about a year, we want to deliver it in three or four chunks each of which take three or four months. So just breaking it down into small chunks gives people an awful lot of the benefits already. So there are other things, of course, you have to do to make it work, but you don't have to do everything at once.
Getting Better Rather Than Getting Perfect
18:43So just figuring out what's the most important thing you have to do. It's a very theory of constraints idea. What's the bottleneck here? What do we have to focus on? What's the really important stuff? We'll get better to start with rather than getting perfect. And I think if you take that approach, you're far more likely to succeed at getting better than you are at getting perfect. And I guess that's theory of constraints kind of philosophy. That's the approach I take. Yeah, no, I mean, it's, you know, in, I don't know if retrospective is the right word, but when you sort of like look at the big picture of software development over the years and the way it's usually sort of like the way the different, whether the developers, architects or product managers or the different people oriented in it, for as good as like software development is at like sorting things and algorithms and things like that, we're always pretty bad at an industry of like, I mean, I guess, pun intended, I guess, it's sort of like keeping our eyes on what the end goal is and really sort of like prioritizing the work that we're doing, right? I mean, and which is fine. I mean, there's a certain, I think another way of putting it is that a lot of the times
When Builders' Goals Don't Match Customers'
19:58the people who are producing software, they have their own goals that may not align with customer goals. And the primary goal is really to, you know, other than making money, you know, pulling down their salary and everything, but it's just to sort of like have that enjoyment of the sort of like ongoing day-to-day software development process and everything, which, you know, once you're done with the software, you've kind of like spiked your own, you know, not to use a confusing term, you've kind of like ended your own goal producing, you've sort of like have stopped what you've enjoyed doing. And, but at the end of the day, it seems like if you're developing software, you have to, you know, keep your eyes on that sort of finally having a release that people want to use, not just the enjoyment of creating the release. That's it. You know, the sad thing that I think, the thing that sort of driven me to do this, to grab hold of Agile, and although I'm a technician at heart, I've kind of, I guess I've turned into a salesman for Agile, writing, you know, a book to try and sell the idea to other people. The reason I do that is because I've had a lot of really horrible jobs in the past, and most of the people I know have had really horrible jobs. And there's been glimmers of hope and enjoyment in my job and my friend's jobs.
People Enjoying Their Work as the Actual Goal
21:19But I guess the, actually, if I can get, this is going to sound a little bit immodest, but it's not actually meant to be about me. Whenever I've gone into, to do Agile stuff in places that haven't been, what I've discovered, and I know a lot of other people have discovered this as well, is that people start enjoying the experience of working a lot more. And I've had it a number of times being described as a breather fresh air. But what they don't realize is that part of it is that I'm delightful and charming, but most of us are working in a way that allows people to enjoy their work. And they attribute that to me. But just making the process work easier makes it just enjoyable. And that, for me, should count as really the end goal. At the end of the day, if people are enjoying their work more, and if everyone's enjoying it, then I bet they're making an awful lot more money as well. Yeah, absolutely. No, I think that's, see, that's definitely the one that's like the big text on the cereal box there. The Agile Abix helps you enjoy your job more. Actually, listen, you know when you write a book and stuff and you sort of – do you have Big Brother in America?
Minor Celebrity, and a Metaphor Hole
22:41Yeah, yeah, we do actually. Yeah, yeah. Well, you know they have – over there they have Big Brother celebrity thing, and they kind of have a celebrity version. And I watch it and I never know any of them. And I guess in the Agile world, I'm kind of – I think of myself as one of those sort of minor celebrities. Minor enough that I might get on that show, but no one would really know why I'm here. And I've forgotten your question there. I don't think there was a question. But there was one – I got stuck in the metaphor there. Sorry about that. That's right. That'll happen. It's like a metaphor hole, right? It happens all the time. But, you know, there actually was one last thing I wanted to ask before we wrap up. And, you know, every time I talk with someone who's, you know, in the technical field, somewhere other than where I live, I'm always curious to find out about sort of like the scene, if you will, in their part of the world. And to that end, I mean, how would you characterize sort of like the Agile scene in the U.K. or, you know, even in regions of the U.K.? I mean, what's your feel? What's the report from across the pond? Right. London's got a very good, lively, agile community.
The State of Agile in Scotland
24:02It's probably a lot of people who have been involved in it for many years. Plus, it's a big city. Here in Scotland, we have a lot of small pockets of Agile. Some of them have been going for a while where they've grown out of XP and the likes, and they're actually doing quite well. Some of them have been taken on in corporate, and they're doing okay. The biggest problem, I think, with most of them is that they've grabbed it sort of big, and they're trying to do full-blown XP and stuff in places where it doesn't work, and they end up being very disappointed because it does turn out to be a lot of hard work and a struggle. So this is going to sound sad, but I would actually say that the state of Agile in Scotland is disappointing. It hasn't taken off. It's taken off in pockets, but it hasn't succeeded yet. It disappoints me no end. I bet. I bet. Well, you know, it's a long slogging process probably. I think you were on to the most beneficial bootstrapping thing is to find those sort of –
Quick Wins to Earn the Benefit of the Doubt
25:20whether you want to call them quick wins or low-hanging fruit or whatever, but just to, like, you know, whenever you introduce a new process into whatever sort of organization, whether it's regional or a company or whatever, you've got to sort of, like, win that benefit of the doubt from the organization that they'll sort of put in the time to believe and understand and sort of, like, try out a process. And it seems like that's really the best way in sort of a business goal-oriented context or organization. It's just, like, really fast things happening right away because you don't want to be sitting around waiting six months to see if this was a good idea or not or, you know, even longer. That's it. And to be fair, in Scotland we've had some great little agile success stories, and I hope to put a wee sort of roadshow on shortly, sort of highlighting those and highlighting why you can use agile to do better during this unfortunate economy. But generally I'm sort of seeing a lot of people thinking, seeing agile as a bit of a fad that was popular but is sort of fading away. Actually, I've just remembered, I'll be very quick here, that the bit that I was going on about with the celebrity thing, I invented my own version of agile.
Everyday Agile, and Making People Happier
26:38I didn't really, the stuff I do is based on the theory constraints. The idea is I gave it a name called Everyday Agile, and what I want to do with Everyday Agile is the idea that by doing some of the really good stuff from agile, you can go into places where you have everyday, ordinary people and not only make them much more money, but you can make people happier. And that's sort of tied back there. The goal for me is to make people happier, and there's a side benefit of that. Businesses will actually make a lot more money. And I think if we generally, in the agile community, tried to get that message across, didn't try to get so bogged down in the technical details that it freaked people out, then I think it will be adopted more. And that's kind of, that's what I'm trying to do with my life anyway. Yeah, yeah. Well, that's, I think, getting people happier, you know. That sort of like, that zooms out the goal like even further than just like the business context, right? It does. And I think, I mean, it's always nice to sort of like Russian doll up to like why you're getting motivated to do something. And at the end of the day, you have to have sort of like that prime mover of motivations.
Where to Find Clarke Ching
27:53And it's sort of hard to argue why you wouldn't want to be happier or like tell someone why they would want to be happier. So it's sort of, it ends the chain of asking why. And, you know, if the logic goes through that businesses are making more money, if their people are happier, then you can actually measure both of those two. And it would be interesting to see the correlation between them. But anyway, I could get stuck in that. Sorry. Well, great. It's been really fun talking with you this, well, for me this morning, for you this afternoon. It is. It's afternoon here. Time for a cup of tea. So if people want to like look up your stuff, do you have a URL they can go to or anything? Right. Clarkching.com. There's an E on the end of Clark. So it's ClarkEching.com. Or just do a search for Clark Ching. There's only one of me in the world, I think. And to go to, to have a look at Rocks Into Gold, the small book, you can just go to rocksintergold.com. It's actually probably the easiest way to find it. And if you scroll partway to the page, you'll find a link where you can read the small book for free on SlideShare. And it does take 15 to 60 minutes or so, depending on how far you have to read. And the feedback I've got from it has been fantastic. And it's just putting Agile across in the light that people can understand it. So if that can help, and if that helps save a few jobs, then I'll be happy. Yeah, I'll have to go check that out myself. That sounds good. And I'll put all of these links in the show notes over at the agileexecutive.com that people can find. And with that, thanks, everyone, for listening, and we'll see you next time.
Machine transcription, lightly formatted. Chapter headings were written from the transcript; speakers are not identified, so nothing here is attributed.