Reducing the Impact of the Reductive Developer

Anyone who has worked on software/application development projects has worked with software/application developers.  Developers are notorious for underestimating work.  For some reason we (yes I am a recovering reductive developer) seem to view work through “rose-colored glasses” when we attempt estimates.  

There are actually many reasons why developers underestimate work.  Some developers are junior or inexperienced when it comes to estimating.  Context switching also leads to poor estimates.  A lack of focus, brought on by excessive context switching, leads to poor execution, including estimation.  However, the biggest source of poor estimating is the single-resource approach.

Regardless of the reason, the reductiveness of developers can be overcome.  The key is to eliminate, or at least reduce, the single-resource estimates.  Traditional projects were estimated using date-based increments (days, hours, etc.).  There are multiple issues with date-based estimating, not the least of which is that dates rarely account for non-project time.  Worse yet, dates take on an emotion aspects.  So, Agile teams have largely abandoned date-based estimates in lieu of stories.

In my experience, team-based estimates reduce ambiguity and variability.  So, in Agile, or even SAFE, work is broken down into stories and tasks, and teams are engaged for planning and estimates.  Over time, teams come to better understand their capabilities, usually expressed in velocity.  Project and iteration retrospectives also help teams better understand the effectiveness of their estimating and execution.  Breaking stories into smaller tasks makes them easier to estimate.  It was the same with WBS and tasks in Waterfall.

Experiential learning is effective when applied to iteration planning.  During these planning sessions, stories are identified, planned, and estimated by the entire team, if need be.  With multiple team members involved in the estimates, developer reductiveness is reduced.  Of course, reoccurring stories/tasks can be estimated more quickly by applying historical data of known successful executions.  This too reduces the inaccuracies of single-resource estimating.

In the end, it is no big surprise that generating estimates from multiple resources, and data, will be more effective than single-resource estimating.  However, some organizations still reply on senior resources to provide estimates that others must except.  The argument most heard is that “…we don’t have time for team-based estimating.”  If that is the case, then I would strongly examine the  overall approach to project delivery.