Agile antipattern: But the development lead said it would take way less time than that

I’d be rich if I had a nickel for every time I’ve heard this, or something very similar to it, in the past 30 years!  Alright, that’s taking it too far, but I think I could at least afford a really nice dinner out with my family on the amount I’d have received.  But that isn’t the point.  The point is anyone thinking this statement is a valid excuse for poor results is wrong on several fronts.

Before we go any further, if the title intrigued you, immediately click on the image to the left and purchase Mike Cohn’s bible about agile estimating and planning!  If you don’t own this book, then I now know why the title of this blog post made you look further!

Now, back to the issue at hand and why it is wrong to think this way.  First of all, this type of statement is part of the reason a waterfall model doesn’t work.  In the waterfall model it is typically development leads or other managers giving the time estimates.  This isn’t a written rule for a waterfall approach, but it seems to be given how often I have seen it in my career.  Let’s think about it for a second and see why this is the wrong way to approach things.  Is the development lead rewarded when a lot of software gets completed?  If so, this incentive is at least subliminally causing them to cut time estimates to the bone.  Is the development lead more experienced than most members of the team?  If so (and I hope the answer is yes!), then he or she is likely to estimate for their rate of development, not the rate of development for an average team member.  Does the development lead have enough clarity to actually give a meaningful answer?  If yes, great, but in most cases the answer is no.  Again, this leads to an estimate which may be on the low side due to a lack of knowledge about specifics.  So just from a logic point of view, using a model where the development lead estimates time is bad.

Second, on agile teams some goals are to collaborate well, and be held accountable for results.  If this is true (and it is), then we are completely bypassing both of these.  We are not allowing the team to collaborate to come up with an estimate they can live with.  Further we are holding them accountable to a result when they were not given the opportunity to give input.  We are back to waterfall where someone says we need x by date y and I told with Joe and he said we could do it, so do it.  That isn’t agile, that’s lunacy!

Lastly, we have taken a single data point and assumed it is 100% accurate at the start.  Even in a waterfall project it is well known that accuracy of estimates at the beginning of a project vary widely.  Review the cone of uncertainty to learn more about how bad it can be.  Part of our goal in agile is to deal with the cone of uncertainty by iterating toward a result.  So to add insult to injury, we assumed the estimate was correct, and we didn’t check on it each iteration to deal with reality.  How not agile can you get?

Project managers are starting to recognize that estimating is different in agile.  This blog post from PM Toolbox is just one example.  There are many more things to consider when estimating.  For example, things sometimes get more difficult at the end of a project (or at least development slows down).  There is a reason the 80/20 rule is often cited!  There are lots of ways to estimate, and lots of ways to do it poorly.

The bottom line is the worst thing anyone can do is ask a development lead to estimate something and then hold an agile team accountable to the estimate.  Collaborate and use planning poker to create estimates and you will be a lot happier in the long run.  There is even planningpoker.com for teams that are distributed!

Time for me to get ready for a trip to Boston where I’ll be starting down the path of  Making Agile a Reality™ for another client.