← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS Your Developers Got 20x Faster — Now Watch Your Product Managers' Heads Explode With Clarke Ching
00:39:00
Loading summary
Transcript51 lines
- [00:04]
A
Hey there, agile adventurer, just a quick question.
- [00:07]
B
What if, for the price of a
- [00:09]
A
fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.
- [01:12]
C
Hello everybody.
- [01:13]
B
Welcome to a very special bonus episode with the person I've been reading the writings from for a very long time. So, Clark Ching, welcome to the Scrum Master Toolbox podcast.
- [01:27]
C
Hello. You made me sound really old, which I cannot deny. I'm 56 and I'm at the age where you tell people how old you are within the first few sentences. It's been a long time.
- [01:42]
B
We are in the same generation, so people out there can guess how old I am. But let me tell you a little bit about Clark and today's episode. Clark has been finding bottlenecks in software organizations for many years, as he just said. But he just spotted a new bottleneck that very few of us are actually talking about. And it's not in how we write the code or what code we write. It's inside the heads of the people who have to decide what gets built. But I wanted to understand a little bit more about Clark as he calls himself the bottleneck guy. So you've been working with and writing about Agile Lean theory of constraints for a long time. And in the Rolling Rocks downhill, you tell the story of a software project. Get trouble. What got you hooked in this bottleneck thinking in the first place and what keeps you there? Right? Like you even gave yourself the cognum of the bottleneck guy.
- [02:48]
C
All I must admit, because it's the most interesting thing on earth. It really is bottleneck. The trouble is it's wrapped in the name Theory of Constraints, which are the three most boring words in the English language. And Ellie Goldre, he was a genius, but the naming came from him being a scientist and a physicist, and it was part of his business kind of brand. He was a science of business. And so theory of constraints fit his history as a physicist. And it also probably appealed to all of the physical engineers, not the software engineers of the world, who looked up to physics as if engineering was, wasn't a proper thing, that physics and science.
- [03:44]
B
What many still do today, by the way.
- [03:46]
C
They did. Yeah, they do. But the sad thing is it's actually really, really, really practical. And so many places have actually used it and it's really interesting. So my version of the theory constraints is. I don't model it on it being a science or a type of physics or anything like that. It's. It's being a detective. So one of my books is called the Bottleneck Detective, and it's basically it's how to think like a detective. And that's what makes it interesting. Every single client I have is a detective puzzle that I go to work with, with, with my clients, and they don't quite know what to expect to start with. But we go wandering around and we're looking for the bottleneck, the narrowest part of the neck that's like a choke. And it's choking their business and starving them of profits. And so we like this quiet killer that's sitting inside their business and they're either just siphoning off money or they are actually killing it. And, and it's so much fun because if you think of the, the detective thing, you've got suspects and, and if you think of your business, you've got like, if you look in an IT business, you, you look in and you go, ah, who are the suspects? The bot. So the bottleneck's a resource. It's a, it's a human resource, a person or it's a machine. And you go, well, what machines have we got? And then it's a process of actually logically untangling it and figuring out what the slowest one is. And then you just go, ah, we've got our suspect. And then we kind of switch out of detective mode. And then we're trying to find something else different, which is how to tame it and how to wrangle it and how to speed it up. Because if you speed up the bottleneck, then everything goes faster. But more than that, what we're really trying to do, and this is the idea in the latest book, which they call it the speed book, is you're actually trying to make sure that the bottleneck is in the right place. Because every Business has a bottleneck and there are good places and there are bad places. And in software development, the surprising thing that I figured out about 12 years ago, and I've only just figured out how to explain it so it's so obvious that it's hard to avoid, is that the bottleneck is always in the, almost always in the wrong place. And there's a really, really, really good place for it, which means that you're actually very, very productive, very fast. And everything just flows like a, you know, like a, like an, with aerodynamics. And when it's in that place, everything just flows, which is what we all crave and what we want never seen anywhere else. Everything gets really busy and, and, and we end up with just really, really, really busy teams that actually aren't flowing and aren't pushing stuff out. And if you look at them from the outside without the idea of going where's the bottleneck? You mistake the busyness for productivity and that's not so good. Now, I didn't actually answer your question, but I hope from your the sound of my voice, it's just so much fun every, for every client I get. And anyone can learn this stuff and read the books and do place of work. It's like having a detective puzzle that's been specially customized and written.
- [07:11]
B
Well, I can clearly see why you got hooked on it. That's clear from how you explain it. But there's a bunch of questions that come up from this introduction and I want to dive right into it. You wrote an article on substack called Cognitive Crush, and there you make this point that AI coding tools like Claude code or Codex or any other tools are speeding up developers, individual developers, significantly. But that speed is creating completely new bottlenecks. You talked about bottlenecks upstream. We'll get there because this needs to be explained. You talk about how more code means more decisions that are needed and faster, more features to prioritize, more designs to review, also more code to review, which is something we've discussed with Philip sue recently on the podcast as well. More trade offs to evaluate, and all of that lands on product managers, designs, designers, leaders. So walk us through what is there now and how you're seeing AI change this so that the bottleneck moves, as you call it, upstream. But let's explain what that upstream means.
- [08:21]
C
Okay, cool. So the easiest way for people to get this is to the metaphor I have is an hourglass, like an egg timer, not a digital one, one with sand flowing through the middle of the little bottleneck in the Mid and a little pile of sand sitting atop it, which would be a bit like your, say, your product backlog or whatever backlog you want to call it. So it's shaped like an hourglass. The flow of the sand or the work that goes through it goes through this narrow bottle neck which is in the middle of the glass, and then it goes out at the bottom. Every system in the world has kind of got that shape. But in software development it's actually really easy. I do have in the book one exception and there are bound to be others. But it's very, very rare case where you would want the bottleneck to be anywhere other than the developers, which really throws people. You actually want the slowest part of your software development system, the whole system, to be the developers. And now I'm going to not call him the bottleneck. I probably will. But don't think of them the bottleneck. Just think of them as the pacing resource, the pacing role. If you can imagine. To switch to a different analogy, imagine there's a Navy armada traveling along and they all travel faster than the most important ship, which is the aircraft carrier in the middle. So the aircraft carrier sets the pace and so do the developers. Okay, so we have them in the middle. We don' to call them a bottleneck, but they are. But they're a special kind of bottleneck. They're a deliberate bottleneck and they are placed right in the middle. And what that means is that the people that work upstream, above the bottleneck in the hourglass, you can. You've got lots and lots of names of people that are upstream. You've got various managers of sorts. You've got architects, you've got designers, you've got testers, sometimes work upstream, sometimes you have developers also working upstream. You have product people. The names have changed so much. I don't like to give it. But we'll just get upstream people. The people who, if you want old fashioned words, figure out the stories or the requirements or even more old fashioned, they make the requests to the developers to build stuff or change it. So upstream, what you want is. It's really obvious. This is so obvious. It just feels a little bit mysterious because no one thinks of it these ways. It's really obvious that you want those people upstream to feed the developers really, really good quality, high value inputs. You don't want them, for instance, just feeding them stuff that's really low value and easy for them to prepare. Or random. Yeah.
- [11:21]
B
Which is what most organizations are set up to do, which is to feed random ideas. To developers because they need to work on a schedule. The schedule keeps them busy. Ye, yeah, like keep them busy. Exactly right, like keep them busy. Which in itself might not be a bad idea, but it needs to be the right kind of busy. Right? As an example, right now we know from different studies and different companies that around 30% or less of the features that get built actually get used significantly, which means that around 60 to 70% of features get rarely or never used. Which means that upstream from the developers there's a lot of random useless things being fed into the developers for building.
- [12:05]
C
And I'll come back to that because it's a really important point, but I want to get people to get the downstream bit, which at the very most simplest is testing. And I'll just do the simple version because obviously there's users, there's all sorts of things that happen downstream from the developers, there's ops, all of that kind of stuff. But you want testers to be able to give very fast feedback. Both of These are Agile 101. High quality inputs, high quality, high value inputs from the top, fast feedback from the testers when the stuff goes through the developers. And if you have high quality inputs, high value ones, then you don't get nearly as much rework. If you get fast feedback from the testers, when you do get problems, they get fixed very, very quickly, which is just so much more productive and efficient. So now, now just start with that and everyone's I hope is listening to go. That makes perfect sense. But I've got really bad news. Is that almost to go back to your example and around that almost every Agile team these days, I think. I don't actually work directly with the teams, I work with the people upstream and higher in the hierarchy if you like. But I imagine that just about every Agile team actually has fast feedback because when they switch to Agile or they adopted Agile, they realized that they actually had to do a lot of automated testing and get really clever about testing. So that came for free. Working software meant that they had to do it. But if you go back upstream, product management, and let me just simplify and just say you have too many developers and too few product management people
- [13:57]
B
and
- [13:57]
C
you don't know it because all the developers are busy and all the product managers are busy feeding them, feeding them, feeding them stuff rather than carefully thinking it through and curating it. And the reason they're doing that is there's not enough product management people relative to the number of developers.
- [14:15]
B
Okay, let's explore that a little bit because I Think that's a very material argument for your cognitive crutch crush article. So you say there's not enough people working to prepare the requirements or requests or ideas or features for the developers to pick up. Now this is important from a theory of constraints or flow perspective because if the bottleneck is in the development teams, then what gets to the development teams needs to be the highest quality possible so that they don't waste any cycles giving feedback upstream about the low quality of the user stories or requirements and so on. But now we have a problem because as you say and argue in the article, if we speed up developers, and just for the sake of argument, this is something we discussed also with Philip Su, let's imagine we can be 20x more productive, that is we can process 20x more user stories at the team level with the same amount of people. Let's just use that as a number too, for argument's sake. Then of course that's going to have an impact upstream. Now if we imagine a team of five, if you multiply that by 20, that's equivalent to having 100 developers with a team of five. And obviously we still only have one product manager or product owner working with that same five people, but augmented to 100 in terms of productivity. And of course that has a direct impact. So let's explore that impact.
- [15:45]
C
Right, so what's going to happen is just to start with it, and it's a nice way of putting it, when you actually go, just imagine one person trying to feed a hundred, it's ridiculous. It's just everyone goes, oh, that's just crazy. But that's kind of going to be what it's like. And everyone goes, well obviously then the product person will become the bottleneck.
- [16:11]
B
Okay, but let's explore that, Clark, because I think that when we just use the word bottleneck, we're kind of hiding the real consequence of that, which is, I guess, the point of the article's title, right? So from your experience and your expectation of what's going to happen in a situation like that, let's describe what would happen to a product and a designer person who are single handedly trying to feed what is now a equivalent to 100 people developer team.
- [16:38]
C
So the first thing they're going to do is they're going to cut corners. They're going to just go, this thing here, which I previously might have spent a week thinking and mulling over and refining and stuff, you know what I'll do? I'll just chuck it into the team because they can turn it around so quickly and then it can come back to me and I can fix it when it goes wrong, which sounds like a wonderfully efficient thing to do. Except that's the more rework you have, actually. And that goes back. You're just adding more and more work to the people up front. So there'll be busy work that they'll do, which is kind of like those, the 30%. They'll just go, oh, I've got this thing here. This is great. In 10 minutes, I can prepare 17 days worth of work, which I can give to developers, which are two developers, and they can go and do all of this stuff. It will be just amazing. And it takes the pressure off me. So they're giving them stuff just to take the pressure off, just to keep them busy. So it's busy work. And those will be the two most obvious ones because they're just trying to keep everything busy. There'll be another one that's absolutely insidious, which is that fundamentally we don't want 100 times as many user stories. We're not here to deliver user stories. We're not here to deliver more features, we're not here. We're to deliver stuff that is really good product and to build really good product. Sometimes product people have to sit and mull. And this is a lovely model. I'll just try and explain this. Just imagine a mountain. We have to climb it, and we're busy climbing it. And there's this idea of a false summit. And what you do is you climb the mountain and they call it's mountain complexity. And when you're working on something, you're creating this new thing. This doesn't happen all the time, but it happens. When this happens beautifully, it's beautiful. And when it doesn't, it just requires a lot of work. You're busy building this thing, it becomes complex. You've got all of these diagrams all around the place. You've joined everything together, you've talked things through and people look at it and they go, wow, that's so clever and complicated. And at that stage you've kind of reached a false summit. And it's like peak complexity. And if you go back to what Steve Jobs said, one of the most valuable things he said was not buy more ipods. It was that when Apple works on stuff and they get to what people think is peak complexity, they keep working and they keep working and they keep working and then just suddenly everything just. There's like almost like a hallelujah kind of sound in the background. And the light bulbs come on and they go, ah. And they discover peak simplicity, which is actually the top of the mountain. And the, the sad bit about that, from the development point of view of having too many developers, is that it's usually smaller, it's usually neater. It's, it's, it's, it's simple and it's beautiful and it's just right and it doesn't happen every time, but when you give it to the developers, because you've done all the work of simplifying it and making it so elegant and simple. And I think many of us have had this experience where they've gone and it just suddenly, the true essence of it just comes out the other side.
- [20:04]
B
So what you're saying is, if we keep the product people and the designers busier, because now they serve a lot more developers, they have no time to walk through the fog of complexity and finally find something that has the value, impact that we hope to get with that functionality. Right? Yep.
- [20:25]
C
And what they'll be doing is that they will be going, more features. More features. Actually, they won't.
- [20:29]
B
Well, actually, that's a good point because actually, one of the things you say in the article that I want to explore is this idea that, okay, but the first solution, people will say, hey, let's give AI to the product and the designer people. Right?
- [20:41]
C
Yes.
- [20:42]
B
Yeah. Such an easy fix. Right. But you argue that actually it almost makes things worse.
- [20:48]
C
Tell us why this. This is the curse of it. So it's actually a good idea to give this stuff, to give AI. It does uplift the capacity and probably the capability of the people upstream. It does. However, I got to tell you about my dog. My dog, she's beautiful. Her name is Georgie. And when she was little and we were training her, we got a trainer. She's a rescue dog. So we got a trainer to help us kind of get her back on track. And they said that if you want to wear your dog out so that she sleeps, don't take her for runs and long walks. That seemed like the thing they get. No, no, no. The dog will love it. You'll be the one that ends up tired. You'll come home and the dog will still have lots of physical energy left. If you want to make the dog sleep, make the dog think. So. Dog owners around there will know. You get these little mats and you hide the treats and stuff inside the mats and they're all tangled up and the dog has to chew around to get the food out. Or if you like, you can Train your dog to sit there and put treats on top of their paws. And they sit there and they stare at the two paws and they're concentrating and they're just working their poor little brains and they're drooling all over the place. And then you say go and it's like. And the treats are gone. And then they get tired. Brain work. This is something that people I think, under 40 will find it harder to realize because the nature of their work is much better paced and they in a way have more energy. The more experience you get, you tend to then get to really cognitively demanding work. The equivalent of sitting there like the dog and watching these treats. And it just is exhausting. And I talk to, I work with quite a lot of seriously senior people who do heavy lifting. And one of the biggest things that I help them do is actually work less, pace themselves, otherwise they wear themselves out and there's just work and work and work. And then they have to just get really good quality time for thinking and not do too much of it at once. If you do too much of it, you do half as much the next day. It's like a muscle and you just wear yourselves out like that poor dog. You send yourself to sleep. So what's going to happen with the product people is that let's say that currently they spend 15 to 20% of their time, and I'm making up that number, probably feels about right, doing the really heavy mental lifting. It AI comes along and then what they're doing is they handing over some of the easy stuff to a machine that can do what used to take them eight hours in about three minutes, say. So what's going to happen is that they're going to get good at that. They're going to trust the AI can do just as good a job that they can there. But then the stuff that requires a heavy lifting, heavy thinking is going to go to what, 40, 60% of the day and that it's like lifting weights for six hours a day or another way of thinking about it. So lifting weights is that cognitive thing. They're just going to wear themselves out. And I know the brain isn't a muscle, but when you think, you chew through, I think it's 30 to 40% of the glucose in your body. When you're thinking hard, your brain is using it up. And I've gone all non scientific and dress it up in scientific language. Sorry, I shouldn't have done that. Heavy mental lifting is exhausting and you have to pace yourself, which is actually the answer.
- [24:51]
B
So actually, that's a very good point because when we are in that kind of position, so let's imagine we are product people, designer people. So one person serving a team in this case, because it could also be a line manager, a test manager, an architect. Right. Like all of those are cognitively demanding jobs. And what is happening is now the team is waiting at our door for the next thing to work on because they are now much more effective because of AI. Now, what you're saying, if I understand you correctly, is that cognitive crush is the weight of demands coming from the team towards those upstream roles that now need to be more productive. And it would be inviting and perhaps easy to think that AI will make them more productive as well. But the problem is that the things that they now need to consider are much wider. So many more things. So as you said, if they used to spend eight hours preparing, say a sprint worth of user stories, now they can do that in three minutes. But the eight hours they prepared, those user stories were also thinking time processing time. That kind of related those user stories to a significant business goal they had in mind. And now they don't have the time to do that. That Is that, Is that what you're trying to say?
- [26:05]
C
They, they will have. Some of it will get chewed up. Sorry, yeah, that's a good point. So some of it will get chewed up their day by feeding these hundred developers. And that's okay. AI will help some of it, a good chunk of it. Presumably they will sacrifice finding peak simplicity, which is really bad for your business and for your users, but they will actually make their brains explode. And there'. There's actually two bits. One is this, that it will go from say, 15 to 20% of their day to maybe, let's say 50% of their day is really, really heavy lifting. And then they're going to be absolutely worn out for the other 50%. There's a second part of it too that's just really, really massively exhausting. Just imagine that all of the ideas that they're playing with, let's just call them idea grenades, okay? And it's from a person. I just like the idea. There's a guy who walked past his team and he goes, oh, why don't we do this? And they'd rush off and they say they call them idea grenades and some of the things they work with are like this. But they're going to go from juggling one idea grenade to try and coordinate many, many idea grenades. And if you like it, if it's easier people are listening, can imagine they're juggling chainsaws instead of dead. Suddenly.
- [27:32]
B
Chainsaws with grenades attached to them.
- [27:35]
C
Grenades on the end. Yes. And they got the pins in their teeth. And what's going to happen is that. And it's already happening for a lot of people who are using AI. Whatever they do, they're trying to orchestrate so many things. They have become coordinators or they've become like the maestro, the conductor in an orchestra. The people that used to sit and think for long periods and now juggling and juggling and juggling and they're going to start dropping things and it is so exhausting. You can't juggle chainsaws all day.
- [28:09]
B
And I really like the analogy because there's another analogy that I've heard that I would like to explore following that, which is, okay, we have these people super busy juggling chainsaws with grenades attached. And then, then we have also this idea that an error in a line of code is one wrong line of code. An error in a design document is maybe 100 lines of code that are error. Then if it is in a requirements document is maybe 1,000 lines of code. If it is in a high level idea like going in a totally wrong direction with the wrong type of features, it's potentially a huge disaster for the company.
- [28:50]
C
Company.
- [28:51]
B
So then we also have this higher stakes in that role. In those roles that are juggling grenades
- [28:59]
C
with chainsaws in the wrong direction and 100 times faster.
- [29:05]
B
Yeah, and that's the thing that really scares me. Not as in it's a problem, but as in if we're not paying attention of how we use, how we deliberately use this new technology AI, we're going to start doing that what you just
- [29:22]
C
described, which is going, yeah, that's the point. If I could take it just back and just forget about it being AI, Just it's some amazing productivity tool. The fundamental idea here is in the theory constraints, you have a bottleneck and it is the resource with the least capacity. If you change the relative capacities and make some of them much, much faster, the bottleneck's going to move. So my next book jokingly is going to be called who Moved my Bottleneck? Like who Moved my cheese? But that's what's going to happen. The bottleneck is going to move. And if we don't think about that, which is what we're doing here, we're trying to figure out how is the relative capacity going to change again. Oh crap, it's gone upstream. What do we do about that. What do we do to get ahead of it? Then suddenly it's going to happen and we're going to all of our product people, their heads will explode.
- [30:18]
B
Not just the product people, because then the customers heads will explode, the salespeople's heads will explode, and so on. It's a cascading explosion. Okay, but Clark, we're getting close to the end and I think we owe our listeners a little bit of hope, a little bit of direction. So the next question is obviously. All right, now that we're here, what should we be experimenting with?
- [30:42]
C
Right. Okay, first thing, get your product people working with AI. Get, get them help to, to work with AI and learn how to use it really, really thoughtfully. So think of it as a thoughtful tool before it being a productivity tool. And like anything, don't just rush into it, learn how to delegate to it. Because that's what we think of as a tool that does stuff. It's actually delegating work to this thing. That's the very first bit. And then we've got to think about, there's two bits and one is actually really bad news and one is really good news from the product point of view. You can't just say 5x with AI your capacity and then get more people working there. You've actually got to figure out how to get, get the optimum number of product people and get them pacing themselves. So I go to the gym twice a week. I used to go three times a week. And when I first started, I said to my personal trainer, I'm really enjoying this. Do you think I should go five days a week? And you see her eyes light up thinking, that would be nice for my income. And then she said, no, no, because you will never come back after the first week. You have to pace yourself. You have to do the heavy lifting and then you pace yourself so that you can survive. So remember, old school agile, sustainable pace. This is really particularly true for this role. So that's kind of like the cheat. We get the most energy by figuring out how to actually slow ourselves down and think. And now the second bit. Don't try and keep your AI and your AI developers busy all the time. You don't need to. That's true before AI, but the temptation is we've got these expensive developers there, all of these developers there. We've got to keep them busy. And that's the drive. Now pre AI, that, that, that's why we actually almost always, maybe 70 to 80% of the time, we have too many developers and we're trying to get them busy, but with the AI, you're not paying them 40 hours a week, you're renting them by the minute. If you, if you like, use them at the pace of the product, people don't use them. Just try and don't just try and go faster and faster and faster because you're not. Your job isn't to make lots work through lots of user stories, make lots of features. Your job is to make really shithot, if you forgive my language. I hope you don't have to edit that out. Great products that make lots and lots of money and, and what you will do if you're not careful, if you just try and keep the AIs busy all the time or the developers busy, you'll end up with 60% unused features.
- [33:46]
B
Actually a lot more, I'm guessing, because now we're going to put a lot more ideas through the pipe.
- [33:51]
C
Yeah. And this is the difference between speed and quality. Quality will come from actually slowing down and money, profits will come from slowing down building very good products, focusing on why we're building these products, not just how do we keep the AIs working. And the lovely thing about the AIs is they're not like people sitting there twiddling their thumbs who, well, we hope they're not, and then just go off and start new stuff. You get to ask them to do stuff and you can turn them on or off. So the capacity is almost like a tap that you can turn off and on when you need it. Whereas the psychology of having, say 10 developers there, we've got to keep all 10 developers there, there, we've got to keep them working, working, working, working. With AI, we've got a lot more flexibility to wind them down so that the whole organization runs at the speed of good. High quality, high value product management. Yeah.
- [34:49]
B
And that's really the goal. I think you just said it. High quality, high value product management. Clark's article, the Cognitive Crush, and his latest book, the Speed book, I really like the COVID by the way, are available now. Check the link in the. So make sure you check out. But how about you, Clark? Where should people go if they want to know more about you and the work that you're doing?
- [35:12]
C
Right. So just in case anyone's missed it, my first name is Clark with an E on the end and my second name is Ching. The best place. Go on LinkedIn. There are two Clark Chinks. One of them is a distant relative From Devon, about 300 years going back, and he's in Canada and he's a dentist and so don't follow the dentist. Don't follow the dentist. Connect with me and if anyone would like a copy of any of my books, I just message me and I'll
- [35:45]
B
oh, I definitely want that. I definitely want to read the speed book. So make sure you send it to me because I'm going to read it and post about it on LinkedIn as well.
- [35:54]
C
I must say that the most beautiful thing about the speed book is not only is it like the I hope I got to peak simplicity for doing the theory of constraints for software teams and it works with the teams all the way to leaders. And the worst place to have your bottleneck is actually your leaders. But it's only an hour's worth of reading. It's like a really big bang for your buck. Absolutely. The buck is free if people want it. Clark Tune Exactly.
- [36:22]
B
Hey, reach out. Clark's LinkedIn page is in the show notes. Make sure you check out the book and send him a DM and you'll get a free book. What's better than that? Clark, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [36:38]
C
Thank you very much for listening to me. Yes,
- [36:43]
B
alright, I hope you liked this
- [36:44]
A
episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking Agile access to over 700 hours of agile Gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books. And if you're into no estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together.
- [37:59]
B
So if this podcast has helped you
- [38:01]
A
before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great. It's important, but doing it together that's next level. I'll see you in the community.
- [38:33]
B
Slack. We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.