Clarke Ching
Transcript
So if you'd like to leave now, there's the summary. Uh, Stories are sneaky little bastards. And if your English doesn't help, I hope that helps. Google translated that for me last night, so I hope it says the same thing. So this is a talk, I've given this a few times over the last year. It's about really how I've changed how I approach selling Agile to people over the last 15 years since I started doing it in about 2002, 2003.
And it starts with a bit of a sad story, a true story.
starts in 2003, which is the year I've come to know as the year of the Muppet. Because in 2003, I was generally regarded in the office where I worked as a Muppet, which in British, I don't know if it translates to France, but in Britain, a Muppet's the village idiot, a fool and an incompetent person. And that was a really, really unhappy time in my life, as you can imagine, especially if you roll back a year to 2002. And at that stage in my life, I'd gone from being a programmer in the late 90s, early 90s to late 90s, and then I kind of stumbled across this whole lot of management stuff that's now all lumped together.
And most of you will have probably read similar stuff like this. That was out at the time, the stuff that was coming out of Japan. And shamefully, Don Reinertsen, who isn't here, he's doing a session upstairs, one of his books should be up there as well, Managing the Design Factory. It was one of those books that made a huge difference in my life. So it came from being a programmer. I went away and I studied and I found out all of this really, really fascinating stuff about lean and in particular, Ellie Goldratt's Theory of Constraints. The book's sort of hidden at the top there. The Goal. Can I check? Has anyone read The Goal? Yeah, quite a few of you. Brilliant. So I read that book and I had kind of like an epiphany moment. I realised that the stuff in that book, I had to figure out how to apply that. To the world I worked in, which was big software projects. And I couldn't make sense of it. I read all the lean stuff, I read all the quality stuff, I read all of the gold rat stuff, and then it only made sense.
I had my epiphany moment when I read this book.
By Tom and Mary Poppendick. Who's read that? It's going back a bit. Okay, very good. So I read that and I had this little light bulb moment when I read the preface. And right at the beginning of the book, it had this little one sentence. I read it and I suddenly go, I get it. I get how all of this stuff, how it all hangs together and why this stuff agile is all derived from lean theory constraints, quality movement. I got how it worked. And it was just this one little... Sentence in about the second paragraph. And I'd love to share that with you now, but I can't because it was in a draft version of the book and it got cut out before they published the final version. So I can't remember what it was. I can't share it. And now I'm sharing my misery with you because you can all sit and wonder and think, what was that great sentence? So I had all of this stuff going on in my life, and at about the same time I was working on an MBA, I decided to do my MBA dissertation on Agile.
And as it happened, Ken Schwaber was in Scotland doing one of his first out-of-America scrum courses, and I went along to a newly formed group, Agile Scotland, and I took Ken's two-day Scrum Master course, and I just spent £15,000 on an MBA versus £300 on the Scrum Master course, four years versus two days, and I swear I got more out of that Scrum Master course than I did out of the four years. So anyway, I had this light bulb moment. I go, I got it. I understand it. Now I have to go and tell everyone about it. And that's when we return to the era of the Muppet. Because even though this stuff made perfect sense to me, and I got the logic of it, I start talking about it. But when I started talking...
I looked like Fozzie Bear telling jokes to the people, but I sounded like the Swedish chef. And it was really, really frustrating because it seemed like the more I talked about this wonderful, agile, lean stuff that I had stumbled on and was going to change the world with, the more I looked like an idiot. And the more I got negative reactions from other people, and my bosses in particular started looking like these two. You know these two? The grumbly old, like, Waldorf and Statler. They sit there and all they do is moan. I remember there was one bit. I finished my MBA dissertation. It was based on a big project I was working on. And in fact, that project ended up being the source material for my own business novel.
That came much later. And I studied this project. I'd done all of the theory of constraints, thinking, process, diagrams. I'd worked through it. I'd applied everything. learned, I then sat down with my sponsor who was one of the senior managers and I sat down to her and she said, well, I've read your
I've read your dissertation and don't worry, I won't tell anyone. Which as you can imagine was the exact opposite reaction I was hoping to get. And it was a pretty devastating moment because I gone from, in my mind I was up here with the ideas, wanting to change the world. Down here I was being treated like the village idiot. And I got a little bit angry. It wasn't rude to people, but it was a natural reaction I think to not being able to
I probably was like a three-year-old kid who couldn't explain to people what was so clear to me. I didn't have the words for it. So it went off, and I had a bit of a think about it. Now, does that kind of little life story sound vaguely familiar to any of you? The frustration of knowing clearly what's better. But not being able to persuade other people, and then thinking that they're idiots.
Well, that's what I went through, and I kind of figured out that the problem was actually, it took me a long time to figure this out. In fact, I may appear, sorry, that might be easier for you, I may appear slightly wiser in retrospect, but I did figure out eventually that the problem
was what was going on in my brain. I was very lucky to be born with an engineer's brain. Can anyone, who thinks engineer's brain? Yeah, okay, cool. There's kind of a black and whiteness about our engineers brain, you know, they give us problems and we solve them and to my mind I had solved the problems and I realized that I needed to be an agile missionary. Here we go again. But I didn't know the difference.
Between preaching to the choir, preaching to the converted, preaching to people like us, compared to preaching to the people who were quite unhappy, but at the same time happy, living in their current world with their current views. So I didn't know how to preach to the non-converted. And that's really what this talk is about, because knowing what's right and helping other people see that as really, really two very different things. So I didn't know how to preach to them and I ended up in what's known as the chasm.
A lot of good ideas end up there, a lot of shiny things start out, they hit people like us who like new ideas and then they fade away and they die.
So, the equivalent for me was that I, as a missionary, ended up in the cooking pot.
I started thinking. And I realized that I knew stuff.
but I didn't know how to sell it. So again with my engineer's brain, I had the problem defined, selling stuff. So I went off and I did,
Same thing again. I went to Amazon to solve all my problems.
And I read everything I could on sales and marketing. And some of it clearly didn't apply. The stuff for the manipulative, small-scale selling stuff didn't apply. But a lot of the grown-up stuff that consultants do,
particularly the book at the top, Spin Selling, was particularly useful, and Trust-Based Selling. A lot of the stuff that the big consultants do, where their job is not necessarily so much to give them ideas as much to sell the ideas, they were really, really handy. And they got me thinking. And I thought and I thought and I thought. And I realised I'd never be a shiny suited consultant. It's just not my particular style.
But I did come up with a little bit of a solution, and I'm going to run through that now, because I realized that the problem, and it's actually a silly way of putting it, this is like one of those, dull, that's so obvious, it's not even actually worth saying. The problem is that people resist change. This is what all the books talk about. So they give you techniques generally for overcoming change. And I figured out that to fit with my personality,
I needed a way to sell new ideas
which didn't provoke so much resistance. So a lot of the sales books talk about raising objections and either avoiding them
as one sales technique, or tackling them straight on and having an answer to all of them. I figured out that for me, the easiest way to sell what I wanted, which is for more people to do Agile and Lean and Kanban and TOC and so on, was just to avoid the resistance. So what I've got next is four
different techniques or approaches. And I'm going to focus on the last one, but I'd like to mention the first three because they were also life-changing things. And I think if you're struggling with the same kinds of things that I've struggled with, then you'll find them really useful. The first one, which is actually really hard to see at the top, are crucial conversations. Can I check, has anyone read that book? Just a few of you, three, four, five? Okay, so if you can imagine that you're working in a place and you're finding it really frustrating, this is the book you read to get your head, to rewire your head a little bit, to be able to have difficult conversations. It's an absolutely outstanding book that changed my life. And the company where I currently work, about five or six years ago, the CIO is a friend of mine. He read the book. He went away, he got a bunch of his senior people to go through and put on their own training based on what they'd read in the book. And apparently, looking back, they said it took it from a culture of over here, where people were like this at each other all the time, to a much, much nicer culture. And I've seen very, very few... I've not really seen anything else that's had that effect on an organisation of about 400 or 500 IT people. Okay, so I strongly recommend that one. Basically, it teaches you how to address difficult topics just using safe words.
There's even little sort of like scripts in it that show you how to speak in ways that don't cause resistance.
This one here is called skeuomorphism. And I don't know the French word for that, but I suspect it might be exactly the same.
Can I check, has anyone heard of skeuomorphism?
One, two, yeah. It's normally, when you hear it now, they're people complaining about slightly outdated Apple software that's been designed to look like real-world equivalents. Skeuomorphism is a brilliant, brilliant idea and I first picked it up from Seth Godin maybe 15 years ago and
And the general idea of skeuomorphism is that you dress new ideas, which might frighten people, up in old clothing. And it just makes them feel familiar. So a classic example is the rivets that are on jeans. They serve no practical purpose, but if they didn't have them, they wouldn't be jeans. Does that make sense? Yeah? If you have a digital camera and you click it and it makes a shutter sound, that's mimicking.
A real physical sound that old cameras used to make. These days you don't need it. It's an MP3 file making a sound at you, but it's dressing up this new technology with something old that makes it feel safe and familiar for people. If you race around Paris here, you'll find lots of old buildings. With the old facade. The outside looks and it fits in just perfectly with the old buildings, but on the inside they've renovated them so they're all modern. Again that skeuomorphism because if they tore them down and replaced them with new stuff, sometimes that works, but a lot of the time it just causes angry tweets and messages to the newspapers. So dressing old new ideas up in old clothing makes them just feel safer with people.
And the last one. But it's dressing up this new technology with something old that makes it feel safe and familiar for people. If you race around Paris here, you'll find lots of old buildings with the old facade. The outside looks and it fits in just perfectly with the old buildings, but on the inside, they've renovated them so they're all modern. Again, that's skeuomorphism because if they tore them down and replaced them with new stuff, sometimes that works, but a lot of the time it just causes angry tweets and messages to the newspapers. So dressing old new ideas up in old clothing makes them just feel safer with people.
And the last one. That's my book, but it's actually stories in general. Sorry, we've lost a little bit of the top and the bottom here. So the last one is what I'm going to talk about next, which is stories. Stories, if you remember, are sneaky little bastards. I'm going to talk through that now because I found that this is the most useful thing that I've stumbled on. Actually, sorry, I've missed one, haven't I? Socratic irony. Ignore that bit about the stories. This guy here. Do any of you, who's old enough to recognise Columbo from the TV series? Right, sorry. Socratic irony. Socratic irony is a lovely technique of deliberately acting a little bit dishevelled. And a little bit silly in a way that forces other people, when you're working to them, to do their own thinking. So Columbo in the TV series was this bumbling detective who was always dealing with these clever murderers and he kind of bumbled his way in and he'd almost tricked them at the end of the show. He'd say, oh, just one more thing. Then he'd ask them the little question that was bothering them and they felt they were safe and then he'd solve the crime, they'd go to jail. In the real world, I do this now, it's become my natural style.
For a lot of the time, which is I find that if I tell people what they should be doing, then they go, okay, that's good, and they do. If I sit down and I talk to them and I don't give them too many of the answers, just maybe little hints and nudges, and if I deliberately keep my mind quite ignorant of what all of their details are, then they usually stumble upon the solutions themselves. And when they do that, they make it work. I've got a story coming up about that. And then the fourth one is stories.
Stories of sneaky little bastards. And there's a whole range of stories, but I'm not talking about this end here. I'm not talking about big, big books like The Goal, or My Book, or The Phoenix Project. Those are all stories that are great. They take a lot of effort for people. Monsters, Inc. If you've seen that, you might not realize it, but it's actually a business story. They end up saving a factory by being nice to kids.
In the middle here, we have these ones here, maybe an hour's worth of effort.
The Fables, The One Minute Manager, Who Moved My Cheese? And there's a lot of little small books that people will grab up and they take maybe an hour's worth of effort to consume. But they contain nuggets of ideas. I'm not talking about them either. I'm talking about... Even smaller stories, anecdotes, metaphors, or especially pertinent
little jokes. Here's one.
Can you all read that?
So, QA engineer walks into a bar, orders a beer, orders zero beers, orders a big number of beers, orders a lizard, orders negative one beers, orders that. Of course, that's not very funny unless you know that that's what testers do. But it actually carries quite a punch because you go, oh God, that's exactly what testers do. It's not silly after all. This one here, I'll just read it out in case it's tricky at the end. Pointy-headed boss, who you might notice doesn't actually have a pointy head. He's got quite a round head. But our goal is to write bug-free software. I'll pay a $10 bonus for every bug you find and fix. Woohoo! We're rich! Yes, yes, yes. And I hope this drives the right behaviour, says the pointy-headed boss. And Wally, I think his name is, says, I'm going to write me a new minivan this afternoon.
Do you all see the truth behind that? Yeah, it's hidden in there and something that makes you laugh and you think, yeah, that's funny, but it only makes you laugh because there's actually quite deep truth in there. Now, this one isn't particularly funny, but what you need to know here, this is actually quite devastating. I went to a conference two years ago in Cambridge in the UK, and in the goodie bag they had one of these delightful little things. Along with a whole lot of books and stuff. And I grabbed this and thought, that's great. I'll never use it though, but it looks cool. And then, here's the tweet.
I sent the following morning. True, went to the loo at 2 a.m. This morning.
Bedroom door handle broke. Eek, trapped. Rescued myself with the conference goody blade. Which isn't particularly amusing, really. There's not a great big lesson hidden behind it. Until the following day,
I tweeted this, had two pints at the conference, woke at 2.30am needing to pee. Incredible. Bedroom door still broken. Didn't fix itself. How thick am I? So now that little story has gone from being something that's minorly vaguely amusing, because it happened to someone else and was quite distressing for me at the time,
to kind of like, well, isn't there this silly thing that we humans do? We notice things are wrong, and then we don't fix them straight away, and we probably should. Now, this one.
This one, you may have seen this before. It's one of the most useful little videos to explain lean and the idea of trying to get more done by just overworking, by working beyond your capacity.
It comes from the 1950s, I think.
You were downstairs boxing chocolates. Oh, they kicked me out of their class. Did I? I can't pinch you to see what kind they were.
I didn't do so well either. Oh, my girls, now this is your last chance. If one piece of candy gets past you and into the packing room unwrapped, you're fired. Listen.
Yeah, we can have a little, okay?
Yeah, that's well worth a clap to him, 50 years ago. Who's seen that before? Anyone? Just a few of you. I love Lucy, Chocolate Factory. Google it, show it to all your friends tomorrow. And who's been in that situation in real life? Everyone, pretty much? Yep, nodding around. Show that to people. And if you tell people, you guys are overworking. You're working too hard. It's causing all sorts of quality problems. I'd like you to slow down. Slow down. No, we can't slow down. Show them that. People nod and go, oh, yeah. How embarrassing, that's us. And they keep wanting to shout at us and speed it up, speed it up. So take that one there and then...
This one here, serendipitously, it sort of snuck up on me a few days after, just before I was about to present this for the first time. There's this great British bake-off program in Britain, and that chap over there is a baker, and he's become the favourite of every lady over 50 in Britain.
That guy there is Sterling Moss. He was a long time ago an incredibly fast racing car driver, a British icon. Paul Hollywood, the guy over there, the baker, has decided now that he's got famous and rich, he wants to go off and race cars. So he's asking this guy a little bit of advice.
So, ladies and gentlemen, I'm going to ask you to go.
I was just sitting there and I was thinking about it. If you drive a new focus club,
So, home drive, I'm not happy. You can just get up on your face, dude. You get up, you can make your mistakes. That's the point. You know the hard way is to be more safe.
Right, so just in case you couldn't hear that very well, this racing car driver is saying if you want to go faster, drive a little bit slower, because that gives you time to recover from mistakes, and otherwise you'll get egg on your face. So it's the same lesson really as in the chocolate factory, just slightly differently told. So see with the things you've seen there, there's quite a little pack of wisdom in each of these little stories.
But they make you smile, or they make you think, they feel quite harmless. So here's another story, this is my favourite story. It's a story about a story inside a story.
But this one happened a couple of years ago, three, four years ago to me. It was a team.
They had a great big bunch of defects, really high priority defects, and they had to get rid of them. And this is in an old legacy system, and it was ugly, ugly work.
And they asked me to help them out. Just to go along as the agile guy, see if you can get this bunch of COBOL Oracle programmers. Is there anything from agile you can kind of lend to them that might be useful? I went there full of enthusiasm.
And I knew what the answer was within two minutes, and I think you will too, just as I go through this. This is my version of the goal, the lessons, the main lessons from Ellie Goldratt's The Goal, The Theory of Constraints. So I walk up with the manager, Elaine, lovely lady, and she shows me their boards. They have about a hundred stickies on there representing about 10 to 12 months worth of work and they want to get rid of them in eight months. And walk up, look at the boards and go, hang on, there's a board missing here. Where's test? And it happened to be hiding behind the programming one. And so we pulled it out and she said, well, we're didn't used to need it, but there's so many stickies now, we had to get their own board for the testers. There's two of them, or three of them in the team. And I look at that, and I look a little bit closer, and I see these guys here are effectively in a waiting room, the ones with the circles around them. They're waiting for testers. These ones... Ones that are going to be shipped shortly, and those are the ones that they've been working actively on. And if I'd actually done this correctly, there'd be twice as many stickies in that one there. So I look at that board, and I'm sure you can all see it. The first three phases, the first three steps, the first three rolls, are running much, much faster, fixing defects much faster than we can actually test them. So there's a big pile up of work and it's just sitting in there. She grabbed one at random and it was 13 months old. That's how long it had been sitting in that pile there. Now, you might be thinking this is obvious, but until you've got kind of like bottleneck glasses that you can look at things and go, oh, there's a bottleneck there and it's testing. Most people don't see this.
So I run through some numbers there, and we just get some very quick approximate numbers. How long is it going to take to do each of these? 20 minutes, 25, 15, and 10. Sorry, that's how many a month can you do? So we've got rough, relatively speaking,
can see here that those guys are actually running faster than this one here. So it clearly is the bottleneck. So I go away, talk to people for about a week, just off and on. People in the team, the 16 of them, just try and figure out that I'm not being silly. And then I ask them the question, have I told you the story about the slowest buffalo? And they all look at me blankly.
And they go, no. And I'd already explained to them this bottleneck stuff, and they were looking at me going, why are you telling us all this stuff? That's not our problem. We're just programmers. We're just working really, really hard. This meeting's a waste of time. So I told them the buffalo story.
It started out as a conversation on Chairs, the TV program, except it didn't really. It was just an email that went around about 15 years ago that said it did. And the character, Cliff Clavin here, comes in according to this. It's a joke. And he says, well, Norm, you see, it's like this. A herd of buffalo can only run as fast as the slowest buffalo. Like this. By the way, you should give me a round of applause. It took me about three hours to animate that.
The slowest buffalo stay at the back of the herd, and the faster buffalo run in front, but at the slower speed.
And if they didn't, the herd would split apart. Does that make sense? Yep. This is actually how it works in nature, apparently.
If they ran at full speed, they split apart like that. And then when they split apart, they would be prone to being attacked from all angles by wolves, rather than just at the back. Does that make sense again? Yeah?
So we've killed off a few of the stronger buffalo there, which isn't good. And evolution favoured the herds that didn't spread apart.
And when these tightly packed herds were hunted, the wolves killed the slowest and the weakest buffalo. And where were they?
At the back. Apparently. If they ran at full speed, they split apart like that.
And then when they split apart, they would be prone to being attacked from all angles by wolves, rather than just at the back. Does that make sense again? Yeah?
So we've killed off a few of the stronger buffalo there, which isn't good. And evolution favoured the herds that didn't spread apart.
And when these tightly packed herds were hunted, the wolves killed the slowest and the weakest buffalo. And where were they? At the back.
Now. That made the remaining herd stronger. See that? You kill the slowest, the rest of the herd speeds up.
See? And we're much faster. So here's the joke bit.
Hang on, sorry. In much the same way, the human brain can only operate as fast as the slowest brain cells. This is a well-known medical fact, I promise. And now, as we know, excessive intake of alcohol kills brain cells.
But naturally, it attacks the slowest and the weakest brain cells first.
Make sense? You've all witnessed this.
And in this way, regular consumption of beer eliminates the weaker brain cells, making the brain a faster and more efficient machine. And that norm is why we always feel smarter after a few beers. There you go.
So, they have a little bit of a laugh.
And then I ask them, where's the slowest buffalo in your team? Because there's two serious things in here. One is that the speed of the herd is determined by the slowest buffalo. But it's also the thing we get that a lot of people don't nowadays. Especially more so in the past, is that we have to have the herd running together. Herd that's running together is low work in process. One that's spread apart is bad and it's not. It has all sorts of bad consequences. And that's exactly what they were suffering from. So I asked them, where's the slowest buffalo? We've already had the conversation about this. And they go, oh, it's test.
And then I ask, how can we speed up the slowest buffalo? Really obvious question.
And they say, feed the testers to the wolves.
And then the testers go, ha ha, and they all have a bit of a laugh. And then there's something magic here at this point where they've had a laugh and they have their own little laugh that they've created. And I just need to shut up then because they now know what their problem is and they know much, much better than I do. How to solve it. And they solved it miraculously. They got 35%. In fact, I'm going to slide through these guys here because you don't need to know the rest of the details.
They got 35% more productivity out of that team.
By working far, far, far fewer hours. The only place they could get more productivity was to figure out how to get the testers running faster. And the biggest thing that they could do to do that was to get the developers and the analysts and the designers to help the testers, not to do manual testing, but to do all that other stuff that automates stuff, go through before the testers are going to work on it, and look at the problem, and then help the testers. do half of their work prepping it to say this is what we think the behavior should be just a whole lot of stuff and within Eight months they had obliterated their problem. But in context, this is the theory of constraints, and this is a mixture of TOC, a mixture of lean, and a mixture of agile thinking, but mostly TOC. It's getting them to figure out where to focus and let them do the thinking. But wrapping it up inside a nice little silly story really helps them get them in a frame of mind of actually solving their own problems. Because I honestly wouldn't have come up with any of the suggestions they did. And if I had, I'm pretty sure they would have ignored me.
So, that says at the top there, delegate the telling to the story.
Okay, so that's what I did.
You know the idea of a Trojan horse? Okay, just think of stories as Trojan stories, the Trojan horses. And they've got a smile on their face. There's a lesson hidden inside them, but it's easy to unpack it, find the principles there, and then apply it. And the jokes don't need to be particularly funny, but it has this lovely... Thing of making the stories and the lessons inside them feeling quite harmless and friendly. It's like the horse is smiling. And it really helps if the joke is memorable and sticky and easy to reproduce.
So I bet, I know this for a fact, you guys, some of you will go back to your work tomorrow, you'll be having a coffee with someone and you'll say to them, oh, that sounds like that buffalo thing. You'll hear it, that sounds like that buffalo thing. Let me tell you the silly little joke I heard by some
fat bloke the other day. And you tell the buffalo story, you'll tell it differently to me, you'll fumble it like I did as you're telling it, but then you can just say that's Socratic irony and you're deliberately getting it wrong. And you tell the story and people go, ah, okay, then they'll go away, they'll take that story with them in their head and they'll think about it. And as they're thinking about it, that back bit of the brain that does the work, sitting and go, you know, that's dead right, the herd spread apart, who's the slowest buffalo?
And then they've done more than half of the work at that stage. Now, Made to Stick is one of those extraordinary books. I just absolutely love this book and I'd recommend you all read it if you're interested in what I'm talking about. They have a success criteria here. Stories should be simple.
Unexpected, concrete, they should be credible, emotional. Especially, that's why I like jokes, because they make you laugh and you just, it's just as something happens in your brain. And they say that stories are the best way of getting ideas across and they are flight simulators for the brain. And I know whenever I tell that buffalo story, people carry it with them and they do something with it. I have another story in my book about how Agile is effectively the inverted pyramid method that journalists use. And this chap here, Derek, must have seen me speak somewhere. No, actually, I think he read my book. And he said, every time I read a newspaper article now, I'm reminded of the story about the telegraph, Abraham Lincoln and Agile. It's because the little stories, they stick in their mind, they can carry them with them. Now, there's another one which I bet isn't going to come up at the bottom of the screen here. If your eyes could scroll down, you would say, I'm actually going to correct this because I think success actually needs another S at the bottom. So they should be sneaky.
Sneaky.
I hope in my accent it sounds like I'm saying sneaky.
Oh, uh-oh.
Oh.
Ah, good stories move. Did you see it?
Good stories move. It's not a story if there's not movement.
And you know when it's not moving because it just feels like you've got blah, blah, blah. Movement, your mind will follow it. You can't help it. Look, you're all following me now. See that? Stories need movement. And also, Alfred Hitchcock. Real world. You all know the real world. The real world is messy and boring and convoluted. And if you marry to anyone that tells you real world stories, good luck.
Good stories.
Is a life, but with the boring bits taken out of them. Okay, so drama is life with the boring bits taken out of them. That bit there will get you 90% of the way. And Alfred Hitchcock kind of knew what he was talking about. So where do you find stories? Well, I find that For me, I mostly copy other people's stories. But usually I have a concept I want to get across, and then I see someone else's story. Steve Jobs has some wonderful stories. He has a lovely little story about... When he was a kid. It's a story about continuity. Newest improvement. And you'll recognize this model if you've ever put together an Agile or Kanban team. It always starts rough, but then it gets better. He talks about when he was a kid. He's wandering along his little neighborhood. Some nice old man that lives there says, come into my garage, young man, and I'll show you something interesting. And this is in the 70s or 60s, so it was quite safe to do that. So he wanders into the garage, and the man pulls out a bag, and he says, look, inside the bag here, what are these? And he reaches in, and he pulls out some gravel.
Some stones, little tiny icky stones. And he goes, they're stones. He goes, yes, yes they are stones. I went out and I collected them this morning. He takes the bag and he wraps the thing around it and then he goes over to the corner of his garage and he chucks inside this big old industrial dryer.
And then he switches it on and he says, come back this time tomorrow. And he walks out and you hear the clunk, clunk, clunk, as this thing turns around and around and around. And he comes back the next day and they open up the bag and there's all this grit.
And he pulls out the stones. And they've been polished. And they're polished gems.
Now, you hear that, you think, that's a good story, but I use that over and over and over again with teams that are working with, that are new to Agile, or even just teams that are familiar with Agile and they're new. Oh, yeah, our job. That's why we do all this retrospective. It's to knock all the grit off. We're polishing the stones. So I mostly copy stories. But what you've got here is two things. You've got a concept that you're waiting to find a story for.
And you've got amusing stories, and it's when those two meet that the magic happens. And sometimes you just stumble across them. So can I...
I'll just skip to this one here. Can you guys see this? Can you see what that is? It's coming up a wee bit funny there. A few years ago, I went to a restaurant. It was about six or seven years ago. It was in San Francisco. Went out to this fancy, lovely steak restaurant that apparently was quite famous. And was probably famous for their rude waitresses more than anything. And sitting down there, and this waitress comes in and says, oh, what would you like to order, sir? And I say, I'd like fillet steak, please. By the way, you could Google this, Google steak doneness chart, and you'll see what she pulled out of her top pocket. I said, I'd like fillet steak. She said, how would you like your steak done, sir? And I said, I'd like it medium rare, please. She goes, hold it there, sir. Pulls out a laminated card with this picture on it, doesn't have the words on it, but she gets me to point at how I want my steak done.
And I point to medium. And she goes, aha! I think she was a tester in the real world. Aha! You want it medium, sir. And then she goes off and they cook it. And then they bring it back. And the weirdest thing happened then. They sit it down in front of me, steak. And I pick up my knife and say, thank you very much. And I'm about to cut into it. She says, please, sir, can you cut into the steak and then look at it and tell me if it's done how you like it?
Do you see there how we've got this...
We live the steak story every day. We didn't used to, and they used to overcook the steak and end up with a great big long testing phase. So she started out by trying to figure out how they would know if the steak was done correctly. So it's test-driven thinking in a restaurant. So when I work with testers who are unfamiliar with all this agile stuff, or even worse, more sensibly, they're actually cynical of a lot of the crap we talk. I tell them this little story and they go, oh, we could do that. I stumbled across that story and it was a story I needed to help me do my job better. Because when I tell people directly what to do, they don't like it nearly as much as when they figure it out themselves. Right, now I'm going to finish on this last video here.
Just hoping you can hear it. Can you guys, if the volume's up, can someone? So I'll just make sure.
I'll just see if it's loud enough.
That enough? to help me do my job better. Because when I tell people directly what to do, they don't like it nearly as much as when they figure it out themselves. Right, now, I'm going to finish on this last video here. I'm just hoping you can hear it. Can you guys, if the volume's up, can someone... So I'll just make sure.
I'll just see if it's loud enough.
One of the most important things that parents do is we teach our children from time. We teach them important things like reading the Bible.
Well, she's in that some home.
I'm going to teach you to read a clock. I'm going to teach you to read time.
Why?
Because it's important that you know the time.
Why?
Because how would you know when to go to school? Don't be mad at me.
Don't be mad at me. You're late.
What if we both find that? We go to school.
How would you want to break those walls? I mean, I don't know.
Somebody comes along to you and says, what time is it? And you didn't know, you'd feel stupid. Well, I didn't feel stupid.
I did it myself, my son. I'm teaching you the clock. This is a clock, it's not actually a clock. It is a clock, but it's not a clock. It's a watch, it's called a watch. It's a wristwatch, because it's on my wrist. Yes, it's a wristwatch, because it's on my wrist. And I watch, yes.
There's time is made up of zones, periods of time, all right? There's hours, minutes, no, not hours, not hours, but hours. They don't belong to us, it's a different spelling, H-O-U-R-S, not hours.
It's silent, I don't know.
Now every day there are 24 hours, 24 of these hours, 12 in the day and 12 in the night. I know I said there are 24 hours in a day, 12 in the day and 12 in the night. But a day is made up of a day and a night.
Why are you stupid?
I couldn't very well say Monday, Monday night. Everybody knows when I say Monday, I'm talking about the 24 hours. Now shut up and listen.
Now, on every clock, all watch, there are three pointers. They're called hands, all right? They point to the arm, all right? You understand? There's the arm hand, that's the first hand, the arm hand. The second hand is the minute hand, and the third hand is the second.
We'll do the leg, forget about the third hand. Forget it! It's gone, all right? It's gone. Now we have two hands.
On the face of the clock, there are two hands, all right? There is the other hand, which is the fat hand, and there is the thin hand, which is the middle hand. So you have a fat hand, All right? Fat hand and arms, thin hand, minutes. Right. Now, on the top of the clock, you see the number up there, one, two. One, two is 12. It's not three.
If we three join them together, we already have three here on the side by itself. We don't need two blank three dot clock.
So it's 12. All right? One and two is 12. So when a fat hand and a thin hand are pointing at the one and the two, it is 12 o'clock in the daytime. It's going to be dark and you'll never see it.
Our thin hand starts to move away from the fat hand. It likes the fat hand.
Yes, it likes the fat hand, but if it wants to tell the time, it has to go away from the fat hand. So it moves away from the fat hand, leaving the fat hand of the one and the two, and then it comes over to the one here by itself. See the one to the right of the one and the two? Now, that one is five.
Because it is. It's five. Two is ten. Three is fifteen. Four is twenty. Five is twenty-five. Six is a half.
Because 12 is a whole, so 6 is a half.
7 is 25, 2 are 35 parts.
So now what's actually happening is that thin hand is moving around the block from the one to the two, which is a five with a ten. And while he's doing that, the fat hand is moving slowly away from the one to the two. Yes, because the fat hand moves slowly, that's why fat thing one
Okay, so that was Dave Allen. He was an Irish comedian. He died in 2005. And he did something quite unusual, which is that when he started out, he was doing, in the 60s, he was doing his normal comedy routine that everyone did then.
The stuff we don't find usually very funny these days. And then he went to Australia and he was doing a comedy routine and a friend of his was apparently a famous opera singer over there. And she said to him, Dave, you're an idiot. You're up there doing what everyone else does. And you're kind of funny, but when you You and I sit here and talk. You tell me stories about your life and they're hilarious. And you have me rolling in the aisles. Why don't you try telling those sort of stories as part of your routine? And that's exactly what he did. He started telling little stories and then he moved from Australia. Eventually he ended up being one of the most influential comedians in the BBC and across the Commonwealth. And a lot of people attribute him, we're starting off the alternative comedy scene that we all just take for granted today. But hidden inside his stories, they were funny, yes, but... A lot of them were actually quite subversive. They were very, very critical in a hilariously funny way of the church and the state.
In the 70s in Britain and Ireland and so on. And he actually changed the world. He's one of those few people in history that actually changed the world. He got people to laugh, and they laughed at things that were so ridiculous that they couldn't help but start thinking about them later. The reason I showed you that one is one day I stumbled across it. When a bunch of analysts where I work were showing it to some of their customers and they were trying to explain the concept of ambiguous requirements. Make sense?
So, that was him. Now, I'm just going to finish in just one moment. I just want to read you a three-star review I got for my book. But before I read any further, let me tell you that if you would like to read my book, it's a business novel. It's got 4.6 out of 5 stars on Amazon. People really enjoy reading it.
Email me and I'll send you a free copy. And tell me whether you'd like the daily edition, where I send you a chapter a day, which is the agile way, or if you'd rather get the whole lot in a one-er.
Clark.Ching at gmail.com. There's an E in Clark. Okay, so let me just read you this review. This is the worst review I've got, but I kind of like it. I quite enjoyed this. Obvious business nonsense, but still quite readable. I write software for a living and have managed projects, and I can see some reality here, but also a fair amount of bullshit. The author plainly makes money from writing books, not from writing software. So if you'd like a free copy of my book, I think you'll find it really useful if you're in the business of trying to make money, deliver projects on time, and using Agile to do it. Okay, that's the end of my rather crappy advert.
Now, last thing, I want to thank you and just ask Do you know what an air worm is?
Okay. You know how you get a song in your head and you can't get rid of it? Okay, so I'm sorry about this.
Thank you.