Episode 075 – Agile Concepts with Mike Cohn

 
For over twenty years Mike has been building high-performing software development teams and organizations through the use of Agile and Scrum. He’s worked with startups and some of the largest organizations in the world.

 

Transcript

Clayton Hunt: With us today is Mike Cohn. For over 20 years, Mike has been building high performing software development teams and organizations through the use of Agile and Scrum. He’s worked with startups and some of the largest organizations in the world. Welcome, Mike.

Mike Cohn: Thanks Clayton, it’s nice to be here.

Jon Ash: Before we kind of jumped into the meat of things. Would you just kind of give us a little bit of background about yourself kind of, maybe how you got started in the industry and-

Mike Cohn: I think I had a pretty typical progression started out as a programmer. I got into that as a PhD student in economics and dropped out what’s called, ‘all but dissertation’ when I saw how much you make with a PhD, was a lot less than you made with a Master’s. I quit with my masters and went places working and doing economics research. And everywhere I went back then they needed more programming help than they need to one more economist, so just kind of stuck with that and it’s what I love doing anyway. I started out that way as a programmer, worked my way up to managing teams, director in different organizations VPC, all type things. I fairly typical programmer to management progression, I believe.

John Callaway: Very nice. How did you get involved in the whole Agile movement?

Mike Cohn: I knew Board Cunningham, who was one of the guys at the Agile Manifesto meeting. He emailed me the day after the meeting. I just worked on a project here in Boulder, Colorado, He emailed me the next day and said, “Hey, look what I did over the weekend.” And that was the Agile Manifesto. I got involved with that and through that met Mary, Pop and Decken. We were kind of the Mary and I were the two that kind of Co-founded the Agile Alliance just kind of get it going, just to get the paperwork and then brought a whole bunch of other people like, Bob Martin and stuff and right at the beginning but. I was right there right afterwards through the relationship with ward.

John Callaway: With the formation of the Agile Alliance and things like that, you’ve authored a number of books, many of which I’ve got on the shelf behind me, hasn’t been just well received, and the community responding well, right out of the gate. How much of a transition from the old software development practices, many of which were waterfall types of development, how easy is that transition or has that transition been for the companies that you’ve worked with or been involved with?

Mike Cohn: Well, I think a lot of us were doing Agile before the name came around, the name got assigned in 2001. I’ve been doing Scrum since 95 when it really first got started. But back in the late 90s, if you were doing what’s called Agile today, you really felt alone. Everybody was doing what was called the Rational Unified or the Unified Process back then. The company in particular that I worked for, we were buying, not a lot, but maybe a handful of companies a year, and every time we bought one, they were doing the Unified Process, and they’d have this wonderful documentation that’s great to artifacts, and we’d buy them and I’d constantly be like, oh man, maybe we need the time to do these documents. Look at how much better they were, the hell of these nice documents, and after doing that for a couple years, seven or eight companies like that. It was like, okay, there’s a reason we’re buying them, they’re not buying us.

Mike Cohn: I was just very thankful that we’d always been too busy to do those documents. I remember one company we bought, just talking to their VP and they had all the documents were put into slip sheets, like the little like plastic sheets that would keep the paper nice. And is [inaudible 00:04:06] like, “Wow, this looks really nice.” And I said to her, what you doing with the document changes, right? What a pain you gotta take it a lot of these slip cases, is like well, we just don’t change the documents. We don’t have to do that, so we don’t change the documents like okay, this is wrong, right? You don’t wanna change the documents ’cause you sheet protectors. Back in the 90s, you felt very alone doing this. Now that was what was nice when the manifesto came out in the 01. People kind of came out of the woodwork saying, “Me too, me too.” And all of a sudden you have this rally in point. You could rally around the term Agile and say, yeah, that’s what I do.

Mike Cohn: It was nice because you didn’t have that feeling of being alone. Again, in the 90s, as much as success as the company I was with it was having, you still had your doubts, right? It was just like, okay, are we the only ones doing this? I think the adoption was either people loved it or they hated it. Because there was a lot of doubt at the beginning that this could possibly be a good way to build software.

John Callaway: You said that you were doing Scrum in 1995, which is way before the Agile Manifesto? How has Scrum changed since then? Or is it basically the same?

Mike Cohn: It’s changed quite a bit like, some of the early stuff in Scrum is no longer there. I mean, Scrum initially then, Jeff Sutherland and Catch Waiver wrote about it. I mean, there were phases to it. There was the reason it was somewhat called Scrum, is there was a pre game, a game and a post game, which were basically conception and wrap up phases around the process. Initially, there was something called sync steps. There were gaps between sprints in some of the early writings. I didn’t necessarily do all those things, I did a little bit. We read about Scrum before I came across Jeff stuff, and read about it in a book that came out in 1990, and kind of mixed it with stuff that was from a very beam spiral model. And so we kind of, were going through spirals combined with Scrum. Doing it without the gaps, and some of the other things are, but the early definition says, Scrum are very, very different than what we saw at the beginning.

John Callaway: Okay. And then, one of the reasons why companies might be most familiar with you is the Scrum master courses that, yeah, Mountain Goat Software does. You want explain what that is? And maybe go into a little bit more detail?

Mike Cohn: Well, the Scrum master course is, well, it was started by the Scrum Alliance and Ken Schreiber and I taught the first one of those in 2003, he came up with the idea because he was, he’d been in a company back then, would have been away 2002, and he said, they wanna buy Scrum. They wanna own Scrum. And he said, I told him it’s open source, just do it. They don’t need to buy, they don’t need to own it. But 2002 is back when everybody’s afraid to open source, where you didn’t want us to open source in case it turned out, somebody owned the copyright. They owned four lines, your website, now you’re out of business. And so we had to come up with a way of, basically of selling somebody something.

Mike Cohn: He came up with the certified Scrum master course. And we were doing that through the Scrum Alliance, which we co-founded. It’s really just a way to get people to master Scrum. And that’s really the wrong way to think about, you don’t master Scrum in a couple of days, but more to be that, the Scrum Master, which was like a master of ceremonies or somebody who can coordinate the Scrum teams, work them through the process, things like that. That’s what the course is about. There has been a lot of people have gone through that course in the last 15 years.

John Callaway: I was wondering if it has changed much through the last 15 years?

Mike Cohn: Yes, and no, I mean, if you looked at it. I mean, I think you know, I’m not anybody who’s taught it, they’ve learned new ways to teach, I end every class with just a pocket and notes I mean, we’ve every class without three to 10 notes, I just write them during breaks, or when they’re doing exercise, when they attend to exercise, I just shove them in my back pocket. I go upstairs every class with five to 10 notes that I have to change. I mean, they’re not necessarily big changes each time. But you know, tweak this, tweak this. I didn’t explain this well, or people had a lot of questions about this. Let’s add a slide about it or an exercise. I think there’s been a lot of that. But if you look at their core of Scrums. Scrums are pretty darn simple framework, there have been some. I think, pretty successful attempts in the past have, every now and then somebody gets a wild hair and says let’s see if we can describe Scrum at 100 words.

Mike Cohn: It’s not even really hard, right? I mean, 100 words you can describe it if you go to the fundamentals that hasn’t really changed. But back in the very beginnings of Scrum, even in the 2000s. The retrospective was not a part of Scrum. And that’s very fundamental the Scrum these days but wasn’t there at the beginning.

John Callaway: It seems like there’s a lot of misunderstanding, maybe misinformation, maybe just the failure on the communities part or the developers part, or the team’s part to communicate the ideas of Agile and Scrum through the rest of the business or the business to communicate it with their clients. I’ve often heard, Oh, we don’t do Agile, we do Scrum. Or we don’t do Scrum, we do Agile and like, where does that misunderstanding come from? Or how can we more clearly articulate the types of things we’re attempting to do? Is it more about, talking about the value we’re trying to deliver, as opposed to the ceremonies that we must participate in?

Mike Cohn: I think you’re right John, I want the terms to go away right. I mean, I just don’t wanna talk about Agile and Scrum. I don’t mean like today with you guys. But as an industry is like, I don’t wanna talk, I’m done. I’m out of here. What I mean is that, you don’t walk around the office anymore and hear anybody say, “Oh, it’s two o’clock.” I have to get to the object oriented design” Object oriented, it’s a good way to design. I mean, there’s other approaches to but, back when objects took over, versus like, structured programming. It won and we stopped talking about, it was just what we did. I want so much of Agile and Scrum to be just what we do, and we don’t have to. We don’t have to talk about a daily Scrum. I mean, teams of course, they talk once a day. And if they don’t, it’s not a big deal, ’cause they talk the last 83 days in a row, right? Who cares?

Mike Cohn: But until we get that stuff to be fundamental, it’s just like, how we do things, we end up still talking about it. But I’ve for 10 years hoped it goes away. And again, goes away in the sense that it’s just becomes what we do, not gets replaced by what’s go back to big waterfall projects or something, but it just becomes adopted way after stop obsessing over, I’m I doing Scrum or I’m I doing Agile, and what’s the relationship between the two? Which for some reason people still struggle with quite a bit.

John Callaway: Yeah. There’s still a lot of struggle with a number of different companies out there that just, they don’t really know what it is or supposed to be doing in trying to deliver a valuable product. They’ve heard about Agile, they’ve heard about Scrum. There’s a Dilbert comic that I’ll read here that I really enjoy. “We’re going to try something called Agile programming. That means no more planning and no more documentation. Just start writing code and complaining.” The last frame says, “I’m glad it has a name. That was your training.”

Mike Cohn: Yeah, that’s, that’s pretty sad. I think a lot of that comes from people getting really confused between the practices that Agile team exhibits and the principles that underlie those practices. Why are we doing something versus, what are the external stuff. It is just sad ’cause, I remember debating this with people back in probably 2003 at some of the early Agile conferences. It was really, I mean, we talked about it back then as a Karate Kid Conversation. If you wax on all day, do you learn the Agile principles? If you’ve got a team doing short iterations or putting out software every couple weeks, they’re pair program, they’re testing like crazy, they know why they’re doing those things. But is that team Agile?

Mike Cohn: That was a debate 15 years ago, and we’re still arguing a little bit about, do you have to start with their principles or the practices. I don’t know that I really have an opinion which you have to start with, but you better quickly get to understand their principles, or you’re not gonna be making the right decisions. I think as the whole thing is spread, there’s a lot of money to be made, anytime something is popular consultants wanna do it. They’ll come in and they’ll see there’s money to be made teaching people, they’ll come in and they don’t understand the principles themselves.

John Callaway: I would say just go back and reread the Agile Manifesto.

Mike Cohn: I reread it today. I read a book about it today, and I reread it today. So yes. So-

John Callaway: What book out of curiosity?

Mike Cohn: It’s a book by Scott Duncan. I think it’s on info que right now. It’s coming out with like, a new edition of it. I was looking at that. I think it’s got, Understanding Agile Principles.

John Callaway: Yeah, I find that businesses is all too often, and some of us the developers fault because we push for things, we want things to be better. And so we push for Agile, or we push for Scrum. And then the company goes, “Okay, fine, we’ll do that.” But they don’t, either they don’t understand why the developers are asking for it. Or they look at it as just a set of things to do. And so they just do that and it usually ends up with not actually fixing anything and sometimes making things worse.

Mike Cohn: That’s a perfect way to describe it a set of things to do, right, which is, you know, not what we want to have people believe it, needs to be a set of principles that are under Your behavior, not a set of things to do. But set of things to do is easy, right? Such that people fall back to.

John Callaway: Yeah, exactly. Is there, in your experience? Is there anything that, like say a developer could do that would try to push up the chain, the importance of why we’re trying to do something?

Mike Cohn: A lot of good Agile transformation started bottom, then move bottom up from teams to middle management, and then hopefully up there, but there’s always a level that the transformation hits where I wish you get support from above, it’s gonna get squelched. There’s always gonna be some level of middle management that looks at it, is just kind of threatened by it. It’s like, I have to give up my corner office or I don’t get to tell you what to do every day or something that, they lose some authority. Well, I mean, I get it, but a lot of managers look at that and think that’s a bad thing. Sometimes people wanna, we’re going to change the Agile, it’s used as an excuse to throw out everything that I don’t like. And so, though, let’s get rid of all planning or let’s go to all management. We don’t need any management.

Mike Cohn: I saw our podcast today, it was like fire all the managers. And it was literally like saying every manager in the world should be fired. I say, you know, think so. Maybe we’d someday we get to a world where we don’t need people coordinating work, but we’re not there in 2019, is just not, where the world’s that’s just too many people don’t, haven’t come up in the workplace that way. I think one of the things that a development team is gonna have to do is sell the benefits of it to those that are kind of at least two or three levels above their, so whatever they can do to start promoting those things. I just think there’s so many benefits to working in an Agile manner. I mean, we can look at higher quality, we can look at faster development time, we look at products that are more likely to delight customers.

Mike Cohn: We can go all the way to happier teams. I mean, that’s a benefit on its own, your job satisfaction of your employees, you’re likely to get benefits from that. I think it’s a matter of selling some of those benefits to people or couple of levels up.

John Callaway: Have you found when, or have you found issues ’cause I guess we’re kind of speaking out of some of my experiences, there’s been times where you’re kind of pushing those benefits, but the buy in that you get, isn’t good enough to actually make the implementation, show those benefits. And so like, it’s sort of like the hard sell in the long run because people haven’t fully bought in to what those benefits are. How have you dealt with that sort of situation?

Mike Cohn: Well, I mean, sometimes it is, you’re right, it is sometimes a long term sell, right? You’re not gonna walk up to somebody who’s probably been very successful with a more waterfall ish manner and convince them that everything they’ve done in their careers has been wrong. It has to be a bit of a long term sell. And if you’ve got a manager that’s been successful with another approach, you can’t discount that. And it may very well have been the right way to do things over the last 10 or 20 years. But the world is getting faster, the way companies compete these days is by cycling through ideas. Time has to be a competitive advantage, you can’t just be coming up with the idea, that’s not gonna win. The faster that somebody can build something, that’s how they’re gonna compete.

Mike Cohn: You sell it over the long term, when I run into resistance I tend to look at why somebody is resisting, and then attack that because it could be, normally it’s one of three things that awareness, desire or inability. And if you looked at, is the person aware that Agile is better and if not, you wanna educate them about why Agile it’s better. If they’re aware, do they have the desire to actually make a change. Some people are very aware, but just don’t really wanna make a change. It’s like, now is not a good time or let’s do it after this project. Those are 100% valid excuses, I shouldn’t even say excuse, excuse sounds negative, those are valid reasons to not do something. We’re finishing up a major project, I don’t wanna switch process either.

Mike Cohn: But, then you have to find a way to increase the urgency. If a lack of desires that thing increase the urgency, And the last one is, somebody have the ability to actually make the transition, and if they don’t have the ability, that’s where getting some training or bringing in onsite coaching, something like that, is gonna help just to help. Just to hope that will make sense, I’ll give a just kind of a personal example on that has nothing to do with software. But, my mom was great. My mom died a few years back, but she was great. Loved my mom, awesome. But she was the world’s worst cook, just absolutely horrible cook. Her way of cooking vegetables would be boiled vegetable for six hours or something. It was bad, I grew up not liking most vegetables, I still don’t eat enough vegetables.

Mike Cohn: If I go to dinner and there’s like, oh, burger or salad is, I’m going for the burger. I have an awareness that I should eat more vegetables in my diet. I don’t really have a desire yet to do it. But if I went to a doctor, and the doctor said, “Mike, weigh up the bars, you gonna die in six months” That would increase the urgency, now we’d have the desire. Now, I don’t have the ability to actually cook the burger, ’cause all I know how to do is boil vegetables for six hours. That’s all I saw being done. Now I gotta go, see you’re laughing at me John. Now I got to get the ability, I gotta get some recipes or something like that, I don’t actually cook the things. That to me, would be an example of that awareness desirability cycle. If I’m facing resistance, I wanna know why somebody receives, is normally one of those three things.

John Callaway: Alright. We’ve mentioned Agile transformations a number of times. The thing that comes to mind there is, switching from a long drawn out waterfall type process of, a year or more to deliver something into more of a fast iterative development and release cycle. How would you go about having those conversations with companies, clients, businesses that, we’re going to start defining a minimum viable product and delivering smaller things. I started to have this conversation with a colleague of mine, he held up his McDonald’s drink cup from lunch that day and said, “If a client came to me and said, I need this cup made, I couldn’t deliver a straw and in two weeks and say, that’s that’s your first delivery because that doesn’t fulfill any particular need.” But I think that also kind of points to that conversation that, we need to better define those minimum viable products and have those conversations.

Mike Cohn: I don’t know, I question that example. I like that you brought up the McDonald’s in the strong example. But if, examples can be silly when products exist, but right, if somebody said, we need to create an experience where people can enjoy beverages in our restaurant, and on the go. Somebody invented the straw, I don’t know, some caveman or whatever. But somebody invented the straw. I think we’re seeing places deal with us right now. I was out to dinner with my family last night, and they brought drinks to our table, your drinks, whatever, and they didn’t bring any straws, and my wife had a margarita that she wanted us try.

Mike Cohn: They brought her two little kind of cocktail straws, little tiny ones, not the like, big normal straws. It’s like this whole thing with straws are killing sea turtles. It’s like well, why aren’t the little cocktail straws killing sea turtles to? Why will you, you don’t bring my daughter a straw for her soda but you bring to in the margarita.

Mike Cohn: My other daughter mentioned that, it was like Starbucks or something, to figure out ways to embed a straw into the cup or something, so you can drink it out to like the lid. I would think that would be part of an incremental innovation. If somebody said, “figure out how we’re going to do this.” I do think coming back in two weeks ago, and hey, we invented the thing that replaces the straw. Now, that doesn’t work with the traditional cup, we’ve invented a new type of cup and then two weeks later you come back with a beverage. One of the examples I use in some of my video training is of, making a pizza. We want to make a pizza and in the first iteration we might come up with the best sauce for the pizza.

Mike Cohn: The next round we might try sausage from eight different vendors and pick the sausage that best to goes with the sauce, and isn’t hundred dollars a pound or something. That to me would be iterative and I think a lot of other businesses know that, they do think about it that way. Sometimes in software we caught up and we have designed the whole thing. To me that comes from companies just asking the fundamentally wrong question. Companies always ask, “What should we build?” And that, it’s the wrong question. The question is, what should we build next? What you’d build next, and then go.

John Callaway: That’s why I liked that story in particular, because my colleague held up the cup and immediately said, “We can’t deliver a straw” and your first instinct was, What they need is a beverage delivery function, a way to deliver the beverage. I think too often, developers and software creators, take the initial request from the business, from the client and say, “Oh, you need this cup. I will set out to build that cup for you.” Instead of asking those questions. What is the need you’re trying to fill? What is the problem you’re trying to solve?

Mike Cohn: Absolutely. In my view with that is that, we have a customer and the customer has a problem. The customer is not uniquely qualified to know the solution to that problem, right? Just because you have the problem doesn’t mean you know the answer. I mean, I have a problem. I like straws. I drink a lot of ice tee, I like straws. I care for sea turtles, but I like straws. What am I gonna do? Some of the restaurants I go to these days, I just don’t order a drink because I know I’m not gonna enjoy it, without a straw.

Mike Cohn: Restaurants have a problem, they’re losing I know, $3, $4 every time I don’t buy a drink. That would impact a restaurant. That’s a problem we’re solving for them. It is a matter of framing the problem. I’ve been reading a lot of marketing stuff just over the last couple years ago, small business I have to, have stuff to sell but, I have to be, I have to know what I’m doing. I gotta market it to.

Mike Cohn: One of the things that comes up a lot of the marketing books is a famous example of nobody wants to buy a drill. They wanna buy a hole in the wall, they don’t want to buy a drill. You think about that applied to software, is exact same thing. It’s a matter of framing the problem, what is it that the customer wants? What is it that somebody wants our software to do? They want a hole in the wall, or they want a beverage delivery mechanism.

John Callaway: Yeah, I’ve worked for several companies where they come up with a solution. And then I’ve asked them, what’s our goal? How will we know that we’ve been successful if we deliver this and they just, they stare at me like a deer in the headlights. They have no idea how to know if the thing that they’re asking for is successful. They had no purpose in designing it, just came up with it and wanted us to make it.

Mike Cohn: The last book I wrote, I wrote the reviews I wanted to receive on the book before I wrote a chapter of the book. Here’s what I want people to be able say, this book helped me learn how to do this. This book covered this topic and so I had, don’t know five or six different Amazon reviews and each paragraph long or something, but they were some of the things I wanted people to say. I’m working on a new course right now and working with somebody on my team.

Mike Cohn: We’re kind of writing some of the marketing material rather than starting with the content. Because I wanna be able to know what, I wanna know what the promises we’re gonna make to somebody in the marketing for that product. And then I can create the course of fulfills that promise.

John Callaway: I really like that idea. Did you go like whole hog and come up with personas and everything?

Mike Cohn: I did. I had, from my book I had three posters on my wall. They were three different personas. I don’t remember them in detail. What I remember had read a book called, Agile Project Management by Jim Highsmith, which is a great book, but it’s really just about the project management side of things. I need to end the persona that had read that book. And I think one other book, now needed to go deeper. They really want to know how to take an Agile team and make them a good Agile team and overcome like four or five challenges. That was one of the personas and then I wrote a review that I wanted that person to say on Amazon, including negative things.

Mike Cohn: I included the negative things in there because those to me where things I decided, I would not go into, in the book. As an example, I was gonna write, I didn’t know how long it would be. But it ended up being about 40 pages on scaling, which is pretty good for a book on Agile in general.

Mike Cohn: I did want the person to say, great introduction to scaling, but I need to get a little bit more detail and scaling. That would be somebody writing a 200 page book, not a 40 page chapter. I was honest with this stuff that I wasn’t gonna write 200 pitches on scaling in a book that was gonna cover 20 Agile topics.

John Callaway: What about when these terms become weapons for the team, maybe the business has bought in that Okay, we’re gonna do this adult thing and this sort of thing. But then it becomes, well, for this two week sprint you committed to delivering 40 points regardless of the fact that we actually didn’t properly break those stories down and get adequate requirements. We’re gonna need you to work the weekend on those, on delivering those points, there’s a danger where the points become more valuable than the proposed value that we’re attempting to deliver.

Mike Cohn: Yeah, I think that’s a huge problem. I think something’s gone astray. In particular in the Scrum Well, maybe I Agile in general. But I see more of it with Scrum, ’cause I see more Scrum teams. But were too many teams, and sometimes it’s a team’s fault, turns Scrum and do a check the boxes process. Did we finished the nine user stories? No, we did eight of them, but they’re amazing or we came up with a way that’s gonna rock the world.

Mike Cohn: The early days of Scrum that was not, that attitude was not there. It was very much meant to be a way to find breakthrough innovations. You put a team under, I don’t wanna make sound the wrong way but you put a look team under a little bit of pressure. There’s a little bit of pressure get this thing done.

Mike Cohn: They find innovative solutions, and you don’t give a team infinite time, that will never happen. And so is this, the subtle like, you gotta get it done, you gotta … Back then it was always a month, you got four weeks. It went to break through thinking and nobody, ever back in the late 90s, even the early 2000s produced a report that said, “You made seven out of eight backlog items or seven out of eight user stories.” That is just so fundamental now, it’s like I totally see the point of people arguing against velocity these days because there’s so many bad uses of it.

Mike Cohn: I end up talking to a lot of people it’s like, you can ruin velocity, you can use is the absolute best measure you have ever had of, whether you’re on track. Or you can use as one more time, one more thing to hit a team over the head with, I’ll offer to like, if you want me to give you 20 other ways to beat up a team I’ll do it, but don’t ruin velocity.

Mike Cohn: I mean, do something like, print out a memo and leave it to print about how you’re looking to outsource the entire project. What your developers find that right? If you wanna get creative, you can find out better ways to beat up a team, then velocity. Velocity, misinterpreting commitment to me it guarantee, if they just kind of ruin, they ruin it for good teams.

John Callaway: That’s one of the benefits of having a good retrospective, and truly learning from the previous sprint and moving forward and improving is that, we missed that story. We didn’t deliver that story. We missed these points, whatever. Why can we adjust? Do you think we need to, maybe commit to less in the future? Was there something that we missed and didn’t understand the scope or something.? I mean, there’s all sorts of valuable information that can be gained from that if it’s handled properly. If it’s handled with, you missed the commitment, you’re a bad boy. I think everyone loses at that point.

Mike Cohn: One guy I took my class one time, this is years ago. But he took my class and he said, “Hey, Mike, you talked about commitment.” And he said, “My boss took somebody else’s class” And back I talked about commitment to, and he said, “What do you think of my bosses email that he sent the entire team.” And the boss’s email basically said, “If you don’t make your commitment, I will take corrective action up to impossibly including termination” Is incredible, this boss ruined it. Now, these teams have to feel like they have to commit to so much, they don’t get yelled at for not committing to enough but not so much there any risk of missing. It’s no longer, what’s a reasonable expectation. How do we find that safe spot between getting yelled at today or getting yelled at in two weeks?

John Callaway: I think that’s a five point story but I’m gonna say 10, that way I meet my quota and the boss doesn’t get too upset.

Mike Cohn: I use the example a lot of a football quarterback, and you don’t want your football quarterback to throw 100% complete passes. Think about what would happen if you went to some quarterback and said, I’m going to fire you if you don’t throw every past complete. The guys just never gonna throw, or you gonna throw two yard passes and hope, but it’s not what you want. That is a quarterback who throws an incomplete passes should be considered extremely successful. I mean, when they are, I mean nobody expected quarterback 100%. We shouldn’t be expecting the same with teams, it’s just not realistic. Just makes teams too conservative.

John Callaway: In wrapping sort of thing things up a little bit would you kind of speak to the listeners that we have that are sort of new or younger or just less mature and maybe are trying to advance themselves, trying to get into development. Trying to get into Agile understanding what this is, maybe they’re primarily still dealing with the waterfall methodology, is they’re in software development. Would you kind of give some like, specific tips and pointers to them on, sort of how they can kind of get themselves kick started and kind of advanced?

Mike Cohn: Yeah, one thing, if your organization’s not ready to go to Agile, or you’ve got a manager that’s resistant to it, I think that’s fine. We don’t have to everybody just, itching to do this. There is plenty of room to debate whether Agile is good or not. I mean, I’m totally open to that debate. The debate that I don’t think exists in the world is whether iterative development is good? There is nobody out there that says, software should be built in a big bang, I gonna rephrase that.

Mike Cohn: Nobody knows what they’re talking about is saying that. The true waterfall model of do all the analysis before any design, all the design before any coding, and all the coding before any testing. Nobody advocates that, go on Amazon and try to find the best book on waterfall, it doesn’t exist. Nobody’s written one.

Mike Cohn: There is plenty of room to debate whether we should be using three month iterations or two week iterations? I would not consider a three month iteration very Agile. If your organization is not ready to go Agile, that’s fine. But start taking some of the Agile ideas and use them in longer iterations. Nobody’s gonna debate that, or if they do, you can argue against them like, I get it some business people will, because they just don’t understand that, we can’t build something perfect the first try. But go to three months iterations, that’s a, that’s a start. And start bringing in some of the things that you like about Agile, the focus on testing perhaps, or the communication. Add in some retrospectives, it’s like, okay, you’re only doing a retrospective every three months.

Mike Cohn: Well, do that. And then, get people to see that’s a good thing and say, Hey, let’s not do them just at the end of every iteration. The last day of every month, let’s do still February 28th, will do one. Start bringing some of those things in, and if your organization is totally resistant, skip the vocabulary. I mean, the vocabulary is, who’s to have somebody in your office, it’s, you have to call Master. I mean, Scrum Master, it is like, this is a bad term. I mean it again, I love Scrum. But, I mean, a bad term. Sprint, who wants to finish and be out of breath? Avoid some of the terms, avoid anything that’s overloaded like that, and just start bringing in the idea.

Mike Cohn: Not all fits with what I was describing about how this stuff all this has to eventually go away. It just has to be what we do. We don’t talk about it is, this holy grail, you have to be Agile, it’s like no, you gotta do great development.

John Callaway: So be iterative with the way that you bring in-

Mike Cohn: [inaudible 00:35:30] be iterative. I mean that is part of what I’ll tell people like, I tried to get people to adopt Agile, and yes be iterative and how you adopt it. People struggle with like, how iteration should be? They’ll have three week debates about how long their iterations are. Just start, pick one see how it goes. Literally randomly, just pick a length randomly and see how it goes.

John Callaway: Excellent. What other resources made your point people to, just kind of looking into Agile? Obviously, you have resources that you produce and courses that your company-

Mike Cohn: We have quite a bit on our website, we have our website as mountain goat software.com. The absolute best book on Scrum for somebody getting started with this is called, Essential Scrum. It’s by Ken Reuben. That’s a wonderful book that titles a bit of a misnomer. It goes way into more than essentials, but it does cover everything that you’d wanna need to get started in that. I would steer people towards that as kind of the best starting point. We have a simple website called Scrum foundations. Com.

Mike Cohn: It’s like an hour of videos, and if somebody like 100% knew that would be a good starting point, we give that to our in person attendees to watch literally kind of comes in with the same foundation but. I’ll start with that is just free hour videos or hour or so. Then go on to Ken’s book if you find Agile interesting at all.

John Callaway: I absolutely love that book by the way. There wasn’t a single word in that book that I wasn’t like, yes. Yes, absolutely yes.

Mike Cohn: Got it. Ken would be happy, he’s a great guy but when he starts a book what he does is, he spends about, I’m gonna exaggerate but it seems like, he spends like six months creating a glossary of what every word is going to mean. Then he uses every word precisely that way and I’m just like, I’m just gonna spew out words. Ken is great but, yeah he’s very picky on the word. He would love to know that every single word was perfectly, it’s a wonderful book essentials from.

John Callaway: How about people who, if they just wanna follow you or what you’re doing? Do you have a Twitter handle? You can plug or where can they follow you, find you?

Mike Cohn: I think, I’m Mike W. cone on Twitter. Mike W and then CEO a Chen and I’m on Facebook and LinkedIn the same, I don’t remember all of my handles on those things, I don’t pay as enough attention to what I got called after the first day when I got whatever name it was assigned me. But I mean, the biggest thing is you find me on mountain goat software.com.

Mike Cohn: I put out a weekly tip. I try to keep a couple hundred words, just really short, one little tip helping people succeed with Agile, that’s kind of the easiest way to stay in touch with me a sign up for that little newsletter I [inaudible 00:38:23] early. Bombard people, it’s just like one short email a week.

John Callaway: Alright, thanks, Mike. Really appreciate you coming on the show.

Mike Cohn: Well, thank you guys have a good day.

 

Links

https://www.mountaingoatsoftware.com
https://twitter.com/mikewcohn
https://www.linkedin.com/in/mikewcohn
https://agilemanifesto.org

“Tempting Time” by Animals As Leaders used with permissions – All Rights Reserved

 

 

Episode source