The Changelog: Software Development, Open Source - Back to Agile's basics (Interview)

Episode Date: October 31, 2019

Robert C. Martin, aka Uncle Bob, joined the show to talk about the practices of Agile. Bob has written a series of books in order to pass down the wisdom he's gained over his 50 year software career ��� books like Clean Architecture, Clean Code, The Clean Coder, The Software Craftsman, and finally Clean Agile — which is the focus of today's discussion. We cover the origins of his “Uncle Bob” nickname, the Agile Manifesto, why Agile is best suited for developing software, how it applies today, communication patterns for teams, co-location vs distributed, and more importantly Bob shares his "why" for writing this book.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by Linode, our cloud server of choice. It is so easy to get started with Linode.

Servers start at just five bucks a month. We host ChangeLog on linode cloud servers and we love it we get great 24 7 support zeus like powers with native ssds a super fast 40 gigabit per second network and incredibly fast cpus for processing and we trust leno because they keep it fast they keep it simple check them out at lynda.com slash changelog. Welcome back, everyone. This is the Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, editor-in-chief here at Changelog. On today's show, we're talking with Robert C. Martin also known as Uncle Bob about the practices of Agile. Bob has written a series of books in order to pass down the wisdom he's gained over his

50 year software career. Books like Clean Architecture, Clean Code, The Clean Coder, The Software Craftsman, and finally Clean Agile which is the focus of today's discussion. We cover the origins of his Uncle Bob nickname, the Agile Manifesto, why Agile, which is the focus of today's discussion. We cover the origins of his Uncle Bob nickname, the Agile Manifesto, why Agile is best suited for developing software, how it applies today, communication patterns for teams, co-location versus distributed, but more importantly, Bob shares his why for writing this book. So we're joined by Robert C. Martin, or as you may know him, Uncle Bob.

Bob, first of all, thanks so much for joining us. It's my pleasure. I guess I'll ask the question that you probably get asked thousands of times, but I'm going to ask it anyway, which is how did you convince a bunch of strangers to call you Uncle? The year was 1988. I was working at a company. We were doing T1 telecommunication testing. And one of the programmers there was a guy who gave everybody a nickname.

And I was Uncle Bob. And he was one of those annoying people that would run around going, Uncle Bob, Uncle Bob, what about this? Uncle Bob, what about that? So I really decided I hated it. And I left that company a couple of years later, and I went to another company. Actually, I went to Rational. And nobody was calling me Uncle Bob. And it was weird. It's like, wait, nobody's calling me Uncle Bob. So I made the mistake of putting it in my email signature. And I was just starting to get very active on the internet in those days

and the news groups and the discussion groups. And it kind of stuck. And I went to a conference a few years later and people recognized me and they point at me and they'd say, Uncle Bob. And then I thought, oh, my God, I've made this horrible error. And I took it out of my email signature, hoping to expunge it. But it didn't go away and eventually i thought you know this is actually a good brand i should probably keep it so that's the story okay well it's stuck it did stick and now i'm happy for it it's fine do you get some inherited respect by being called uncle bob yeah i don't know if it's respect or not you know there's an uncle bob storage place out there that people often refer me to.

So, Bob, in your latest book, you're talking about Agile. Of course, you were there. You were part of the original group that penned the Agile Manifesto. Man, it was a long time ago now, 2001. 2001. 18 years later, you're here to write about it, going back to the basics of Agile. Tell us what's happened. Maybe introduce the folks to Agile, who many of us are just kind of living in a world where Agile is maybe like a bedrock of what we think we do or what we've been doing. And we know there was like a group of people and they wrote some stuff and it has to do with like not planning too much stuff up front. But a lot of us are actually foreign to the concept, and then what's changed and what's happened. So kick us off in that direction. Controversy in the long, long discussion.

So back in the extremely early days of software, going back into the 1950s or the 1960s, there was no standard process for doing software. Nobody knew what the heck to do. The programmers at the time were generally older people. They were in their 30s or 40s or 50s because there were no universities teaching software in those days. So they hired mathematicians and engineers and other people to do software. And these guys were older. And they very quickly adopted a style which today we would

squint and call agile. But in those days, they didn't call it anything at all. It was just kind of the way they worked. And they worked in short cycles, and they verified the outcome of those short cycles on a regular basis. And they wrote tests and so on. One example of that is the programmers who wrote the code for the Mercury space capsule, who worked in cycles that were one day long. And they wrote their unit tests in the morning, and they made them pass in the afternoon. Just one example of how the style started to enter into software.

And then in the 1970s, early 70s, there was this event. First of all, there were suddenly university programs that were graduating computer science graduates and a flood of 20-somethings poured into the industry, mostly male, by the way, for some reason, that we're still trying to figure out. And this flood of, you know, testosterone-laden 20-somethings poured into the industry. And I think the management at large thought, we've got to get some control over these boys. And right about that time, a fellow by the name of Winston Royce wrote a paper. And the paper was called Managing Large Scale Software Systems. I think that was it, something like that. And in this paper, he drew the standard waterfall picture. We're going to do analysis and then design and

then implementation and then testing. And he drew it with those nice little boxes with the arrows flowing down. So it looked like a waterfall. And he wrote this paper in an attempt to tell people that this is probably a really bad idea because nobody can actually do these phases in that order. And the paper is fascinating reading if you ever read it. Apparently, people did not read the paper. They just looked at that first image. And the first image was of the waterfall.

And everybody said, yeah, that makes perfect sense. And for some reason, for the next 30 years, that was the model that dominated us. It got put into all kinds of documents, process documents in the military and in industry. And I remember I was a young programmer at the time, perhaps I was 18 or 19 years old. And I remember seeing the articles in the trade journals come out about this idea that you could do the analysis first. And then when the analysis was done, you could do the design. And then when the design was done, you could do the implementation and you could put dates on those events. And I thought, oh, this is a godsend. This is wonderful. Because now, if the analysis

is done, you know you're a third done. And when the design is done, you know you're two thirds done. And honestly, we believed this. I believed it. Everybody believed it. It was so compelling. It descends from another branch of management called scientific management, which was a competing theory at the time. Very successful one back in the turn of the previous century. Anyway, that dominated us for about 30 years. And in the meantime, all the original programmers who had been in their 40s and 50s and 60s, they all retired and quit. And those of us who joined in the 70s kind of grew up. And 30 years later, we're all in our 50s and 40s and thinking, what the hell happened to us? And a bunch of us got together at Snowbird in Utah in 2001 and said, OK, how do we get out of this mess?

There had been a substantial movement in lightweight processes since about 1995. Ken Schwaber and Jeff Sutherland and Mike Beadle and Martin Duveau, they wrote a paper in 1995 about Scrum, real early paper about Scrum. Jim Coplin in 96 or 97 wrote a paper about the processes used by the most successful organizations. And this introduced some of the ideas of Agile. Kent Beck started promoting his extreme programming ideas in about 1999, 98, 99. Pete Code, who was running, I can't remember the name of his company at the time together soft uh he had started promoting his particular brand of lightweight process and there was this this large multi-faceted movement uh throwing off waterfall and trying to trying to

use a much lighter weight approach all of them based weight approach, all of them based on short cycles, all of them based on feedback. And so it was this group that met in 2001 at Snowbird. And Martin Fowler and I got together at one point and we sent out an invitation. We said, hey, let's all meet somewhere. And Alistair Coburn suggested Snowbird. And so let's all meet somewhere and alistair coburn suggested snowbird and so let's all meet at snowbird and we'll get together and we'll talk about this and we all got together at that meeting and and you know when you get a bunch of opinionated people together in a meeting it doesn't usually work out well and usually they you know there's a lot of spitting and hemming and hawing and posturing. Yeah. Well, it was 17, right? And the magic happened.

Somehow the magic happened. Now, this group of people has never met again, don't want to meet again. I don't know that we all like each other very much. You don't have a 20-year reunion coming up. We tried the 10-year reunion. And most everybody got – this was at the Agile conference. The Agile conference tried to organize it. And most everybody came.

A few people didn't. Even then, it was like, okay, we're on stage, you know, whatever. But we didn't have a lot to say to each other. It's like, you know, the magic happened once and it cannot happen again, at least not with that group. But it was a very productive meeting. And at some point, I think it was on the end of the first day or the beginning of the second day, somebody put those four magic lines on the board. And I think it was Ward Cunningham, and Ward thinks it was Martin Fowler, and nobody

really remembers properly. But it was those four magic words saying, hey, you know, the old way was good, but there's this other way which we think might be a little better. So we prefer one over the other. And we all thought that was the appropriate way to state it. Now, at the end of the meeting, we thought, well, nothing's going to happen with this because that's the other thing about meetings like that. Maybe they come to some kind of conclusion and they leave a crater behind and nobody ever cares to look into that crater again. But in this case, Ward Cunningham did something smart. He said, I'm going to put this on a website and I'm going to let people sign it.

And we were stunned. Tens of thousands of people signed this thing, and it started a movement. There you go. So you had the four values and 12 principles that came out of those four values. People signing it. This was 18 years ago. And then, I mean mean things proceeded from there and i would say that modern day software for the most part is written at least ostensibly in an agile world or an agile milieu or we think we're we're agile and there's a lot of buzzwords that have been come attached

to it there's a lot of like subclasses you list out a few of them in the book lean kanban safe xp scrum like there's all these things there's consultants there's trainings there's just a whole like a cottage industry if you will around this process or these ideas yes that's true. So the most successful thing about Agile is the word Agile. Everything else, maybe not so successful. The original concepts almost instantly started to get muddied and lost and twisted and turned, and people would ask, well, what about this or what about that? Can we use Agile to learn how to play the piano? and turned and people would ask well what about what about this or what about that can we do

can we use agile to learn how to play the piano can we learn can we use agile to do uh uh marketing of toothpaste um so people wanted to take it and twist it and turn it in many different directions and and you're right the consultants got into it i was one of them. And we were trying to figure out a way to get companies to change to use Agile. So this was called the Agile transition. People are still selling Agile transitions today. And that was very difficult, very, very difficult because people don't want to change and they want to keep using the same methods. So that was very hard. And people would push back on the rules and twist them and turn them. It was a very unsatisfying period. Until, and this didn't fix the problem, but there was an event.

And the event was Ken Schwaber. Ken Schwaber came to me probably 2003. And he said, Bob, I'd like to use one of your classrooms. At the time, I had a company. There was about 20 of us. We were training people. I had a whole bunch of classrooms. And he said,

I want to use one of your classrooms. I want to teach a class called Certified Scrum Master. Oh, boy. And I listened to these three words, and I thought, these three words don't have anything in common. What could you possibly be teaching here, Ken?

But Ken was a friend of mine, and I thought, okay, fine, you can use it. And he said, in return, I'll let your people attend the course, and they can all become certified scrum masters. And I said, yeah, fine, whatever. I didn't go to it because I had to go somewhere else. Okay.

I found this on the web. Oh, Siri, thank you for helping me yeah all right siri is telling me so helpful so ken did this course and you know i thought it was a dumb idea i thought you know who wants to go to a course named you know certified who wants to have a certificate saying that you're a scrum master well apparently lots of people did. So I was wrong about that. And a flood of people started taking these courses. And apparently they liked the idea of certification a lot. And they liked the idea of having this piece of paper. What was very disturbing to me and remains disturbing to me is that these people were not programmers. These people were project managers. And so there was a flood of project managers that poured into the Agile community and literally took it over. The Agile conferences went from being technical

conferences to being management conferences almost overnight. And literally that didn't change. That has been the theme ever since. Agile has become a soft skills, people management kind of thing with, you know, soft ideas and loosey-goosey things and, oh, let's juggle and let's play with mice and things like that. And I'm an engineer. I'm a programmer. And most of the guys who went to Snowbird were very technically based, you know, hard to weren't into the real soft skills thing too much. Some of them were, but most of us weren't. And this was disturbing.

And we suffered it for a while. And then at one point, a group broke away and said, well, look, somebody needs to be promoting the hard skills. You know, test-driven development, pair programming, simple design, refactoring, those, the core of the technical skills within Agile. Somebody needs to be promoting that. And the Agile community is not promoting that. The Scrum folks had pretty much abandoned any of the technical practices that had come into Agile. And so the craftsmanship movement was born. And the craftsmanship movement was an attempt to reintroduce the technical skills and the technical disciplines back into Agile. The hope was that the Agile community would re-embrace the craftsmanship

community and there'd be a joyful kumbaya and everybody would be happy. But that never happened either. So here we are today in 2019 and there is this definite split. There's the technical people who like Agile, you know, they want to do Agile, but they want to do it with technical disciplines. And then there's the vast array of non-technical Agile people who are suffering through all the different adjectives. And the adjectives, you know, there's modern and there's safe and there's less and there's more. God knows there's a million adjectives put in front of Agile, most of which are there to satisfy either the differentiation of the company that's promoting them or the companies who don't want to do Agile but want to say they're doing Agile.

And that's where we are today. And that was really the motive for writing the book. The book is a back to basics book. It says, hey, this is what Agile was, you know, 19 years ago, 18 years ago. This is what Agile was. This is what Agile will always be. Here are the rules. Come read them. Here are the disciplines. They're simple. They're easy. They don't answer every question. They're not going to give you differentiation for a consulting agency. They're not going to let you, you know, learn how to do the piano in an agile way. But if you want to build software, here's a discipline that works. Yeah. So that's kind of the reason for the book.

Is it for an everyone book or is it for, you know, so is it for a software developer who's been there doing it for a while and they're relearning or retraining for lack of better terms, or as you say, back to the basics, does it, does it seem to assume that the reader is someone who's been in software? Is it for someone who's getting into software, trying to understand how to be on a team or build a team or run a team? It is, it is very much for people who are in software projects. It's not a technical book. I don't put any code in it. But it is a book for people who are technically minded and want concrete disciplines. And so it walks through the concrete disciplines that started Agile way

the heck back in the first place. So it's one part history, one part application, one part sort of definition and maybe some guidance. Yeah, that's a good way to put it. It does begin with history, that history I just told you. It goes into that at some detail. I rant in it a fair bit about what has happened to Agile and what needs to now happen to Agile. My views are not universal.

And so I included some people in the book who disagree with me. And so there's a couple of chapters that are kind of point-counterpoint chapters. They argue the other side of the case, which I thought would be valuable for someone who is trying to understand what Agile is and what all the opinions are about. Right. It's interesting, too, because there's so many, as you say, there's so many different variations of it. You've got Agile, XP, Scrum, Lean,

and I think you even mention in your book 5,320 other Agile methodologies out there. So it's like... He counted everyone. Well, no, that's what it said. I don't know where i got that number from i could probably tell you but you wouldn't want to hear right along yeah the point is that is that um people coming to this need some sort of some sort of direction and there's so many out there so many named ways to do agile it's like well where do i really begin how do i actually

do agile how do i? How do I achieve building software in a well way with a team and actually see results successfully, where we make customers happy, our business makes money, our software engineers and our teams, they thrive. Yeah. And the book tries to make the point that you really don't need to hire anybody to train you for this. There's plenty of material out there. The book is one offering. There's many others. There's plenty of material on the Internet that can teach you this.

A small team of developers who wants to work in an agile way will have no trouble finding the resources to help them through. If you want to hire someone, well, fine, be careful with that because they may have their own agenda. But it's possible for a small team of developers to work in an Agile way without an awful lot of effort. It seems like there's two kinds of trouble. There's the one that you see coming and the one that you don't see coming

because you don't think you have any trouble. And it seems like perhaps with Agile, there's an overriding thought of we're already doing it. And so, of course we're Agile. Because it becomes a marketing term. You don't want to be not Agile. A potential hire might say, are you guys Agile? And what kind of a hiring person is going to say no?

Of course we are. Right. So everybody thinks, we all think we're Agile. What are some surefire signs that you actually aren't? Like you're not, you think you're agile, but you're doing things in a different way. Well, so there's a couple of obvious giveaways. Number one is, are you producing something deliverable every week or every two weeks? Something that you could deploy. You may not deploy it because maybe it doesn't have enough features, but technically it is deployable. It's been tested. It's been documented.

It's done as far as what's been specified and you can deploy it every two weeks. Some people use one week. Some people use two. I like one. Some people use two. But that's a dead giveaway, right? If you don't have that, if you are not delivering something on an extremely regular basis, something that is deployable every single time, then you're not doing Agile. You are not doing Agile if you are not intensely communicating with stakeholders. The programmers and the stakeholders have intense communication all through the development cycle. If you're working off of a set of requirements that are written down and the stakeholders are on the other side of the

planet, you are not doing agile. There's no way you can be doing agile that way. You are not doing agile if you are not writing tests. If you do not have a suite of tests that can verify that the system you are writing works as specified, you are not doing Agile. You are not doing Agile if you lose control of the code. If you look at the code and the code is a mess and there's no way you can clean it up because it's just too hard, you are not doing Agile. An Agile team always keeps control over the code, always keeps the code clean because they have tests, because they refactor, because they use simple design, because they use those engineering practices. There's a whole bunch of other telltales that you could go into, but those are the most obvious, I think. Starting to sound like Jeff Foxworthy's You Might Be a Redneck If.

You're not doing Agile. You could have a whole stand-up routine where you're pointing out who's not Agile. Yes, well, I've actually done that on stage, but never mind that. then. This episode is brought to you by Codacy. Codacy helps developers and teams automate and standardize their code quality by instantly identifying issues through static code analysis. With Codacy, you get notified on security and complexity issues, gaps in coverage, and code duplication for every commit and pull request directly from your current Git workflow. Identify OWASP top 10 vulnerabilities, ensure code quality is standardized across all teams and projects by applying code patterns and customizing parameters, get visibility into your technical debt, and so much more.

With 30 supported languages and counting, you have options to use the cloud service or go self-hosted to bring Codacy behind your firewall with support for GitHub Enterprise, Bitbucket Server, and GitLab. Learn more, get started for free, and grab a sweet pair of Codacy socks at changelog.com slash codacy. Again, changelog.com slash codacy. Again, changelaw.com slash codacy. So, Bob, you said kind of why you did this book, but why did you specifically, you know,

you mentioned why it needed to be there, but why you particularly came back to this, this many years to write not just this book, but a series of books around agile encoding and, you know, clean coding and these ways you sort of prescribe things. Why did you particularly come back to this subject matter? I've been a programmer for close to 50 years, half a century. I am 66 years old. I got my first programming job when I was 18. I wrote my first code several years before that. So a very, very long time and and for most of that time I had no mentor no one to teach me anything it was it all had to be self-taught I began at a time

when the number of programmers in the world was probably numbered in the thousands maybe the tens of thousands now that numbers in the hundreds of millions. Someone with some experience needs to say to the very large number of people who don't have experience what mistakes they're going to make and how they solve them, what things are valuable and which things are not. And the need I felt to do that began probably about 15 years ago. And at first I thought, you know, who am I to tell people how to write code? Who am I? I'm just a guy. And then at some point I thought, no, somebody's got to say this. Somebody's got to write these things down. And I started on this path of of writing the clean series, the clean code book, the clean coder book, the clean agile book, the clean architecture book. There will be a couple more to come yet. And I think the I think the years that I've worked are the, I don't know how to say this, but are the justification for me writing a series like that.

How many programmers are there in the world now? I said there's something like 100 million. Yeah, I was wondering where that number came from. Well, so that's a soft number. It's hard to get the number. Yeah, that was funny. It depends on It's hard to get the number. Yeah. That was a – it was funny because – It depends on if you count the VBA programmers or not. If you count the what?

I missed it. The VBA programmers. You know, maybe the numbers – Oh, yeah. If you count Excel, now you're huge. Yeah. So, okay, but it's a large number. It's obviously more than 10 million.

It's probably somewhere between 50 and 100. And if we choose 100 as the number, then there's some really startling math you can do. The very first person to write code for an electronic computer was probably Alan Turing. There's some debate about this, but let's say it was Alan Turing in 1946. What kind of growth curve gets you from 1 to 100 million in, what is that, 73 years? Well, it's not linear. No, no, it's not. It's an exponential growth curve. For sure. Okay, well, all right.

So we're programmers. We can choose the base of the exponent. We'll choose the base of 2. So how many powers of 2 is 100 million? Well, 2 to the 20th is a million, and 2 to the 7th is 128, so about 27. So there's 27 doublings in the number of programmers from 1946 to now, roughly. Okay, well, that's 73 years, 27 doublings. That's one doubling every two and a half years. Do the number of programmers in the world double every two and a half years?

That's a hell of a question. And initially, I think the answer is no, because during the first decade, the doubling rate was much faster. First, there was Alan Turing, and then there were 10 guys the next day, and then there were 100 guys the next month. And then it slowed down there's very good evidence that the the current rate of doubling is every five years and you can look at this you can look at the age distribution of programmers to see this and you can look at the the one ad lists or the recruiting lists and see it see a definite trend. If the number of programmers in the world is doubling every five years, first of all, that represents an immense demand,

a demand that is growing exponentially. And it's pretty clear that that's true, right? Now we're seeing software written in thermostats and microwave ovens and little things that we carry in our pocket. Our car keys have software in them. You know, so the amount of software getting written is just enormous. And this doubling rate means that half the programmers in the world have less than five years experience. And this will always be true as long as we're doubling every five years.

And so we're stuck in an industry that is in a state of perpetual inexperience. And there aren't enough old guys to teach the new guys how to do it. If people look around at the software industry, they see a bunch of very young people. And they ask themselves the obvious question. Well, first say well this must be a young person's game all the old people probably go into management later or something you might ask well where did all the old old programmers go and then the answer to that is we're all still here we're all still here we're all still writing code we never went anywhere there just weren't very many of us to begin with. Your majority was already small. Back in that time. Yeah. The original cohort was very small compared to what it is now. And so who's training the youngsters coming in?

And the answer to that is almost no one. They all, youngsters training youngsters for the most part. Yeah. Almost no one. Yeah, youngsters. And of course, after a year or two, they think they know it. Oh, yeah, we know how to do this. And of course they don't. And so our industry is in a very precarious position.

Now, you put that on top of something else and you get a real firestorm. And the other thing you put it on top of is the fact that in 1960, our society lived without computers. Nobody had a computer at home. Nobody had access to a computer. A computer was something in a movie, maybe, a science fiction movie. Or a computer was something that was in a laboratory somewhere and it cost millions of dollars and only people in white coats used it and so on. But over the years, that's changed dramatically to the point now that in your house, there are probably hundreds of little computers. On your body, there are probably a dozen or so if you count your car keys and your phone and the battery case and your AirPods and the watch and whatever you've got on you. Literally on your body, there's probably a

dozen or so computers. In your house, there's hundreds. In your community, there are hundreds of thousands. If you go out on the road, every car out there has got software running it. And a modern car, and I don't mean a tesla a modern car has 100 million lines of code in it and that if you're a programmer that should scare the hell out of a lot of code who wrote that code and did they test it would you like to see the tests that for the code that is running in your car and and you think well okay most of that code is in the entertainment system and it's in the the uh the navigation system but a fair bit of that code is in the entertainment system and it's in the navigation system, but a fair bit of that code sits in the engine.

And when you put your foot on the accelerator, there is not a hard cable that goes and opens a butterfly valve in the carburetor anymore. There are if statements interpreting that pressure on your pedal. When you push on the brake, there's an if statement in there deciding how to apply the brake and where to apply the brake and when to apply the brake. And wouldn't you like to know what tests were done on those if statements? Our society at this point depends for its existence on software. Nothing can get done without software. No one can do anything without software.

You can't buy anything. You can't sell anything. No insurance can be bought. You can't microwave a hot dog. You can't wash the dishes. You can't wash your clothes or dry your clothes. You can't watch TV. You cannot make a phone call.

You can't drive anywhere. You can't do anything. No law can be passed. No law can be enforced without software sitting in the middle of it. Our society rides on top of software. And we don't quite get this yet. We don't quite get how vulnerable we are to all of this software and the people who are writing it. There have been a number of disasters. We can count them, right? There was Knight Capital.

You remember Knight Capital? It lost $450 million in 45 minutes because some poor software guy did something stupid. I won't go into the details, but it was a very sad story. Several dozen people have been killed or injured or maimed by cars that have run out of control and the brakes don't work because of software failures we could talk about the 737 max i suppose there's a software portion in there it's not entirely a software issue but there is a

component that is software uh we could talk about the um mess in California, right? And that's an interesting one because that's where you had some programmers actually lying and cheating at the behest of their company. Yeah. The company told them to do it, right? That's right. So we sit at this very interesting precipice. Our society depends on software, and the software is being written by vast numbers of people with almost no experience.

So that answers the question of basically why you wrote this book. You paint a scary picture. I love it. You love that? I mean, no, I love that reasoning why, because there's actually a section in the book which is which some of what he said is somewhat quoted from that. I wouldn't say it's quoted because he's the one who written it, but it's We Rule the World. It's talking about how software developers are super influential.

We, for lack of better terms, rule the world because so much sits at the software developers' hands to ensure people not being killed via software that, uh, doesn't work properly. And so I kind of understand the importance of it. It's really interesting to kind of look at the statistics of that and say, because of the doubling, how many people, uh, become software developers each year and how many of those are inexperienced because of the doubling factor of every five years that we double. That's just astounding to me. I never really considered those numbers. Well, and why would you, right? Because you live in this industry, you work in this industry.

Okay, you see a few more programmers from time to time, but you really don't see the impact unless you think about it. And it's been insidious, right? The software has invaded our way of life to the point that now, I mean, I can't tell the time without invoking a software system. And this software system on my wrist yells at me all the time. It gives me the news. It just yelled at you a bit ago. It talks to me about Donald Trump.

It's continuously talking to me about Donald Trump. It's remarkable. Yeah. Well, it's so stinking useful. There's no going back. There's no going back. It's impossible to go back. We don't want to go back. On the other hand,

society doesn't quite realize just how dependent society is on software. And it will likely take some kind of event. And that event will be some kind of horrible tragedy. Some poor software guy will do something stupid and kill 10,000 people. And when that occurs, the politicians of the world will not be able to ignore it.

So they'll have to stand up and wag their finger and point their finger right at all the programmers and say, how could you have let this happen? And you'd like to think at that point that the finger would not point at the programmers, right? It would point at managers. It would point at business people. But we saw what happened when the CEO of Volkswagen North America was called to testify before Congress about the cheating and lying that was done in the software of the Volkswagen car, he said, well, it was just a couple of software developers who did it. He just took the finger and moved it right back to the programmers. And to some extent, that's justified because it was a couple of programmers that did it, maybe more than a couple.

But, you know, it's our fingers on the keyboard. We are writing that code. How do we answer that question? When the politicians of the world finally stare us in the eye and say, hey, guys, how could you have let this happen? How do we answer that question? Do we say, well, you know, my boss told me it had to be done on Tuesday. If that's our answer. That's true.

If that's our answer, then we're toast. Right. And the politicians of the world will start to pass laws. That's our answer. That's true. If that's our answer, then we're toast, right? And the politicians of the world will start to pass laws. And, you know, that we'll be told what languages we can use, what platforms we can use, what signatures we have to get, what processes we have to follow. A bunch of guys, a bunch of bureaucrats will make these decisions, and they will get turned into laws. Don't you think that's inevitable? And we'll all work for the post office. I mean, good code or bad. I mean, even the best agile practitioners write code with bugs in it.

So I'm not saying don't try, but I'm saying that if the numbers are there and this is going to happen, even if the code was really, really well written, the regulation or the, it's still going to happen. The regulation is going to happen. There's no way to avoid that. In the end, it's got to happen. The question is whether we get to regulate ourselves or whether we are regulated by someone else. If the answer to the question, right, they come and they point their finger at us and say, how could you have let this happen?

And if the answer to that question is, look, this was an accident. It was terrible. It was horrible. But it was not because we were being negligent. And here's why. Here are the practices that we follow. Here are the disciplines that we follow. Here are the standards we uphold.

If we can come back with that statement, then we will probably escape the worst of the regulations. They will still regulate us, but maybe they'll use our own regulations to regulate. That's what the doctors did, right? The government finally went to the doctors and said, you guys are out of control. We need to regulate you. And the doctors handed them a whole bunch of rules. I've been working on these rules for 50 years. And the government said, oh, great, because we certainly don't want to decide that stuff. And they just made the doctor's rules the laws. That makes sense. That's kind of where I hope it all goes.

This subject we're talking about now is coming from chapter two, roughly. And the title for that chapter is The Reasons for Agile. So are you saying that I guess it would make sense if you're going to influence, as you mentioned, sort of rewinding a bit, the reasons why you wrote this book and the reasons why you're passionate about this is because one, you've got a lot of experience in software and two, you see the doubling and you see the influence and the, you know, sort of the impact of software in our world. And it would make sense to influence good software. And how do you do that, right? You would want to enforce, or in this case,

reinforce good practices for producing good software for good teams to produce good software. And so the reasons for Agile is to save the world. I couldn't have said it better myself. There you go. Yeah, the reason for Agile is to save the world. I think Agile is a component. Agile is one component in a much larger field.

Agile is a way to get a small group of people working together on relatively small projects. And that's really all it is. It's not a way to build the next air traffic control system, right? It's not something like that. You may use Agile in a bunch of little teams to build that air traffic control system, but Agile is not the overarching management system. Agile is a small thing for small teams teams so it's one component of the set of disciplines that programmers are going to need in the coming years but there are others there's the whole notion of clean code and testing and there's the whole notion of architectural boundaries and clean architecture the book clean architecture So I've been writing this series as a kind of

educational tools to inform programmers of what the future of programming ought to look like. This episode is brought to you by cross-browser testing of SmartBear, the innovator behind the tools that make it easier for you to create better software faster. If you're building a website and don't know how it's going to render across different browsers or even mobile devices, you'll want to give this tool a shot. It's the only all-in-one testing platform that lets you run automated visual and manual UI tests across thousands of real desktop and mobile browsers. Make sure every experience is perfect for everyone who uses your site, and it's easy and completely free to try. Check it out at crossbrowsertesting.com slash changelog.

Again, crossbrowsertesting.com slash changelog. Again, crossbrowsertesting.com slash changelog. Bob, in the section of your book called Iron Cross, you mention this concept of good, fast, cheap, and done. And that's the Iron Cross. And you talk about managers not understanding, in quotes, the fundamental physics of software projects. So when you say that, what do you mean by the fundamental physics of software projects? What are those? So this relates to the iron cross of project management, which is a fairly well-known concept

in project management circles. It's good, fast, cheap, done. Pick any three, you're not going to get the fourth. And why can't you get the fourth? Well, because something needs to be managed. There has to be room to manage something. If you could get all four of those, there's nothing to manage. So something has to be managed, and therefore you can't have all three. Now, the real job of a good manager is to set the

coefficients on all four of those. How good does it need to be? How fast does it need to be done? How cheap and how good, fast, cheap and done? All four. You set the coefficients on that. And this is one of the things that Agile tries to do by setting up this rhythm of every two weeks. Because you're starting to develop real features and you can deploy those real features every two weeks, and you can measure how fast that's going. You can measure by just looking how much is getting done every two weeks. You can measure and develop what we call a velocity, and that velocity is probably going to be really bad news.

You're probably going to look at the original schedule and realize the velocity is far too slow. And the good thing about Agile is that it tells you that early. So in some ways, Agile is a way of destroying hope as early as possible. Get the hope out of the project. Get the project down to reality. The reality is going to be bad news, but at least we get that bad news early enough that we can then manage the situation.

And you manage the situation maybe by changing dates, maybe by cutting features, maybe by adding staff. And you can do that early enough to make a difference. But if you get the bad news early enough, you can manage. Now that's the fundamental physics, right? You can't have everything. You can't ask programmers to come up with an estimate and then expect them to hold that estimate. Because no one knows. No one knows how long it takes to do software. No one knows how long it's going to take to do this project. And so you have to accept the iron cross, accept that you're going to be managing this by cutting something you want, cutting a

feature, cutting a date, cutting a budget, or increasing a budget by adding staff. You're going to have to face that because that's how you're going to manage the project. Let's talk about estimates a little bit because, as you said, nobody knows. And as somebody who's had a lot of wrong estimates in my life, I know very well, I've been doing this long enough to know that I don't know. And I often say to people, would you like me to lie to you in great detail or vaguely? Because you're kind of on a sliding scale there. What are some advice for estimates? Because while we admit that it can't be accurate, and it's a shame that people take an estimate and turn it into a concrete and hold you to it.

That's unfortunate, but it happens. There's still things that we can do to have better estimates or worse estimates, and you have advice on this. So what have you learned in terms of estimation that you can give to us, and we can take it and say, well, my estimates are better than they used to be because I apply this strategy. So the first thing to realize is why it's difficult to estimate software in particular. And the example I like to use is how long does it take you to tie your shoes? And maybe it takes you 10 seconds. If if you're good at it 10 seconds yeah okay 10 15

seconds and you don't even think about it right the motions are baked into your fingers you just have you zip zip zip zip and they're tied now estimate how long it would take you to write down the instructions for tying shoes and make sure that a robot can execute a more a moron you know a computer-driven robot right and all of a sudden you're looking at months worth of work months to try and get that done why because writing down the instructions of things is much harder than actually doing things and when programmers estimate they estimate something i think well you know that sounds awful simple and they they forget that they are trying to write down the programs for a moron to execute, for an automaton to execute.

Very, very difficult. Now, how do you improve your estimates? Well, first of all, you recognize that. You recognize that the way you're going to look at the problem is not estimable. It's not going to give you the right number. So then the next thing you do is you say, OK, because I don't know how 50s, 1950s, Program Estimation and Something technique. What you do is you say, OK, if everything goes the way it normally goes, how long would it take me to do this? And you come up with some number. OK, I think if everything goes the way it normally goes, it's going to take me three weeks. And then you come up with a number, number, another number. And this number is

if everything goes perfectly and, and to the extent that you have no fights with your significant other and all of your, your coworkers are polite and they don't bother you and there aren't any meetings, you know, if everything goes perfectly. Yeah. Well, and they call it the 5% scenario. You know, this thing, this has a one in 20 chance of being right. Well, maybe then I could get it done in two weeks. So I got two for the best case, three for the normal case.

And then you do the worst case scenario, which is the 95% case ratings. You've got a 1 in 20 chance that it could be this bad. And this is like everything goes wrong short of nuclear war. It's just terrible. Everything goes wrong. And you, oh, well, then it might take me 10 weeks. Because you've got this very interesting probability distribution, 2, 3, and 10. And that's usually the kind of curve that it really is. And you present that to management. Say, 2, 3, and 10. And that's usually the kind of curve that it really is. And you present that to management. Say, okay, guys, these are our numbers. It might be 2, probably going to be more like 3, and it might be as bad as 10. No manager's going to like that. The managers want to push the risk back onto the programmers.

They want the programmers to absorb the risk. And the programmers cannot absorb the risk back onto the programmers. They want the programmers to absorb the risk, and the programmers cannot absorb the risk. There's no way they can do that. So the programmers have to be honest with this probability distribution and face down the managers and say, look, this is the risk. This is the risk profile.

I can't do anything about it. Right now, these are the best data I can give you. This is extremely difficult for programmers to do. Managers will like crazy they'll try so well can't you just deliver by a certain date i mean can't and and the intimidation factor comes in right yeah and programmers are not trained uh in dealing with intimidation you know we we didn't get into this business because we like people you know we got into this business because we like people. We got into this business because we want to have our heads down, writing code, and not have people bother us. So when a manager who is very good at manipulating people comes to a programmer, the programmer usually has no idea how to handle this. That's why I wrote The Clean Coder.

The book The Clean Coder is all about situations like this. How do you handle the fact that your manager is going to over-intimidate you? And the answer to that in this case is you have to stick to those numbers and you have to avoid the traps. And the traps are insidious. Like, for example, your manager will come to you and say, well, can you at least try? And the answer to that is no. I'm already trying. I can't try any more than I am. How dare you even insinuate that I am not trying?

You don't probably want to say it that way. But the way you think about it should be that way. How dare this person insinuate that I am not trying now. These are the best numbers I can give you. Yeah. I had this experience long ago. I was in a meeting with a bunch of managers and I was running a group. And my group, I had met with a customer and I'd made some commitments to a customer. They were reasonable and rational commitments. The poor customer had already been delayed long enough. And then I went into this meeting with a bunch of managers and it was the typical kind of resource meeting.

We got to cut resources to go over here. We got this problem over here. We got to take from there to go to here. And these guys, I could see what they were doing. They were going to take some of my people. And it was very reasonable and very rational. And I literally threw a fit. And it's not something I normally do, right?

But in that meeting, you know, I just got so angry. I said, look, you know, we have made promises to this guy for months. I told him we were going to do this. You cannot take these people with something to that effect. And all these managers looked at me with a very different kind of respect and said, well, you've made a good point there. Now, my point was entirely emotional. I didn't make a rational point. It was entirely emotional.

But they accepted that. And that's when I learned that managers get to the truth. Managers are good people, people, right? They know how to manipulate people. They get to the truth by testing your resolve, by testing your emotions. If they can drive you to an emotional confrontation, then they know, oh, this is really the truth. Programmers don't do that. Programmers get to the truth by doing the math. We're technical people.

We don't want the emotion. The emotion bothers us. But managers want the emotion. That's how they get to the truth. So I learned that a long time ago, and it's served me well. So a lot of these estimates that we're doing, a lot of times another aspect of Agile or these methodologies is the user stories. And a lot of times when you're doing that,

the estimate, you're doing it for a user story. Yes. What I've found, and this is not even in other people but in myself, is that the user stories themselves suck and so it's really hard to estimate because I'm not good at writing user stories and i've i'm sure there's other people like me where you know you'll have two next to each other one is like a huge scope one's like a tiny thing i don't really understand all

that's implied and you have a lot of thoughts on user stories as well including a kind of a maybe not an uncle bob maybe a grandpa bob idea about using physical index cards uh so we want to talk about user stories next and why you want us to write them on actual paper i mean come on bob you're talking about software taking over the world you want us to use pen and paper yeah yeah well you know i know every everybody's tempted to use a tool the problem i have with tools is not the tools themselves. The tools are fine. The problem is that teams will go to the tool first.

They'll say, okay, what tool do we need to manage our user stories? And they'll buy one. And then the tool will dominate them. The tool's rules will dominate them, and they won't learn how to do it by themselves. So the advice I give to people is, you know, first couple of months, use index cards and get good at it. And then you'll be able to pick the tool and then you can dominate the tool. Because you'll already know how to do it. So you will force the tool into your way of doing it rather than the tool forcing you into its way of doing it.

That's why script software and agile software is so hard to even make because there's so many different variations of agile, right? XP, Scrum, Lean. There is no rule set, so creating software to do agile is extremely hard because there's so many ways to subscribe and unsubscribe

from certain prescriptions of what we call agile. Well, and then it's software and software is a set of procedures. So the people who make the tools have a mindset of how the procedure ought to be followed, and that just carries into the tool and will dominate whatever team adopts the tool. You know this is happening when people use the name of the tool

for the work they're doing. Have you written your JIRs today? That's an obvious clue that the tool for the work they're doing. You know, have you written your Jiras today? That's an obvious clue that the tool is dominating. So now the user stories. Yeah. You said you're bad at writing user stories. How do you write a good user story? Everybody's bad at writing.

Well, so first of all, go ahead. I just get the sense that I'm not the only one. That's why I'm okay. I'm okay admitting it because I've seen some bad ones out there as well. I don't think it's easy to do well. It's not easy to do well but one of the one of the issues here is that you don't need to do it well a user story should not have detail in it a user story is a flash card it's a a mnemonic but shouldn't an estimate require detail i mean i, I can do a better estimate with detail. Well, hang on.

Yes, but. So I'm going to have a conversation with the stakeholders. We're all in a meeting. We're having a conversation with stakeholders. We're talking about a feature. We're talking about the way this feature ought to work. And we'll be discussing, oh, maybe you could do this. Maybe you could do that.

We're not writing any of this down. This is way too early to write this stuff down. But what we do put eventually on a user story is a word or two words or three words or something like that that will remind us of this conversation. This is an old thing from Ron Jeffries. A user story is a reminder of a conversation and it's a reminder to continue a conversation. All right. So the words you put down on the user story aren't very important, except that they should restart the memory of the conversation. Then you put an

estimate on the card, but the estimate has no units. It's just a number. So you look at the card and you go, okay, that one's a three. And you put the number three down. And someone says, well, three what? Three days? Three hours? What? No, just three.

Isn't that arbitrary and meaningless? Entirely. It's entirely meaningless. Okay. But that's good. That's good. We're driving to meaning, Jeremy. We're driving to meaning.

Okay, take me on the road. So now comes the next story. The next story, a bunch of people are talking it over and blah, blah, blah, blah, and you put two or three words down on the card, and then you look at it and say, well, that just feels like it's more complicated than that three. I bet you that's a five. And you put a five down on it, and you're done. And you keep doing it this way, right?

The numbers are relative. Okay, right. They're not absolute they're not naming absolute time they're just relative time not even relative time their relative feel okay it's very loosey-goosey there's no science to this it's very subjective except that it's relative and and it turns out that people are much better at relative estimates than they are at absolute estimates okay if i you know i say well you know it took us six years to get to the moon how long do you think it's going to take to get to mars you could come up with a relative estimate right

probably going to be three decades longer than that so yes yes you know something like this is harder or easier than the other thing so that's the way that we deal with the cards. And then we say, okay, these cards, these numbers on the cards, there's some kind of point value. Now, in a two-week iteration, how many of those points can you get done? And the developers don't know. They come up with some number.

They'll say, well, what do you think we can get 30 done? Well, I don't get 30 done. They get 12 done at the end of the iteration, at the end of the sprint, at the end of the two-week period. They get 12 done. Oh, we've failed horribly. No, you haven't failed. Iterations never fail. You cannot fail an iteration because the purpose of an iteration is to produce data. And even getting nothing done is data. And that's data that goes to managers, and managers can use that to manage the project. So iterations never fail.

There is no target for the iteration. That 12 number was just complete nonsense. It was a way for the stakeholders to pull out 12 points from the deck of cards and say, well, try to get these 12 done. And then later on you come back and say, well, we didn't get that many done. We only got. Would you also say it's these estimates are to bring the team to the same page? Because I've been in estimates where we come out thinking, for example, a story.

We all, you know, we do our, what's it? Scrum poker. What's it called again? I forget what the name is. Yeah, Planning Poker. Planning Poker, that's it. Thank you. And I love the cards, the website. I forget what it is.

I think it's planningpoker.com or something like that. But we used to do this all the time. And everyone would anonymously put in their number of what this story would be. So we'd say, here's the story we're all estimating. And everyone would estimate it. And it would essentially reveal the cards and the numbers. And it was cool because you would see like 3, 3 five seven or some crazy number something there was always some outlier and that person got to share why and again back to relativity uh it was relative to other stories

we already estimated or were planning to estimate so they were all relative and it was this whole process was less about defining the number from my experience and more about bringing the team to the same page. So if one person thought it was a seven, okay, we'll advocate for that. Why is it a seven? Okay. If you think it's a three, why is it a three? And somewhere we find ourselves actually sitting on a five and it's not that it was five days, five hours, five hard points, whatever it was. It was more about getting to the same page and being on the same playing field and having a shared understanding of what we're trying to accomplish. That's an old technique. It's called wideband delphi.

And it's basically the idea that a bunch of people make their estimates and then share about why they differ. And planning poker is a very – a shortcut way of doing that, but a very, very powerful way of doing that. Now, you don't need to use cards. You know, you can get those decks of planning poker cards, but I just like to use fingers. You know, one, two, three. And everybody holds them by their back

and then you count one, two, three and you hook up, throw up the number of fingers and yeah, okay. Oh, why do you have two fingers? Now we have emojis. That's right. Little frowny faces.

Oh, boy. Don't get Bob angry. But the point, though, is to bring everyone to the same page. Well, that's one of the points, yes. Does that resonate with you, Jared? Does it resonate with me? I don't know. Right.

Have you done poker like that, plenty of poker? No. Is that answering the questions you're asking? A lot of this kind of seems like a waste of time to me. But... So, you know, I was of that opinion too, until we did it religiously for years. And again, it's back to producing data, shipping something, getting to some point to understand what we're trying to build and what we're all trying to go to. And it was about team cohesion, if that's a word.

Cohesion. Correct me if I'm wrong. Cohesion. Coherence. Yeah, coherence. It's about bringing the team together. And that was more the point. And I get that it seems loosey-goosey, doesn't really make sense, sort of very ephemeral, but it actually, when practiced like that, it kept us together and

we were all together in what we were building. And, you know, it seems loosey-goosey and it seems like it's almost vaporware. On the other hand, if you have a deck of story cards that total up to 200 points and the team is getting 20 points per iteration done, you know it's going to be about 10 iterations. And managers can look at that and go, oh, I can measure this. Yeah. And you can measure even from sprint to sprint and whatever you can do. Your burndown charts, you can do all these different necessary tools that sort of like

predict this data. But really, it's about being able to predictably predict the unpredictable. Is it? Yeah, which I don't think is possible. So I don't think you can predict the unpredictable. And isn't this fodder for abuse from the management side? Like, well, it should be 20 iterations and you're at 24, so you're not working hard enough.

You said there's no failed iterations, but if I'm trying to estimate off of an iteration and you're way slower, so you're not working hard enough. You said there's no failed iterations, but if I'm trying to estimate off of an iteration and you're way slower than you were before, isn't that an indicator to me? Well, it could be an indicator to you as a manager who doesn't know how to manage something, yes. But here we are giving you, Mr. Manager, these numbers and these tools

and this information every two weeks that you can use to manage this project. And if you turn that into a club to beat us, then we're just going to lie to you. Right. How often do you think that happens? The alternative, however, though, in the waterfall world is what? So let's compare that scenario to the prior iterations.

Well, I'm not advocating for waterfall. I know you're not, but I'm just saying, you know, sure, it seems like fodder, but what are the alternatives? The alternatives is misinformation, fabricated estimates, period, with no process to even somewhat estimate. And then no one gets to make good software. And then 10,000 people die because of a bad failed test or something. I don't know.

That's what's written in his book. It's the end of the world. My example is because of his book, so I'm not being morbid here. But very serious, though. Yeah. Well, I mean, I think we could dispel of the estimates altogether and just move forward without the point system and all of that and just still pick the priority things and still work in two-week iterations.

And people do that. They use a Kanban kind of approach. In other words, it's just fun. Which is why there's so many iterations of Agile, too, because, Bob, you can speak to this, too, is that that's why it's so difficult, I guess, to really understand Agile well because there's so many different variations of it.

It's almost like you can subscribe to some things but unsubscribeubscribe from others. And everyone kind of does a little differently. What I always thought of for us was that let's, let's best understand what agile asks us to deliver in terms of how to build a framework. And let's do the things that make sense for us and our team. So they're adaptable. So it doesn't force us into a way of doing things that we're not comfortable with, but something that we can use as tooling to be a better team, deliver better estimations, understand what we're trying to build better, and let's pick and choose. But that's kind of what the downfall of it is in a way, but also the good thing of it. It's both good and bad because it's hard to follow because so many people do it so differently. So one of the reasons I wrote the book was to reduce that variation down to a single set of disciplines again.

So if you read Clean Agile, you'll see pretty much one way to do Agile. And somewhere in the book I say, okay, now these rules can vary and teams need to adjust them, but you have to be very careful how you adjust them. Because once you give people license to adjust them, they will adjust them out of existence. So you can't allow that if you're going to, and still call it agile. You still can't call it agile. Like if you say, well, we don't believe in doing tests. We're just not going to write tests.

Well, that's not agile anymore. Or our iteration is going to be six months. Well, that's not agile anymore. Right. Or our iteration is going to be six months. Well, that's not agile anymore. So there is some room for variation. And one of the variations is a good one, is the Kanban variation, where you give up on the whole point thing and just start moving stories. And you just count the number of stories. Eh, we're getting somewhere between three and six done.

And that's good enough yeah for a lot of teams again the story with that even with that side the struggle is the stories tend to be not scoped uh the same and so on one side you have you know and i've seen tools where it's like this is a bug this is a chore this is a feature well that's not granular enough because you might have a feature that's going to take you a half an hour and a feature right next to it's going to take you three weeks and it's like well they're both stories so there's just lots of one of the reasons for the yeah i get it i get it yep good point okay well let's let's talk about one other small aspect or maybe a tactical detail which i seems like a lot of people are getting wrong out there and just from

my experience is stand-up meetings wrong in terms of not the way that you think about them in the book. It's like the stand-up meetings, tell us about this. It seems like when I read this part of your book, I thought, oh yeah, this is way more reasonable than what seems to be happening, which is stand-ups. Go ahead. Well, so the stand-up meeting, mostly it came from the scrum work. And the scrum work said, you know, there ought to be this meeting, the daily scrum. And there's pigs and chickens. And I won't go into that whole thing. The extreme programming people said, well, you know, let's just have a meeting every day.

And we'll call it the stand-up meeting because we stand up so that the meeting is short. We don't let anybody sit down. And somebody said, well, we can shorten it by posing three questions. So everybody stands in a circle and they answer three questions. What did you do yesterday? What do you think you're going to do today? And what's in your way? And nobody says anything besides that. No discussions, no complaints, no nothing.

Just those three things. You can get the whole thing done in five minutes. And that's fine. Those meetings are fine. If you can pull those off once a day, that's great, because they only last five or 10 minutes, and who cares? The problem people have, however, is these meetings turn into big grumble fests, and they try to solve problems in them, and they go on for an hour and a half, and it's just awful. The other thing is that people become slaves to these meetings. Now, half the time, you don't need them. You don't need to meet every day. If you've got a team of people working together, they already know what they're all working on. They already

know what the problems are. So maybe you say, well, we'll do it every Wednesday or maybe every other day or something like that. There's no rule that says it has to be every day. No rule in it says you actually have to do it at all. Maybe you do it once in an iteration. If the team is really good, if the team is really gelled, you hardly ever need to do those at all. They just happen kind of by themselves. Would you say then that agile is a maturing mechanism for teams? Because less mature team would need the daily meetings or the daily stand-up, so to speak, and a more mature team that works well together,

that has communication beyond this meeting, understands, right? It's a maturing process or a maturing enabler, I suppose, for teams. You ever taken a martial art? Yeah. Yeah, which one? Karate.

Karate, Karate. Yeah. Okay. So you start out as a white belt. Right. Right. And there's no flexibility. You know, the instructor says, and you do.

That's it. And you repeat it over and over again. If you're going to do a strike, it's going to be a strike exactly the same way. And the angle of your arm, the tension of your muscles is all tested. You have to do it the same way over and over again. And as you rise through the belts, this persists. There's this one way, and the sensei will make sure you're doing it the one way. And then you become a black belt, and the rules change immediately. And the sensei says, how come you're following all these rules? You know all this stuff now. You know how to infer it. You know how to deal with this.

So now start inventing your own style that's composed of all these things but is not these things. And that's what happens in a team. You give a brand new team and you tell them they're going to do Agile. You better have them stick to the rules. They're white belts. They're white belts. They're white belts. But as they mature, they can look at those rules and maturely adjust them and twist them and tweak them

so that they're better for their own purposes. I like that. So yes. So yes. So yes. So yes. It was a yes or no question, Bob. It was a yes or no question. So yes. So yes. It was a yes or no question, Bob. It was a yes or no question.

So yes. One last train of thought. We talk about bringing teams together. You talk about co-location in this book. And you say a team composed of people who work almost entirely from home will never work as well as a team that is co-located. And yet we see the movement in our industry is away from co-location and to towards more remote teams. Does this worry you? Do you think we'll get we'll figure it out? It worries me to some extent. Now, I have worked on remote

teams and they can work just fine. But I've also worked on co-located teams, and there's just nothing like it. You know, if you are with a group of people in the same space, looking at each other in the eye, smelling each other's fear, you see all the body language, you see all the funny little eye gestures and faces that people make, And there is this gelling that occurs in that kind of environment, which cannot occur in a remote environment. Now, that doesn't mean the remote environment can't work. It can. It's just, it's going to be less effective. That's really all. A very wise person once said, if you can't have a co-located space, at least have a co-located mind space. If everybody's sharing the same mindset, the same ideas, the same vision,

the same values, then at least you've got something tying that group of people together. Yeah, because it seems like the other side of non-co-location is that while it is less of a benefit for the team, it seems like in many cases it's a huge benefit for the individuals on that team because it allows them to live a lifestyle that's healthier and better in many, many ways. I cannot deny that. Having been on a remote team. I understand that very well. I think with all things like this, though, there's always trade-offs, right? There's,

there's always going to be good things and bad things for either side. And I think it really comes down to, you know, what you're trying to do. If some of the culture you're trying to do is face-to-face people, like if you're a face-to-face kind of company or organization, then it would make sense to have co-located spaces. If you're less concerned and more, if you're more pro, you know, the benefits of a distributed team, you know, having your own lifestyle, having your own schedule, whatever those are, then you're obviously going to see success in those areas because that's what you thrive in, right? There's always trade-offs, whether it's in person or not in person. Yep, that's certainly true. It's easier to get the people you want if you don't have to locate them together. It's easier to find talent.

There is an immense amount of talent that cannot come to work. And in our industry, tapping that talent is really valuable. What do you have to say then to hybrid teams where you have co-located and distributed in the same team set? The people who are co-located will always have an advantage over the people who are distributed. And the people who are distributed will tend to take the less collaborative tasks, and the co-located people will tend to take the less collaborative tasks and the co-located people will tend to take the more collaborative tasks. There's going to be stress when it comes to salary review time

because the value of the co-located people is probably going to be seen as higher than the value of the distributed folks. It's just a fact of life. Yeah, I've experienced that. Yeah, but if you've got a good co-located team and there's some really good talent out there that's half a continent away and you want that talent, I'd go for it. I wouldn't force that to be a totally co-located team. I think it also depends on, I guess, what you just said there, basically. If you're aware of those trade-offs, if you're aware that there is going to be seemingly more value in the people that are co-located, or some perception of this, then if you're aware of this sort of offset, for lack of better terms, then you can operate around it.

Or as you mentioned, have a shared mindset, like, you know, even if you're co-located, act distributed, you know, have, you know, digital communications. Even if you're co-located, act distributed. Well, you'd have to do that to some extent. You'd want to use chat more and you'd want to have screens more. For example, you know, don't have in-person to some extent. You'd want to use chat more and you'd want to have screens more. For example, don't have in-person meetings without others. In-person meetings are on Zoom, even if you're co-located. That's weird.

I'm not saying they're right or wrong. I'm just saying that that's how you include. You have to include the people that are not in the co-location. So you have to find a way to merge and act. It's just that you're going to have a couple of guys go out to lunch and they're going to solve a problem while they're out to lunch. And that's fine. In prompt meetings, they happen, but deliberate meetings, you should be invited and included.

That's all I'm saying. You're going to have that. It's natural. It's a natural benefit and artifact of being in person. You're going to have happenstance conversations that solve problems, and that's okay. And that's a trade-off. That's, that's something to be aware of, be aware of. If you're that person who's distributed, you should understand that that's going to be in effect. That's gonna be something

that happens with co-located people. Yeah, I agree. Well, the book is called Clean Agile Back to Basics. In his own words, the grumblings of a curmudgeon telling all those newfangled agile kids to get off his lawn. If that intrigued youlings of a curmudgeon, telling all those newfangled agile kids to get off his lawn. If that intrigued you, if this conversation intrigued you, definitely check out Bob's new book. Bob, we're honored to have you here. Thanks so much for sitting down and chatting with us. Thank you for inviting me. It's been a fun talk. Thanks, Bob. All right. Thank you for tuning into this episode of The Change Log. Hey, guess what? We have discussions on every single episode now. So head to changelog.com and discuss this episode. And if you want to help us grow this show, reach more listeners and influence more developers, do us a favor and give us a rating or review in iTunes or Apple podcasts. If you use Overcast, give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it.

Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service, and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo. And our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master or go into your podcast app and search for Changelog Master. You'll find it. Thank you for tuning in this week. We'll see you again soon. Thank you.