Episode 258: Agile Estimation is Faster, Easier and More Accurate (Free)

Play Now:

This episode is sponsored by The Agile PrepCast for The PMI-ACP Exam:

This interview with Mark Layton was recorded at the Southland Technology Conference 2013 in Long Beach.

Mark Layton (https://platinumedge.com/) has been an entrepreneur, consultant, and trainer in project management for the last 20 years. (And as it so happens, Cornelius Fichtner was a student in one of his Scrum Master classes.)

Mark and Cornelius got together in Long Beach to talk about Agile estimation. Mark says that traditional requirement estimation techniques are a frustrating combination of wild guesses and false precision. While estimates are given down to the exact hour of effort, the accuracy of those predictions vary wildly and provide no opportunity to self-correct based on actual performance. This inaccuracy problem is then intentionally masked by an even more inefficient tool - contingency reserve.

In our interview, Mark describes how professionals using agile project management can adopt agile estimation techniques to work in a faster, easier, more informed, more honest, and ultimately, more accurate way than guessing to the hour how long tasks months in the future will take to complete.

Poor estimating is a huge source of risk for projects, and better estimating is one of several risk management strategies for agile projects that we can all learn from.

Episode Transcript

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.

Podcast Introduction

Cornelius Fichtner: I am still at the Southland Technology Conference 2013 here in Long Beach and this time I welcome Mark Layton from Platinum Edge.

Podcast Interview

Cornelius Fichtner: Hello Mark!

Mark Layton: Hello! Thank you so much.

Cornelius Fichtner: Your presentation earlier today is titled :Agile Estimation: Faster, Easier and More Accurate" How did it go?

Mark Layton: I thought it went well. We had a lot of really good audience participation. We had just under a hundred people that were stuffed into the room. All the chairs were taken. People against the wall. So there seem to be good participation and interest so we were fortunate.

Cornelius Fichtner: Yeah and out of the 300 people attendance, you got a third while there were 3 more people speaking after you. That means, it's a topic that people want to learn about.

Mark Layton: It seem to be, yeah.

Cornelius Fichtner: Yeah! So what is the fundamental difference between estimating under Waterfall and estimating under Agile?

Mark Layton: Well fundamental is right. I mean it is a fundamental difference. I mean when you talk about a traditional Waterfall approach, it's premised on starting off with a holistic view of all of the requirements. So at the very start of your process what you are going to do is you're going to sit down and you're going to gather all of the requirements that sound like they are a good idea. And as long as they sound like they're a good idea, they're going to be included in the project itself.

Now from that pool of requirements, you're going to look at those requirements and you're going to basically guess at how long it would take to develop all those of requirement and from that guess of how long it's going to take to develop all of that requirements from a time perspective, you will establish how much budget is necessary to be able to do it.

When you talk about doing it under an Agile approach, it's actually the exact opposite of that. Under an Agile approach what you're going to do is you're going to start off and you're going to say: "Alright! Well, what is the maximum amount of money that we can spend and still deliver the return on investment that we promised the funding committee when we went before them for approval? What's the maximum amount of money that we can spend and still deliver that ROI?" From that maximum amount of money that you can spend, it's going to buy you a dedicated development team for a set period of time.

Under an Agile model, what you're going to do is you're going to start off and say: "Alright! Well what is the maximum amount of money that we can spend and still deliver the ROI that we promised the organization? What's the maximum amount of money that we can spend and still deliver that return on investment?" Now from that maximum amount of money that you can spend, that's going to buy you a dedicated development team for a set period of time. And now what you're going to do is you're going to start building out those priority requirements and the requirements that you build, you're going to build them to completion. What I mean by that is you're going to elaborate the requirements, design them, develop them, test them, integrate them, document them and have them approved. And so those requirements that you build, you will build them to completion and you will know that they work.

But as you move through the project, you're going to start having less money available to you, right? The development team is not free. And consequently, you're going to start having less time available to you and eventually what's going to happen is you're going to run out of money. Consequently, you're going to run out of time and when you run out of money and consequently, you run out of time, those requirements that you have built them to completion and you will know that they work and those requirements that you haven't built, well, that's just requirement Darwinism. I mean you cannot get everything and we made the choice of these requirements for higher priority than those requirements.

And so, the nice thing about this is that it basically takes catastrophic failure off the table because whenever that money runs out, you will not only have something. You're going to have your highest priority something.

Cornelius Fichtner: Okay. Let me make sure I understand this right. Under Waterfall, we start out with the scope. We define the scope down to the smallest screw then we estimate this is how much it's going to cost us to deliver. We start working on it. Money starts running out and you're starting to get really frightened about what's going to happen, how much can we actually do. The customer comes in, changes priorities, adds scope, adds scope, adds scope and in the end, we're nowhere.

Under Agile, we're turning this around. We're pretty much saying, okay, this is not 100% correct but: Okay, you have $100,000 of budget. Now let's see how far this is going to take us. Tell me which are your highest priorities. We work on this first. We deliver this to you totally finished. They work. You can use them and at the end when money runs out, you will have actual working product available to you.

Mark Layton: That is correct, yeah. And what we did in that 100,000, well always been your highest priority as you yourself defined it and you will also see where that 100,000 line is and so we're going to be able to provide some visibility into which requirement you're actually getting for that 100,000 as our knowledge grows.

So one of the things that is kind of problematic under a traditional model is when we talk about requesting additional funding, it was hostage-taking situation. You get 85% into the project and then you'd go to the business and you'd say: "Well we need another 10% to complete the project. I know you're going to give me that 10% because these are what are choices are. Your choices are you give me the 10% and we complete the project or you can get nothing and you will have wasted the 85%." So it's kind of a bit of a hostage-taking situation.

Whereas the business under an Agile approach, you're always making business decisions from the point in which you are like: "Well, I've gotten my highest priority 90% of the requirements." Now when I look at those requirements that are going to fall below the line that it looks like I may not get, well do I want to fund all of them? Do I want to fund some of them? Do I want to fund none of them? But I can actually make that decision, add a requirement by requirement basis rather than it's-all-or-nothing type of basis.

Cornelius Fichtner: Okay! What about scope creep?

Mark Layton: Well scope creep really isn’t a problem under an Agile model. Under a Waterfall model, you had the concept of scope creep, which was pretty simple, right? I would give you a generic requirement and then as my understanding of what I actually wanted grow, I would go: "Yeah, yeah, that thing that I want, that's part of my earlier definition of the requirement itself." So you need to just do that now, right?

Under an Agile model, it's different in that because you know we're going to allow changes fluidly all throughout the project. As your knowledge of what it is that you're looking for grows, you're going to be able to put it into the project with no problem. But we've ran out of money point. That's not fuzzy. So requirements and the interpretation of the requirements, they're fuzzy. Those can be exploited on both sides. But you know, you either have money left or you don’t have money left isn’t fuzzy.

And so the nice thing about an Agile model is we're going to be able to give the business a lot of flexibility to get a better understanding what they're looking for an easily move those requirements into the project but we're also going to protect the development team from the perspective of saying: "Hey look, it isn’t your fault that there might be a gap between what's been requested in my head and what's been interpreted by you." And so both sides actually went under an Agile model because of that clarity.

Cornelius Fichtner: Alright! Before we get into how do we actually estimate these various features that we want to bring in to the project through an Agile model, what does Platinum Edge do? What is your company known for?

Mark Layton: Sure. Well we’re an Agile transformation company and we're one of the few companies who's actually been in this space for a long time. We were founded in 2001. We've been doing it for about 12 years now. And what we do is we do Agile transformation. So taking companies that are used to doing traditional Waterfall approach and using an audit training and transformation model to convert them into using Agile and getting the results that you can get from an Agile approach. The results are phenomenal to be honest with you. We regularly bring 30 to 40% time to market acceleration to our client projects, 30 to 70% cost savings and that's huge.

We work mostly in the Fortune hundreds. I'm not talking about littlesmallcookingbuddy.com projects. I mean I'm talking about billions of dollars in revenue, global teams, real governance, Fortune hundred companies. It's even in those environments that we can provide that type of performance improvement. It's very exciting.

The way we do it: We come in. We do an assessment of that organization as it stands today. We start to say: "Hey this is what your organization looks like today. This is what it would need to look like under an Agile model." We get everybody on the same page as far as proper training is concern. So they're literally going through the same training and we're not having misinterpretations of what we're talking about from a terminology perspective and then we'll actually embed coaches within the organizations working on live projects so that the behavioral change that has to happen in the moment. Because behavioral change happens in the moment. You can't say: "Oh yeah last Tuesday, I think I did this thing." You need to be able to sit down and say: "No, no, no! That's not what I was talking about. Don’t do it like this. Do it like that. You see how that's different? Okay, now you do it. Uh-huh, now see." And then we help build that new thing. Because the reason that it's hard for people to change is because well, we've been doing in a different way…

Cornelius Fichtner: Since the 60's!

Mark Layton: Yeah, yeah. For decades, right? And so what is executing a project in your mind has a certain pattern? And so changing that pattern isn’t as easy as people think and I think that that's a big challenge, people think it's going to be easier than it is in reality.

Cornelius Fichtner: Alright! And here's my little plug for your company because your company also does training and thanks to your training, you personally, I am now a Certified Scrum Master. So if you out there are looking to become CSM-certified as well, I recommend Mark Layton and Platinum Edge because I've personally gone through their training. And I enjoyed myself.

Alright! Coming back to Agile estimation. So how do we estimate?

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.