The act of estimating work brings no value to your customers.
This is not to say that there is no value in estimating work. There certainly can be. But in terms of benefiting the customer the amount of time and effort spent in coming up with estimates is worthless. A customer does not care whether you hit your deadlines, unless missing a deadline adversely impacts them. Conversely, a customer does not care whether you made a deadline or finished a project early, and for the same reasons. This is also not to say that there is no value in delivering a project within a certain time frame. There can be tremendous value in that, from being the first to market on a new offering or just putting something into production that begins generating revenue or cost savings.
But the act of estimating in and of itself, and the act of basing project milestones on those estimations, has little to no value. Human beings are notoriously bad at estimating, and no matter how much effort is put into attempting to define processes that can help in that effort the fact remains that the larger and more complex the work is the less accurate your estimates about how long it will take to complete will be, so time spent trying to come up with estimates is wasteful.
So why do we estimate at all? Why do I, as an Agile Coach, teach teams about things like story points or relative sizing? What that’s the point?
Being able to predict when you’ll deliver value to your customers.
That’s it. That’s the only reason to estimate work. The methods of estimation that I teach are tools that a team can use to predict what value they will generate during their next iteration, and the more mature a team is the less time they will spend coming up with those estimates. The goal is to eliminate the need to use estimating tools entirely. A high performing, mature team should be able to accurately plan the value they will generate in the next iteration (sprint) without needing to put a numeric value on that work.
There is a lot that must happen for that goal to be met. A key component of that is for external forces (i.e. managers, supervisors, executives) to trust that the team wants to, and will be, as productive as possible without constant scrutiny. That’s a big ask, but without it the whole house of cards collapses.
So when I see leadership teams fret about an organization needing to get better at setting realistic timelines for project completion I worry, because when I see that I see delivery teams spending extra time trying to come up with “accurate” deadlines that are, ultimately, going to be wrong. What’s more, that the time spent coming up with those bad estimates could have been spent doing things that generate value for the customers. The only true value generated by asking a team to estimate is that it gives someone removed from the work the ability to absolve themselves from blame when the work is not completed on time (which is, of course, one of the many factors that lead to teams inflating their estimates).
This is always the point when someone looks at me and asks if I’m advocating some sort of system in which there are no deadlines or expectations and teams just churn out whatever they want in their own time without any kind of external influence.
No, of course not.
What I’m advocating is that dates and deadlines should be focused around value.
I’m going to turn to Star Trek to explain my point because that is, as the saying goes, how I roll.
In the original Star Trek series, Chief Engineer Montgomery “Scotty” Scott is often referred to as being a “miracle worker” because he always seems to provide his Captain, James T. Kirk, with what is needed to save the day despite Captain Kirk giving him unrealistic deadlines. In a typical exchange, Captain Kirk will explain to Scotty what the problem is and ask how long it will take to solve it. Scotty will quickly give him an answer (say, for example, “three hours”) and Kirk will respond that he has 10 minutes. Somehow, Scotty always manages to deliver in those 10 minutes. Scotty eventually revealed that he always inflated his estimates to Captain Kirk because “Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.”
I realize that I run the risk of offending by saying that this applies to business leaders as well as starship captains but, frankly, it does. Estimates and project deadlines are ways that we try to force a scenario in which we get everything we want, not what we need. Without that focus we cannot even begin to have the conversation around delivering with a Minimum Viable Product (MVP) mindset.
So how could this work in the real world?
By setting deadlines tied to customer/business value and cost of delay, we flip the conversation from “when will this be done” to “what can be done in this time frame?” This encourages everyone involved to focus on delivering instead of “moving cards to Done” to meet expectations. In a healthy and trusting environment, it also can provide opportunities for external stakeholders to remove impediments that are preventing value from being delivered in a timely fashion. If, for example, the reason that a team cannot deliver value by a set deadline is because they are still working on other projects those projects could be delayed or, even better, stopped altogether (which also requires the existing projects to be organized in an MVP factor AND for the organization as a whole to resist the trap of the sunken cost fallacy).
Some questions inevitably arise when contemplating this kind of scenario. The answer to most of them ultimately boils down to “you have to trust your teams” but I will address a few in particular.
Doesn’t Parkinson’s Law state that work will expand to fill the time allotted?
It does, but that is a result of the kind of behavior that I’ve talked about here. When someone knows that they are being held to a deadline, and that often the deadlines they are being held to are arbitrary and meaningless, they understandably tend to take advantage of scenarios that develop that allow them to take some breathing room. In a high trust environment if a team becomes idle and literally cannot find things to do that are valuable uses of their time they will let you know.
But we’re not doing the work! How can we possibly tell a team when it should be done by?
By focusing on the value instead of focusing on finishing a “project.” Tell the team what you need. Tell them when you need it by. Let them tell you if they can do it, and if not let them tell you what they can do in that time frame. If that’s not satisfactory, ask them what they need to meet that time frame. If you can give that to them, do it. If not, modify your expectations. Don’t change your dates, change the scope of your request. If you’re being unrealistic your teams will tell you. Listen to them. Trust them.
Does this mean I won’t ever get everything I want out of a project?
Maybe it does. That’s ok. To paraphrase yet another frequently cited business world axiom, “80% of the value comes from 20% of the effort.” If your teams can focus on delivering value often and regularly instead of meeting deadlines, you will likely find that it’s ok to not get everything you want. More importantly, you’ll find that getting everything you want can be incredibly wasteful.
What if we’re wrong?
What if you are? Will the world end? Will you go out of business completely? Chances are the answer to both those questions is “no.” If the work your teams deliver does not generate the value that you expected, focus on getting better at predicting value, not deadlines. Ask your teams to do the same. Learn from each other. Run short experiments. Take risks. Spend less time planning and more time doing.
Be, I don’t know, Agile?
