Every stakeholder of software development has the same two questions and some have an unreasonable third demand:
- How much can I get by my deadline?
- How long will it take to deliver all of this?
- I want all of this by my deadline.
Let’s agree that the third ask of getting everything demanded by a deadline without any flexibility in scope or schedule is most often physically impossible. Some make such demands as a way of bidding high so they can get more by their deadline. My experience is that it is an ineffective tactic that results in mistrust and defensive tactics taken by developers to prevent being held accountable.
The first two questions can be answered, but not by estimation. Estimation works great for project managers who are working in environments of low uncertainty such as construction. Predictability is attempted by Project Managers by building a WBS (Work Breakdown Structure). This is a list of big items that must be completed broken down into their individual tasks in an ever increasing pyramid of tasks, people, and time/cost estimates. Adding up the estimates of the specialists who do the work gives an approximate completion time and cost. Estimates are often re-used when the task is frequently repeated using the same people and materials. Construction projects are held to schedule, scope, and cost goals and penalties are charged for overruns with equal rewards for coming in under the wire with time and money to spare.
Somehow, this technique was ported into software development where it doesn’t work very well because of uncertainty. In the world of digital creation, the same people never do the same thing twice with the same materials unless they are doing something like installing hardware and installing software just like they did in the previous job. In short, it works when they are doing construction.
Once we look at creative design, coding, testing, and deploying software, though, estimates inevitably are proven as waste. People who frequently claim their estimation systems work often have correction systems built which cover up the fact that their original estimates were low value. Integrated Change Control, which is designed to help a construction project prevent changes to the plan that might derail the execution of the original plan, is misused to create endless change requests to adjust the plan and the estimates throughout the project lifecycle. This just covers up the problem: estimation isn’t providing an accurate forecast. It is just a pro-forma exercise that is later changed repeatedly.
Estimates are costly to produce and lack any foundation to predict the future. The original plan never succeeds. There are always piles of changes. It’s beautiful evidence of uncertainty, but a terrible way to manage it: pretending we can plan it away, make some estimates, build in some buffer, and then change the plan over and over again.
Uncertainty is not eliminated by planning or estimation.
In fact, over-planning often increases problems by creating longer timelines and larger batches of work which result in more variability, more defects, more risk, and more interruptions which prevent successful delivery of priority work.
Empiricism is the agile way of building software based on accepting uncertainty and letting go of construction estimates as a software practice. Empiricism is a tool that sits on a platform of short cycle times and frequent throughput brought about by controlling work-in-process and doing small batch work. With smaller, more frequent delivery, feedback is obtained on a faster cadence, and the direction of doing better work and the risk of any delivery in particular is lowered.
Teams that engage in this type of work do not stand up expensive war rooms and go on time-consuming and sometimes terrifying bug hunts through hundreds of changes that dropped into production that morning. They drop in a small change, and if it goes badly, they easily back it back out – often with automation. Think of it as small, short projects with a fixed end date and flexible scope that may surprise at the end.
But even in this model, estimation proves a silly, often non-value-add activity.
Predictability in software development is best achieved through flow metrics – not story points or hour/money guesses. Measuring cycle time, work-in-process, throughput, and item aging are incredibly valuable, and the pile of data they provide can be tossed into a Monte Carlo simulation. That simulation will provide a probability for current or future work to be completed which is based in historical evidence rather than estimations (guesses).
To get work flowing it must be decomposed. WIP is controlled by limiting the number of actively worked things allowed simultaneously and disallowing those things from being large. Stop putting work items into projects and deliver them separately embracing small batch work.
Understanding lean principles and empiricism is at the heart of agile. But most people only know some goofy practices like daily meetings and story points, and they believe that by merely doing those things work will speed up.
It won’t.
ActionableAgile.com provides tools that can be plugged into common tools like Jira and ADO which provide the ability to perform Monte Carlo analysis on work. This sort of analysis is used at Hitachi, Expedia, and Northrup Grumman to predict completion of development efforts instead of guesstimating hours, dollars, or points. I did not ask their permission for a screenshot of their Monte Carlo results nor was I paid for an endorsement.