At the moment, I’m sitting at a gate at Newark Airport, waiting to board an extremely delayed flight that will take me to the South by Southwest Interactive festival in Austin, TX, where I’ll be speaking on a panel discussing estimating software projects (“Project Estimation: 3 Firms Light Up the Dark Art”, March 7th, 5PM in the San Jacinto Ballroom). I figured that I’d use this unexpected idle time to capture some of the points that I hope I’ll be able to make.
To be honest, while I’m excited to be speaking at SXSW, I wasn’t at all excited at first to be talking about this topic; it’s an area that’s not considered ‘cool’ in modern software development circles. The most obvious indication of this attitude is an article in a recent issue of Pragmatic Programmer Magazine by Ron Jeffries titled “Estimation is Evil: Overcoming the Estimation Obsession.” Many of the points that he makes are valid:
- When you start with a list of requirements that represents the entire project and attempt to estimate that, it’s a sure thing that your estimate is wrong.
- At the beginning of any project, it’s really not possible to have a realistic definition of what the features that will be present at the end of that project will even be (made even murkier by the fact that a really successful project doesn’t ever end).
-
Stakeholders have an unfortunate habit of putting too much stock in our estimates, and when they are revealed to be inaccurate (almost a guarantee, as that’s part of the nature of an estimate), those stakeholders usually react negatively, eventually going into a panic mode.
That article was countered by Phillip Armour in the January 2014 issue in a short article titled “Estimation is Not Evil.” In Armour’s view, the Waterfall model that’s ridiculed by Jeffries (and to be fair, almost all of the rest of us as well) never really existed in the form that we like to make fun of. According to him, the Waterfall model was not a development methodology, but instead a management technique that gives a simplified model to track a project’s completion. I’m not sure that I buy this assertion, but do agree with his followup point: Agile methodologies are focused on how to run a project in such a way that each iteration of work done by a team provides the most value to the project, but they have nothing to say about how stakeholders have an idea of the resources that will be needed to get that project done.
This is one reason that I’ve always thought that any of the agile methodologies as they are available off the shelf make more sense in an in-house environment where a development team can be budgeted for on a long-term ongoing basis; in the world that I’m used to, that’s a very difficult thing to do when a client is looking to do something more like a one-off project, and can only make a go/no-go decision on the basis of some form of estimated time and budget to completion.
Basically, I don’t think that this Manichaean treatment of the topic is very helpful.
In my experience, the following things are true when working on software:
- Clients want to have an idea of how much money they’ll need to spend on their project.
- Clients believe that they know exactly what they want the project to consist of, and the more certain they are of that, the more wrong they are.
- By the nature of the beast, the scope of software projects will naturally expand (and occasionally contract, if you can believe it).
- When the need for new features arises, a good developer needs to be able to accept that change and welcome it (and add it to the project without too much drama, redesign, or any accidental disasters). They also need to be able to explain the impact of that change to the client in terms of time and budget, and let the client decide to go or no-go as a result of that.
- Features that seem trivial to a client to implement are sometimes inexplicably difficult to implement, and letting them know that as soon as possible lets them make better decisions. Over the years, I’ve had plenty of examples of this happening to be told by a client to drop the feature request — it was worth x to them, but not the integer-multiple of x that our estimate indicated it would take.
- We don’t really know how to execute large software projects, but we do know how to execute lots of sequential small projects
- A client who wants a waterfall model for budget and schedule but an agile model for adding scope to the project without a corresponding adjustment in the budget or schedule is going to be an unhappy client. The developers aren’t going to have any more fun than the client.
- Projects where we’ve encountered the most success and happiest clients are those where we’ve maintained a steady rhythm of delivering releases demonstrating continual progress along with a view of the pieces that are left to be built along with an estimate of the effort still to come. The secret isn’t estimation, it’s re-estimation, all the time.
- The real value of an estimate done before starting a project isn’t that it really reflects any kind of a bottom-line view of what the project will look like at whatever point you designate as the ‘finish line’ — this estimate is done at the time when both the client and developers know the least about that project that they will ever know. The important thing in that estimate is to be able to draw up an initial shared vision fro the thing that they’re considering building together. It’s an opportunity for the client to determine how closely and carefully a developer is listening to them, and for the developer to get their first look at how a client will end up being to work for.
I hope that I get to make most of these points on the panel discussion tomorrow.
