Selling Features We Don’t Have
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.
Comments (7)
Jim Benson
Hi Mike,
Nice thoughts.
I want to put one additional thought in … that the issue with estimates is that they try to boil a chaotic system to a simple number. The number that results from our estimates do not take into account variation.
Software development’s individual tasks suffer from great and inestimable variation. The nature of the work means an alleged one hour task can be anywhere from one to eight hours long – depending on the winds of cruel fate.
If we could estimate perfectly, we would be in a commoditized business and coders would make $10 an hour. A lot of my work lately has been spent convincing coders and management alike that knowledge work is inventive and filled with understandable variation.
I totally agree with the conclusion that marketing and software devs need to work together when announcing new features … or potential new features. The most successful companies I see in that area let the customers know a portion of the backlog and then let the customers vote on what’s coming up. Not only is this good feedback to the company, but it underscores to the customers that the features are not ready and won’t be ready for some time.
Thanks again,
jim
Jim,
My personal belief, shaped from first hand experience working with teams, is that features and tasks are much more estimateable than we give them credit for. Shared understanding, active risk management, assumption validation, and a willingness to deal with reality all contribute to being able to create a useable and useful estimate.
I acknowledge that there are some problem areas that don’t require or benefit from estimation, but some do. being able to estimate IMO does not commoditize building software. This post was really to explore the notion that overcommitting is underneath much bad estimating,
Thanks for the comment!
Bob Marshall
In “Necessary by Not Sufficient”, Goldratt lays down a means to ensure that features are added to a product ONLY when they add value to prospective customers. (BTW Grant Rule and I have build on this to produce a teachable method of calculating business value for prospective (product) features).
Further, I regularly feel compelled to ask “why estimate?”. Until folks grok the requirements for which estimation is (most often) an implicit solution, how can anyone say with any certainty that estimation has any value?
Cheers
Bob
Hey Bob,
Thanks for the comment. If estimating isn’t necessary or useful, don’t do it. Most of the clients I work with can use estimating to make better commitments, increase shared understanding, build trust, and establish a baseline to measure against. I’ve got no motivation in my practice to do or teach anything that doesn’t work or isn’t useful. I usually start with very heavy explicit estimation until teams learn each other and get good at decomposing work. As they mature we lighten the process. I could see eliminating it all together if we had sufficient shared understanding and uniformly small features (but IMO, that is just an implicit form of estimating).
I started this thread (and plan to continue it for a while) because its my belief that not all estimation is waste, and I think the advice some of us give is actually harmful without understanding someone’s context. Just because there are a few teams out there that have been successful abandoning estimates, doesn’t mean that YOUR team is going to have that same success. Likewise, just because my teams tend to benefit from estimation, doesn’t mean that YOU need to estimate.
Thanks again for the comment.
Lisa Davidson
Very Interesting post. I was looking for such information. Can you share your views on Agile testing methodologies. What are the benefits from a QA Testing point of view.
David J Bland
“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.”
At first, especially as a Developer, I thought selling a feature that you do not have was unacceptable behavior. Over the years, I’ve come to embrace it with one big caveat.
Customer Development.
We are selling something we do not have to determine whether or not it is worth building.
I’m comfortable using feature fakes, building minimum viable products or conducting surveys around a feature that does not yet exist. I’m also ok with making it to look like it does exist or using Wizard of Oz or Concierge tactics to do so. Sometimes it is the only way to find out if there is a real market need.
Some of the companies I work with are in a position where, everyone knows they don’t have the feature, but they agree to put the new feature in, such that they can close the deal. The net effect is a hard time, cost, and scope commitment that may or may not be possible. The commitment may or may not have been supported by an initial estimate, but there is no longer any room to move without violating the terms of the contract. Nearly an impossible situation for many of these organizations.