There's a recent post titled Four Fallacious Reasons Why We Estimate.
It lists the usual suspects for why those spending the money think they don't have to estimate how much they plan to spend when they'll be done producing the value they've been assigned to produce for that expenditure. Let's look at each one in more detail. The Italics are from the post and regular texts are my comments.
The original post, while likely well meaning, coming from direct experience, focuses on ME the developer. And like many posts and tweets about estimating, it's made from this point of view, not the business point view, not from the point of view of those paying the developer. This is a recurring theme of #NoEstimates it's a waste to me the developer, I'd rather be coding, I'm not good at estimating, I see no value in my making estimating when you're just going to use them against me when I'm late and over budget.
This all about me approach to spending other people's money creates barriers to addressing the Root Cause of project difficulties and most importantly inhibits open - free and frank - discussion of how to Increase the Probability of Project Success.
So let's take a deeper dive into the contents of the post to see if there can be corrective actions or preventative actions for each of these symptoms.
1. I need an estimate because… I need to measure productivity
Although I understand measuring productivity could work well for repeatable activities, it's hard to believe it works well for abstract and, ultimately, non-repeatable tasks like software development. For non-repeatable activities - meaning it’s never been done before - no one really knows how much time a task should take. Thus, the common approach to "measure productivity" is to compare the estimates against what, in fact, happened. This can cause a number of problems, including the fact that once developers realize they are being judged by their own estimates, they start to be very careful about the process of creating those same estimates, usually spending a lot of precious time completing an activity which doesn’t accrue additional value to the product that they are building.
From my experience, seeking to measure productivity is usually more intense when the side requiring the estimate doesn't have a profound trust that the other side will work very hard. That's why I strive to create an environment with mutual trust between the engineers and the different stakeholders. One of the most powerful techniques in this sense is to have a genuine interest in understanding the reasons behind the requirements for estimates. We engineers should always keep in mind that software development is usually one part of many others inside the company. After having worked for outsourcing, consultancy and product companies I believe that creating a place where people really trust each other is easier when software engineers and stakeholders are both part of the same organization. That's one of the reasons why more and more companies are now considering software development as a core business - thus creating really strong software engineer teams.
Root Cause: Productivity is the efficacy of the investment of time, talent, and money. To know if I'm getting my money's worth we need to establish a target productivity and measure performance against that target. Since all project work is uncertain, we need to estimate what the productivity might be to some level of confidence.
- When might we finish with the planned work?
- What is the possible future work we have not considered yet?
- What might it cost to finish the planned work?
- What's our exposure for NOT finishing the planned work?
These are all probabilistic questions with probabilistic answers.
Corrective Action/Preventative Action: Productivity in software development is simple to define and measure:
- One start is to use Earned Value Management, but we won't go there now, even thought EVM is a powerful tool when applied in the Agile Development world and used on Complex System of Systems in many places.
- The next is to define in the Product Roadmap - in units of money - the Value of the Feature to the product. This Value is developed during the Product Planning session. This is standard Product Management. Done by every Product Manager for every Product Company. The Product Manager is not always the same as the Scrum Product Owner.
- Product management is an organizational lifecycle function within a company dealing with the planning, forecasting, and production, or marketing of a product or products at all stages of the product lifecycle. Similarly, product lifecycle management (PLM) integrates people, data, processes and business systems.
- The Product Owner could be the Product Manager but doesn't have to be.
- Where we work and many others in our Software Intensive System of Systems domain, the Product Manager is usually in marketing or some type of business development role. She identifies the needed Capabilities of the customers to the firm, sorts them out in terms of revenue opportunities, competitive advantage, and other product marketing decision processes.
- This notion of profound trust is not the basis of business management. The audit, surveillance, performance reporting, measurement are at the core of all business processes. Trust but verify is a phrase used by Henry Kissinger regarding the Russians in his day. Agile development works best when there is a trust but verify paradigm.
- Asking to profoundly trust that the developers are spending the money in the proper way would be very naive of those providing the money.
- You wouldn't do that with a lawn mowing service, you wouldn't do that after your car was repaired, and you certainly wouldn't do that after spending perhaps 100's of 1,000's of dollar on a vague and ill defined product development process where your firm's success depends on that work produced by the development team.
- This notion shows that governance is not considered a requirement for the business.
This is the same olde problem we have with estimating definition if you don't define who the players are, assign their roles and responsibilities, then when you use a word it can pretty much mean anything you want it to mean.
2. I need an estimate because… someone else is asking me to provide one
It's incredibly common to hear this reason in an environment with traditional hierarchy where decisions are made top-down. I strongly believe that "agile transformations are not about transforming IT, they are about transforming organizations".
I remember once working for a product where our project manager asked us for an upfront estimate regarding a large feature that would be a game changer in the product. We tried to make it clear it was just a guess, and then provided a 3-month estimate.
Without us realizing it, the marketing team then created a beautiful campaign and started giving hints for the customer that the feature would be launched soon. Unfortunately, due to a variety of reasons, the feature was released with a huge delay. At this point, the marketing team came and asked: "Why did you tell us it would take 3 months? If you didn't know upfront, why didn't you just say you didn't know?"
Cases like this helped me learn not to provide estimates unless someone specifically tells you the reason. In this case, had we realized that marketing would take our estimate as something solid to use to begin promoting to customers, we would have acted quite differently.
The interesting thing is we are so ingrained to the culture of giving estimates that we end up giving them even when no one is asking us! Having in mind how dangerous a reckless estimate can be, I would not provide an estimate unless someone is explicitly asking you one. You can still have a general time frame in your mind, but it may be better to keep it to yourself, thus avoiding problems like the anchoring effect.
Root Cause: Failure to understand the managerial finance processes of any business seems to create the condition for this question and answer. I once was told by a Big 4 Consulting Firm Partner, after suggesting an elaborate Strategic Planning session for a new business opportunity similar to one we had just completed... look it's simple your customers have money and you want it. Find out what they need, what they're willing to pay for that need and when they need it, and build those capabilities at that cost on that date.
Failure to understand that business operates in a MicroEconomics of Decision making paradigm is the start misunderstandings like this reason. Knowing the cost to produce a needed Value, on a needed Date, is core to that correcting this misunderstanding and applied Managerial Finance disciple to the development of software for money.
Know the cost to produce the needed Value at the needed Time is also core to the success of the business.
Corrective Action: Yes, those paying for your work have a fiduciary need to know how much it will cost in the end and along the way, when the Value will be arriving, and even to know that the Value producing Features in the Product Raodamp will be arriving in the order they need to start booking that Value.
When you work where management has little understanding of the estimating processes, stopping estimating isn't going to fix anything. Both management and development need to be on the same page about estimates.
Estimates are NOT Guesses. No matter how many self-proclaimed #NoEstmiates Gurus make that claim.
Here's some background on the definition of estimates, forecasts, and projections. So once again, when established terms are redefined to meet the needs of those unfamiliar with the topic or those simply wanting to change the outcomes of established principles, at best it creates confusion. At worse it ends any conversation about how to increase the probability of project success.
3. I need an estimate because… having one motivates us to work harder
This is a dangerous statement. Although it may encourage the team to stay in the office for longer hours, it’s not a healthy long-term approach. I've seen many teams working very hard to finish tasks before the estimated date. Many have ended up forgetting about other important things in the process, like code quality and a focus on simplicity. The cost of this cannot be underestimated. It will really come to the surface later when the team realizes that, as a result, they have accrued significant technical debts.
Root Cause: Estimates cannot be the basis of motivation. A bad estimate may be a root cause of de-motivation. An unachievable goal. But the act of estimating has no connection with the motivation of the team. If the team is working long hours to meet a deadline, find the root cause of this condition.
Here are four root causes of cost and schedule overruns in our domain. Go find your own. Never Ever make a suggestion to fix something without first determining the root cause and confirming that the corrective action will fix and/or prevent that cause from recurring.
Corrective Actions: perform the needed processes, with the needed data, with the needed skills to generate realistic performance expectations, realistic cost and schedule estimates, adequate risk assessments and mitigation, and start to anticipate the technical issues with prototypes, experiments, reference class models, etc.
Don't Do Stupid Things On Purpose
4. I need an estimate because… I need one to prioritize my backlog
One of the most important and complex questions in software development is, “What should we work on next?” Although I believe that in order to prioritize we should take into consideration the size and effort of the tasks, I'm not convinced we really need estimates to do that. This statement may seem contradictory, but I’ll show you how I've been prioritizing without using estimates.
First - backlog prioritization is essentially a sorting process. As software developers, we know the only requirement to order a list of items is to be able to compare elements. In other words, we don't need to know the absolute value of an item, but we need to know how to compare them. The trick as it relates to estimates is that although we aren’t very good at determining absolute numbers, we are better comparing things of the same nature.
Root Cause: The failure to understand that in the presence of uncertainty, prioritization is a probabilistic process of assessing the possible outcomes - Analysis of Alternatives - for each decision. This AoA requires making estimates of the input data since it is probabilistic and the outcomes since they are probabilistic.
Corrective Action: The answer to what we should work on next starts with the Product Roadmap and Release Plan. The notion is the prioritization of the customer Value is contained in that Product Roadmap. The customer is the owner and is accountable for the contents of the Product Roadmap. It's their product, they own the Value produced by the developers.
This is no different when the development processes are agile or traditional.
Without the Product Roadmap, there is no management of the work toward the goal of the project.
So addressing the Four Fallacies of the Fallacy we can see that NOT Estimating have been made clear.
- Productivity measures are needed to manage the expenditure of funds - am I getting my money's worth from the team? Do I have enough time and money - at the current production rate - to deliver the needed Value, at the needed Cost, at the needed Time?
- Someone asked me to estimate - yes, it's likely that someone who asked is paying you for your work. They likely have a need to know how much it will cost to produce the value they are paying you to produce and when you'll have that value ready for use, so they can start making money in order to continue to pay you.
- Motivation comes in many forms - know the capacity for work, the cost of that capacity, the probabilistic productivity from that capacity provides data when asking hey guys what'a you think we can get out the door by next Friday's release? Since all project work operates in the presence of uncertainty, we need to make estimates in order to answer that question. YES, forecasting the future using data fro the past IS ESTIMATING, no matter how many times #NoEstimates say it isn't.
- Because I need to prioritize my backlog - if each backlog item has a value, then you need to know the cost to produce that value before you can decide what to do next.
- Feature A has Value A, Feature B has Value B
- Feature A's Value is Greater than Feature B's Value by $5,000
- Feature A cost $15,000 more to produce
- Which one do you do first?
