I’ve been managing software projects for much of my career. Early on, I spent most of my time trying to estimate projects more and more effectively. I pulled together models for how to estimate. I kept track of historical estimate vs. actual data, so that I could evaluate the quality of my estimates. I even tried some modeling or arithmetic techniques to fine tune my estimates. Some of these are quite well know techniques like Function Points or Cocomo or the Personal Software Process.
All of this was focused towards estimate quality…not software product quality. I was worrying about how to represent the time to build the software to stakeholders and accountants so that we could reasonably know how much it would cost. Then we could make better decisions around whether to start it or not.
The odd thing, at least in my experience was that no matter how hard I tried nor how much effort I expended on estimation and planning, over 60% of my projects went awry. They failed. They were Death Marches. They were incredibly painful. And in many cases, they resulted in people losing their jobs.
I guess my point is – estimation is incredibly hard.
Now you may say, well Bob, you simply were poor at estimation and didn’t really perform it all that well. My counter is that I am really good at estimation. I’ve studied a wide variety of techniques and applied them diligently. I’ve even taught software estimation at international conferences. So, while I still have much to learn, I’m not a tool-less novice.
And I guess my other more crucial point is – estimation was the wrong place to be focusing my efforts!
What the Agile Methods Taught Me
When I first was introduced to the agile methods I was struck with the practicality of the planning. Instead of focusing on planning & estimation, the methods broke things down into two levels – high level release forecasting and low level detailed iterative planning. More importantly, it was the interplay between these two levels over time that refined your estimates.
No longer did you try to predict a guaranteed endpoint for a project. Instead you gave a reasonable, high level view that you promised to refine every time you got real-time performance results from your team. You would then narrow your view over time as you iteratively gained traction delivering real, working software. At each point of actual data, you would update your release plan / model and re-communicate to stakeholders where things actually stood in relation to their expectations and your previous views.
If you were behind schedule, stakeholders had the option of dropping, reducing, or re-framing scope based on business value and priority. But in order to hold to a date, they would have to adjust something. If you were ahead of schedule, a not so rare event, they could pull in more value-based scope and deliver more than anticipated.
Comments