I don't think I have ever done a post for the sole purpose of linking…
Okay, so the beef with estimating seems to go like this… we all agree developers are bad at estimating, we all know that managers will misuse any estimates we give them, and we all know the team will have to go on a death march to meet an unreasonable date the manager set. Since we don’t like managers and we don’t like death marches, we conclude the creation of software is an unpredictable process, that estimates are bad, and we should never estimate at all. Is it possible that we don’t really have an estimating problem? Is it possible that we have a bad management problem? What if we decided to keep estimating and just decided to stop having bad managers? Would that solve the problem?
We could always just create an approach that didn’t have managers at all? Oh, wait… we’ve done that, it’s called Scrum ;-)
All kidding aside, I don’t see any reason to stop estimating. In fact, unless your business model supports totally emergent outcomes, chances are you have some sort of goal, some sort of business outcome you are tracking toward that is tied to a hard, somewhat pre-defined deliverable. Chances are you’ve sold something to some customer and now you have to make good on that commitment. These are not emergent outcomes, they are convergent… we are trying to manage the process to optimally hit some predefined target. Inspecting and adapting is about optimizing our chances of creating, not just any successful business outcome, but a specific business outcome. We can debate this business model all day long, but if that’s your reality, you need estimates.
But we have to remember, estimates are just that… estimates. We know they are wrong by their very nature. That said, I have personally coached teams that have gotten very good at relative estimation, and stabilizing their velocity, and are extremely reliable predicitng 3-6 months out. Their estimates are actually pretty good. Here’s the deal… estimates have to have ranges and probabilities. Assumptions have to be managed and risks have to be mitigated. We have to be able to measure how wrong our estimates are so that we can start to forecast that error forward. Is it possible that estimates aren’t the problem, but the failure to manage the estimates? We have to constantly adapt our plan to deal with our current reality… no matter how difficult that might be, no matter how much we might want the outcome to be different.
And therein may lie the real problem with bad estimates, and bad management in relation to bad estimates. We want our reality to be different, we need our reality to be different, our reality just HAS to be different… so we ignore the facts… we ignore what the data is telling us. We ignore the team’s actual performance against the estimate. There is so much competitive pressure to deliver, so much pressure to add those extra features by the end of next month so we can make the sale, so much pressure to deliver those features our sales team committed to win that big deal. So much pressure that we ignore reality. We promise against the most optimistic possible outcome. We have to have everything yesterday so we don’t buffer or plan for the unexpected. We don’t deal with reality when it presents itself.
The problem with estimating isn’t that estimates are bad. We know they are bad going in. Most organizations I work with can at least get them somewhat in control and a little bit consistent. Having teams that stay together and establish a stable velocity levels out many of the remaining bumps and makes them a useful approximation. Given a known estimated backlog, we can manage deviation and change and keep the business informed about how things are going. All we are really looking for is a baseline to measure against. The real problem is that, far too often, we oversell the organizations ability to deliver. The real problem lies in creating a ‘you have to deliver at all costs’ culture that doesn’t respect the teams established capacity to build working tested software.
More often than not, the root of this problem is selling features we don’t have in order to close business. Selling features on the chance that the team can deliver them on time, that’s where it all starts to break down. If we only sold what was available, or on the near term product roadmap, I think we’d be having a very different conversation about the value of estimates. We could use them to give us a rough idea of what’s possible and use them as a management baseline to measure where we were against where we hoped to be. Bad estimates become a problem, bad management becomes a problem, in the face of unyielding pressure to deliver against unreasonable expectations and inflexible project schedules and commitments.
If your company is in position that it has to sell features it doesn’t have to stay viable, you are taking a huge gamble that you’ll be able to deliver. Sometime that gamble is the right thing to do… I’m not arguing that. But you have to realize the risk and have a strategy to deal with it. Hoping that the developer estimates are going to be accurate is false hope. Failure to have a strategy for dealing with estimates when they are wrong is bad management. Having a well groomed backlog, keeping teams together over time, aligning teams with business units or products, holding teams accountable for establishing a stable velocity, will all help make estimates more accurate over time. Nothing is going to help if we can’t deal with the reality of an oversubscribed product delivery team.