Clayton Lengel-Zigich and Derek Neighbors discuss agile estimation.

Transcript:

Clayton Lengel‑Zigich:  People treat estimates like estimates, and guesses look in the beginning. Then, when it comes time to do the actual project, they think that the estimates are non‑negotiable. Somehow, if they don’t perform, or they don’t get the velocity done, what they thought it was in the estimation process, now that they’ve talked to the customer, they feel like they’re going to be chastised for that. I think that’s pretty fascinating.

[music]

Announcer:  Have you ever felt tempted to pad time or cost estimations for a project you’ll be involved with? In this episode of “Intergrum Scrumcast,” Derek Neighbors interviews our very own Clayton Lengel‑Zigich, about how agile estimation addresses the fears of both management and developers.

Derek Neighbors:  Today I have with me Clayton, from Integrum. Clayton, I just wanted to talk to you a little bit about some of the blog posts you’ve been getting lately. I saw that you did a post on estimation, and some of the lies we tell ourselves about estimation. Why don’t you give me some of your thoughts on estimating? What do you think makes estimating difficult for developers?

Clayton:  I think there’s a lot of competing roles among estimating. I think, traditionally, a lot of people have experience with estimations, where there’s someone like a project manager or someone like that ‑‑ a manager of some sort. They have certain goals about estimations. Or maybe even a sales person. It seems like they want to try and get a low estimation. At least people get that impression. Developers get that impression.

Then developers have a competing interest, where they want their estimations to be padded so that when it comes time to do the project, they are not having to work extra hard to get things done super fast. They think that the estimations need to be broad and, “Let’s give myself lots of extra room. I know that this problem is going to take a really long time, so I’m going to pad this estimation, and give myself extra time to get it done.”

You have these two competing interests, and I think they come together and clash. With that, I think developers and your manager or salesperson or project manager kind of thing, they have these competing interests. I think the developer is trying to win out, but usually they just tell themselves these lies to try and win that side of the argument. It doesn’t ever seem to work out.

Derek:  I definitely think that in most organizations, estimation is used in a negative light. There definitely are competing interests, and the person with the money wants the budget to be as low as humanly possible. The person doing the work wants to make sure that they’ve got a commitment that they can drive to.

One of the things that I like about Agile estimation and planning done right, is that each phase of the estimation is done in isolation of the other phases. You can go in, and you can estimate a difficulty on something. But it doesn’t have a time value to it. Even if a developer decides they want to pad something, in truth it’s not until you determine your velocity that you’re really putting something in a place that lets you know what your numbers are.

I think if you are able to do some of those things in isolation, it shields the ability for developers to pad, and for project managers or planners to be able to dictate the length, and the cost of a project. I find it interesting that people still have knee jerk reactions. One of the things I see a lot is, I’ll see a developer who will be involved in the estimation process, and be completely happy with what they see the estimation to be on a story by story basis.

I’ll see them be part of the velocity determination, going into a project where they get an estimated velocity. They seem fairly happy with the estimated velocity. Then, a couple of weeks go by, and they are assigned to a team. The first thing they do is freak out that the velocity is not fair, and all the estimates are wrong, even though they were part of that entire process.

Why do you think that some developers fall into that trap?

Clayton:  I think part of it is that people do the estimations. They have a different mindset. When they’re doing the estimations, they treat them like they’re estimations, right? This is a guess, this is my best guess. They treat it like they are supposed to for the most part, when they’re doing the estimations. They’re part of a group usually doing estimates is more than one person.

When they’re doing that, I think they get comfortable, and they think, “I think this is the three complexity, and so does this other guy. OK, I’m confident with that.” Then maybe they do the velocity, and maybe they are talking afterwards and they say, “Oh, my estimate was I think 20 points for an iteration,” or something.

The other guy says, “Yeah, I was 23.” When they do that, I think they are feeling very comfortable, and it doesn’t really mean much to them, because it’s just an estimate. They treat it that way. Then when it comes time to do the project, I think they throw all that out the window. Now it’s like they’re committed to this, and they’re sticking their neck out ‑‑ or they feel that way at least.

They feel that if they don’t do it, it reflects poorly on them or their job performance, or even their ability to estimate. That’s something I find very interesting, that people treat estimates like estimates and guesses in the beginning, and then when it comes time to do the actual project, they think that the estimates are non‑negotiable.

Somehow if they don’t perform or they don’t get the velocity done what they thought it was in the estimation process, now that they’ve talked to the customer, they feel like they’re going to be chastised for that. I think that’s pretty fascinating.

Derek:  I’m curious. What do you think it is in people that makes them have that change? I think one of the beauties is in doing each of the pieces in isolation, you really don’t think of it necessarily as a commitment. You’re really being true to it being an estimate. When that project goes live, and the switch is flipped so to speak, there definitely is that panic, that reality moment.

How do you think developers can overcome that initial sprints, panic moment, looking at a velocity and not letting it paralyze them, and instead let them gauge an accurate velocity for the project going forward?

Clayton:  I, certainly, think that a lot of that just comes down to when the project starts or maybe they have the initial planning meeting with their customer, they just need to be realistic about what everyone’s expectations are. Maybe if you’re a little kid, and you get in trouble, or you do something wrong and you’re waiting for your parents to come home, and you’re freaking out about how terrible it’s going to be, and you make such a huge deal out of it.

When in reality it gets to, as long as you’re honest about it, it’s never as big of a deal as you thought. Same thing with the projects ‑‑ they start out and everyone panics and they get paralyzed. When you have that conversation, and you talk about expectations and then you realize, the s sign of velocity was this.

But now that we have had this conversation, we’ve talked about it for a little bit, I can see that some of these stories are more complex, or at least the scale of complexity is a little bit different. We’re going to need to have a conversation about how that affects the velocity in the project, et cetera, et cetera. People don’t ever get to that point. The developers typically get to a point of paralysis and then they start making excuses.

They forget all about the fact that they estimated these stories and they were happy with the estimates and now it’s,” Oh, God, I’m on the line for this. I better do something about it. I don’t know what I’m going to do. It’s not my fault. The estimates are bad.” Their excuses start coming at that point.

Derek:  I find it interesting, that usually [inaudible 07:07] when we’re estimating, we talk about simplest solution possible. When we do our story workshops, and we work with customers, we state that going into it, unless they specifically add weight to the story that would indicate that it was more deep than simplest solution possible.

I see a lot of times what happens is when the first planning meeting comes around and acceptance criteria start to be collected, the stories quickly balloon out of simplest solution possible. That’s where some of that fear sets. I’m reminded, I believe it’s a bank that has the commercials where a person from the bank goes to the first kid and says, “Do you want to dump truck”? They bring him a little toy, a piece of crap dump truck.

They go to the second kid, and they give him the real dump truck. The first kid is, “What the hell, I just got screwed. You didn’t tell me I could have a real dump truck.” Sometimes we look at those commercials and we laugh, because it’s so hilarious, the disparity between the first item that the child was given and the second one, and how there was an extreme bait and switch.

A lot of time developers fall into that bait and switch, and the customer upfront says, “I’m totally OK with the little Tyco dump truck.” When they come into the first planning meeting they say, “No, no, no. I’m getting the Cummings diesel dump truck. I’m not OK with the Tyco dump truck.” How do you propose that developers can better negotiate those situations with a customer?

Clayton:  Maybe the biggest part is just confidence in being assertive. A lot of developers feel or, at least they’re treated in their organization, or they just have a lower opinion of themselves and they feel that their job is to satisfy someone else’s desires in terms of, “OK, you tell me to do this and I’m just going to do it.” There’s a great “bogfest” by Uncle Bob Martin about a professional versus a laborer.

He was saying that if you went to a doctor, and you said, “Hey, Doc, my arm hurts. Cut it off.” A laborer would say, “OK, sure.” But a doctor would say, “Hey, I’m a professional. That’s not what I do. I’m going to do the professional thing.” Developers will get into the habit of, in that first planning meeting when maybe the estimate was a simplest possible solution.

Now the customers going off this tangent about what they want, they don’t have the confidence to make themselves stand out and say, “I know that’s what you want, but let’s talk about the trade‑off. Let’s talk about how that impacts the rest of the project. If you really do want this whiz‑bang, gold plated feature, then you’re going to have to have these trade‑offs.” I don’t think the developers do a good job of expressing that.

The clients certainly don’t understand to some degree, if they do have all these things. I guess everyone understands that there’s trade‑offs, but no one really talks about them until the very end, or until it’s too late, at least. In terms of how do you become more assertive, I think you need to go into the planning meeting with the understanding that you are the technical expert at the very least.

You need to make sure that the customer understands that you have their best interests is in mind. You want to look out what’s best for them so that whatever trade‑offs they decide to make, and if they do really do want this certain feature, that they are going to understand the full impact of that and that you know how that’s going to impact the project.

Derek:  I definitely agree. I think that a large part of doing agile well is confidence. One of the biggest mistakes teams make is they look at Agile as being a surely simple thing, because on the surface it seems really simple. There’s not a whole lot of rules, on the surface there’s not a lot of structure, per se.

But underneath the principles are a lot of subtleties. The difference between knowing those subtleties and not knowing those subtleties is the difference between success and failure. When you don’t know the subtleties, but you think you know what you’re doing, you don’t have confidence.

When you know the subtleties, it’s very easy to be confident in your discussions with product owners, project managers, with other developers. I really think that makes a huge difference. I love the Bob Martin analogy, and I think in my mind here, the difference between a professional and an amateur is confidence. Obviously, that’s not wholly true but there is some truth to it.

Thanks for joining us today, and we wish to have you on in the future.

Clayton:  Great, thanks.