Agile Weekly Podcast

Clayton Lengel‐Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton.

Drew LeSueur: I’m Drew.

Cognitive Bias and Estimation

Clayton: With us today, we’ve got Jim Benson. I might know him better on Twitter as ourfounder. We wanted to talk today about the cognitive bias and estimation. Jim, I see that you’ve written an eBook or Kindle book about plans and cognitive biases, under just biases in general and plans. Could you give us an overview of what it was that prompted you to write that book?

Jim Benson: Sure. My career actually started in Psychology and as I worked my way through being an urban planner where I built really, really large things, like subway systems and freeways. Later, when I came to software development, it was incredibly obvious to me that people just couldn’t estimate their way out of a paper bag.

Most of the breakdowns in projects regardless of what they were or who they were for, generally centered around problems with the estimates.

I started to look into reasons why that was and I started finding clues in psychology. The psychology of how we approach problems, how we gather information, how we make decisions, all of those combine to really muck‐up our estimates.

Estimates Are Wasteful

Clayton: OK. You know one thing, I don’t know if you are a part of this camp, but a popular mindset nowadays seems to be that estimates are wasteful. No one ever gets them right, so why bother doing them? Where do you stand on that?

Jim: Eisenhower said that planning was important and that estimates for it and plans were useless. I believe that the same thing is true, that estimation is indispensable and that estimates are useless.

Going through the exercise of estimating is actually rather important. When you change it to an active word instead of a physical object, going from an estimate to estimating, then estimating becomes something that you do constantly throughout the project and that’s much more helpful.

Clayton: That is an interesting way to think about it. Obviously there’s a lot of teams that, probably experienced the idea, they do some estimates and that gets held against them or something like that. But I agree that there is something important about that mental exercise.

Now, in terms of some of the biases or some of the more psychology things you hinted at, what are some examples there that you could give us about some things that some agile teams might face?

Availbility Heuristic

Jim: I’ll just start to cherry‐pick and I’ll come to the big one, maybe third.

The first one is something called the “availability heuristic.” When you look back on things that have happened and we pick out exemplars of either our fears or our hopes, and we then start to make decisions based on those exemplars. The worst part of this is an exemplar can be status quo.

What we found is that the error in estimates follow almost a perfect Pareto curve, or almost a perfect power curve. We start to feel that we’re very good at estimates because we actually do get them right, about right, or excusably right, about 80 percent of the time. The other 20 percent of the time, we perceive that we are dead wrong, so we say “If I could just get that last 20 percent right, everything would be fine.”

But it’s actually a natural power curve, it’s a natural law, especially in software development that we’re always going to fall prey to because there’s too much variation in our work for us to estimate accurately, a 100 percent of the time.

Clayton: Take scrum as a methodology that puts a lot of emphasis on predictability and timeboxes. Usually in most of the training literature there’s a lot of emphasis on the estimates, specifically Planning Poker.

On a scrum team, do you think they just need to find some way to overcome some of those biases and problems, and just deal with it? Or should they find creative ways to avoid those issues, or creative ways to do estimates differently?

Planning Poker To Eliminate Group Think

Jim: I’ll start this by saying it is dangerous to ask me about Planning Poker, and then I will try my best to state this as distinctly as I possibly can. Planning Poker itself was devised to get around groupthink and other cognitive biases to play teams.

The theory behind it was, if you got people together and they in silence and at least cognitively separated from each other came out with like an opening bid for what the number of story points were for a given story, or a given task, or given feature, or whatever you are estimati...

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly podcast. I’m Drew LeSueur and with me today we have Jeff Patton. Jeff tell us a little bit about yourself and what you do.

Where Did All Start

Jeff Patton: Where do I start? I’ve been in Agile development since starting with Extreme Programming in 2000 and later in 2001 finding that was Agile. For the previous ten years I had been in software development in a huge variety of roles, but eventually ended up in product management. After 2000, I stayed in product management, then I worked as a product manager, and then as a consultant with a company called Thoughtworks. These days I’m independent. My focus is on software product companies, people that make software for commercial sale, although I still work with some companies that do IT.

I like the challenge of working with companies where, if they make a product and it sucks, they’re in trouble. For better or worse, in an IT world, sometimes you can get away with making a product that people don’t like very much, because they have to use it. That’s a mouthful!

Four Steps of Design Thinking

Drew: No, it’s great! I watched a video of yours talking about design thinking, kind of labeled “Four Steps of Design Thinking.” Could you explain a little bit about that, just a rough overview, and how you incorporate that into your work? Working with companies that make software products.

Jeff: Yes. Good question.

The design thinking thing has become fashionable. You can go to amazon.com, type in design thinking and find a great number of books about it. It’s become popular at an executive level in a lot of larger organizations.

The tenet of design thinking is, you start by understanding the problem you’re solving. You’ve got to do enough research or gather enough information about the problem before you stop and say, “This is a good idea,” or “This is a solution we should build.” In an Agile context, for instance, we build product back‐logs, but product back‐logs are filled with solutions and not problems. You know, in theory, if we were writing user stories. We’ll talk about who they’re for and why they want to use the stories.

But, design thinking will ask you to go farther back. Stories contain solutions, most of the time. The next step in the design thinking process is an ideation step.

When I’m teaching people design thinking, I’ll ask them, “Tell me about a typical meeting when someone comes in with a problem.” They’ll say, “Well, then somebody will propose a solution.”

Then, I’ll ask, “Then, what happens?” People will usually say, “Well, then we start discussing that solution.” People usually joke and say, “Then we start tearing it down and then somebody will suggest something else or we’ll adjust the solution.”

That’s exactly not ideation. If we were doing ideation, our goal is to come up with tons of solution, a great many solutions, and not stop and evaluate any of them before we’ve come up with a dozen or so.

Does that make sense?

Ideation vs Iteration

Drew: Yeah, it does. When I watched your video, I wrote down the steps and you, to me, hit the first two at least.

If you have a problem, you “ideate” ‐‐ is the verb you used, which I thought that was kind of a cool verb ‐‐ come up with a bunch of ideas and then, you had a step in there that’s “iterate”.

Jeff: Iterate is a troublesome word.

Drew: Right.

Jeff: In Agile development, I started with extreme programming. These days, I teach Scrum because that’s the role that most person using Scrum as a starting part and Scrum uses the term “sprint”, but in extreme programming, they use the term “iteration”.

Drew: I really like that word “iteration”, too, as far as software development goes.

Jeff: But, iteration can mean repeat the same process over and over. But, when you’re talking about a product, a thing, iteration means, well, it means the same thing as rework.

It means I build something and I look at it and say, “Well, that’s not very good.” I change it or I improve it.

If you’re doing the design thinking thing. You ideate to come up with a lot of possible ideas and then, you have to start combining and refining.

You start to take your best ideas and put them together. The only way you can tell if they’re actually good ideas is to prototype them or put them in a little bit higher fidelity and get them in fron...

**Roy: vandeWater:** Hello and welcome to another ScrumCast. I’m Roy: vandeWater.

Alan Dayley: I’m Alan Dayley.

Derek Neighbors: I’m Derek Neighbors.

Perry Reinert: And I’m Perry Reinert.

Jade Meskill: And I’m Jade Meskill.

Roy:: I would like to welcome you to a special edition of the ScrumCast. About 12 months ago, we all got together and came up with several predictions on what we felt were going to happen throughout the year, with regards to Scrum and Agile. We’d like to take a moment, real quick, to reflect on our predictions of last year and see how well that went, and then also make some new predictions for the upcoming year.

Alan, you made several predictions last year? What you felt really happened and didn’t happen?

Losing Labels, Community Conflict

Alan: I thought the most promising thing was to start losing the labels around the different frameworks, and I saw a movement happening in that regard. I think that was a pretty safe prediction. It’s happening.

My secondary one, on community, I also predicted there was going to be some conflict around that movement. In my opinion, at least on the email lists and other places where conflict seems to grow, those sorts of things aren’t happening. We’ve got some people who are adamant about losing the labels and mixing and matching different parts of different frameworks.

They’re very upset when somebody says, “No, we need to do Scrum or we need to do Kanban or whatever it is.” I think those are pretty safe predictions. They did happen, and they continue to happen.

Winners or losers, I failed implementations. I have a client right now in fact, that is doing really well, or was doing fairly well on their own, but told me, “No, we don’t need you,” and then several months later said, “Yeah, would you come help us”? I think that’s happening a lot.

Roy:: Perry?

Legalism and Frameworks

Perry: Yeah, I definitely, I was jumped onboard with Alan on the verbiage. I think we had, my notes show legalism and frameworks. That’s the sort of getting spun‐up on the details versus the real concepts around Agile.

We’re definitely making progress. As it grows up, as we get more mature, as more people actually really understand Agile instead of just, “Read the book and try to follow the recipe,” then they’re in a better position to adapt the real principles to what they need to do.

I think we’re still making progress there. I also had around community predicted changes in certification. I think we’ve definitely had changes around certifications. We’ve seen the spring up of IC Agile, Scrum Alliance has made some changes, just for example, the CSP has changed from the 10‐page form to that’s now an exam.

I think we’re going to continue to see changes in there also. Winners and losers, I had developers who would continue to win in the Agile world. I think there’s no progress in there, but I’m really feeling like that’s still the next big thing to trying not to get into future predictions now. I think we made progress, there’s more progress there.

New things, I said exploring lean principles in usability. The lean principles definitely, all of those Agile practices and principles I think are coming together as we mature and usability is still a big thing. I would have liked to have seen even more progress there, but I think we’re making steady progress in those areas.

Roy:: Derek, how did your predictions and the beyond?

Revolt Against Process, Coaches

Derek: I think my first prediction was getting back to the roots of the manifesto not being quite so process focused, and I failed that one miserably. I think I’m about three years ahead of the curve on it. I suspect, in about two years, we’ll actually get there.

I think step one Alan and Perry got right on, and that’s now everybody’s just bitching and fighting about which process is the right one. I think ultimately they’ll come to find that it’s really about the routes of the manifesto, and the processes that we use don’t really mean shit when it comes down to it. They’re just tools to implement the bigger things. I think I failed on that one because it was a little too early.

On powershifting away from trainers back to coaches, I think that’s starting to happen a little bit. I didn’t accelerate quite as much as I thought, but Scrum coach retreat certainly saw a number of CSTs that are now doing a lot more coaching engagements instead of training.

They’re not fe...

Derek Neighbors: Welcome to another Scrumcast. I’m Derek Neighbors.

Clayton Lengel‐Zigich: I’m Clayton Lengel‐Zigich.

Done Is Done

Derek: Today we want to talk about something that a lot of teams struggle with, and that’s the concept of “Done is done”. I guess to start off with Clayton, what do we mean when we say “Done is done.”?

Clayton: That’s a hard one to sum up in one phrase. There’re a lot of things that go into it, but I would say that it’s basically, if you want to go with more of a book answer, you want to delivery potentially shippable software. That’s an easy definition for that. Obviously you need to expand on it.

Where Do You Draw The Line In The Sand

Derek: There’re a lot of exceptions depending on the size of your team, and what team functionality is. You might draw a different line in the sand of what is done. Meaning, maybe I’ve got a Q & A team that is entirely separate from my team so done is done for. My team would be making sure that we’ve done A, B and C, and we’ve handed it off to the Q & A team, and when we’ve handed it off to the Q & A team it’s thereby done.

For today’s conversation we want to talk about “Done is done,”, is that a single team is responsible for the entire chain all the way to deployment. What does it mean to be done in order to deploy? What we see a lot is a developer will say “Oh, this is done.”

“Mrs. Product Owner, it’s out there. It’s totally ready to go. Go check it out.”, and a product owner comes in and they go to the website and say “I don’t see how to...Where do I get to this”? “Oh. Well, you have to enter like this super magic URL to get there.” “OK.” They go in and they pull out some data, and they press a button, and boom the software blows up, and then there’s a defect.

Obviously not done, but thought it was done. Today maybe let’s go over what are some things that hold developers back from being able to give product owners features that are actually done the first time.

Lack Of Automated Testing

Clayton: Take your maybe less savvy, what you want to call it, developer not doing any automated testing. Those people in my experience...I got into the industry. I’m going to do some feature, and I’m going to spend a lot of time manually going through their entire process. I know how to make a testing, but one way that people go wrong with that is they choose the golden paths. It’s a phrase I’ve heard before.

I know that I need to fill in on these fields, and I know that if I put a two highway number in this field, it doesn’t going to work, so I normally put ten in that field. I know that I need to press the submit button, and I know that when I get to the next page, there’s a bunch of [indecipherable 03:18] , but there’s this little link down here. If I click on that, “OK, sweep, it’s done.”

They’re just lazy in that regard. They don’t think about it in terms of how someone actually is going to use it. I would say for the more savvy developer, that’s actually writing automated test.

It’s really easy to do the same thing when you’re testing. You have different test cases, but you still do the golden path for a lot of those. You don’t think to put in much crazy test cases, maybe you shouldn’t. You don’t necessarily wanting to catch every single edge case, but it’s still easy to do that.

Also, you get the false sense of security of while this feature is tested when you actually maybe deployed of that. The product owner is looking at it. They don’t do the same except that you did in your test obviously. You get the ball of the software.

Works On My Machine

Derek: I definitely think that that’s one of the biggest things that...at least in web development. I don’t even say we see this a lot in mobile development. It’s not actually deploying to target platforms and do the testing.

It’s the classic, “Hey! This works in my environment. Everything is great,” the works on my machine syndrome, so going along, blistering along, everything is great, and I handed off, and the product owner complaints that it just doesn’t function at all. You scratch your head and say, “How the hell? I’ve worked on this for four hours, and I’ve not seen anything remotely close to what you’re talking about.” You’re completely crazy.

You go to the diversion of the operating system on the mobile device or their particular mobile device where you go to their web browser and you go, “Oh, oh, oh. I forget about that dependency or whatever.” That is probably one of the lowest hanging pieces of fruit that developers can do to get a better done is done and that is, make sure that you’re deploying to a solid target platform.

If it’s multiple platforms, we see this as mobile, if you have to support multiple versions of ...

Jade Meskill: Hello. Welcome to another episode of the Agile Weekly podcast. I’m Jade Meskill.

Roy van de Water: I’m Roy van de Water.

Clayton Lengel‐Zigich: And I’m Clayton Lengel‐Zigich.

Prescriptive Agile Coaching Trying a New Approach

Jade: Clayton, you’re trying a new approach to coaching a team you are working with. We wanted to talk about that a little bit. Tell us a little bit about what you’re doing.

Clayton: A little bit of background. The team is this collection, I wouldn’t say misfits, if you’ve seen the movie “Bad News Bears” it’s kind of like that.

Jade: [laughs]

Roy: Wow. I have not.

Jade: [laughs] Imagine that you have.

Roy: Is it like “Breakfast Club”?

[laughter]

Clayton: In that there are people in the movie, yes. It’s the same thing.

Jade: [laughs]

Roy: Is it like any of the three “Star Wars” movies?

Jade: [laughs]

Clayton: OK. There’s this collection of misfits and the approach I have been taking was I wanted to be prescriptive about some things. I go back and forth between organic learning or being really prescriptive. I thought I want to be kind of prescriptive because I want to accelerate things, but I don’t want to be prescriptive about stuff like process. I don’t want to say like, “We have to do stand-ups” or “We have to do Scrum” or “We have to have a product owner.”

But I thought, “What if I’m prescriptive about the principles and the values?” As far as being prescriptive goes, that has actually gone pretty well. Things like being open about what we’re working on, visualizing the work, collaboration, and all those kind of things. Then the other approach I’ve been taking that’s actually probably had the most benefit there’s two things.

One is I’m pretending like they’re already an awesome team. When topics come up, rather than saying like, “I’ll ask a question about something like, “How would a team handle this?” Rather than saying like, “A high‐performing team would do X, Y, Z,” I’d say, “Oh, I think maybe if you guys did this, that would work.” They look around. The next part that comes in is “You can do anything you want.”

I always laugh when Jade does the, “You can do anything you want, but there are consequences.” I’ve been trying to get them to believe in this kind of fantasy land where they live in this reality where they’re already awesome, and they can do anything they want. Some of the things that I’ve done on accident that have helped a lot, we set up pairing stations. One of the things that I was being prescriptive about was collaboration.

Rather than trying to work on a bunch of these different projects all at once with a bunch of different people siloing, I said, “Hey, let’s set up a pairing station.” I actually did that for them and made it really easy to use them. It worked out in my favor that no one’s machine was set up to work on any of the projects, and the only machine that was was the pairing station. I just grab [indecipherable 2:27]

Jade: This was a team that hadn’t paired before? They were not

Clayton: Yeah, they’d had a little bit of exposure but not really.

Part of the pairing station problem that we had was the monitors were really bad. I went out one day, and I just bought new monitors. I came back and they were all like, “Wow. How did you get new monitors? You didn’t go through IT.” I’m like, “Yeah, I just went and bought them”. They are like “you can do that”? I wasn’t trying to make a case on this but I was like “Yes, I can, I’m an adult. I went to the store and I purchased them and there was this transaction and now we have new monitors”.

It was totally an accident but that was I think the first time they saw “Oh, wow, you really can do anything, there was this thing that I thought was impossible but then you did it”. All the conversations we have been having around actual code things or technical practices or what ever, I think the barrier of that’s impossible, I have never seen that before is widdled away at this point.

They are willing to pretend now, that they can do any of these things. Anything is possible.

If You Tolerate It, You Insist On It

Jade: What are the results that you have seen so far from this experiment?

Clayton: They are making good choices. One of the things that I have been trying to emphasize is that concept of if you see a problem it’s your problem now. If you tolerate it, yo...