It's popular to speak about the Agile Manifesto and the 12 Principles of Agile. When we hear that the next big thing in agile is Not Estimating, let's look to see how those 12 Principles can be applied without those estimates?
12 Principles of Agile |
How estimates help implement these principles |
Without estimates, what is missing |
|
1 |
Satisfy customer with continuous delivery of value |
Value cannot be determined without knowing the cost to deliver that value and the time frame the cost is expended. This is basic managerial finance when spending other people’s money Business strategy is based on the delivery of value at the planned time for that value for the planned cost of that value |
Without estimating the delivered value to the business for the estimated cost and time to deliver that value, the balance sheet will be wholly uninformed about when the breakeven date for this expenditure |
2 |
Welcome change to improve the value of products |
When change arrives, the first question is what will be the cost-benefit of this change. Since software development usually operated in the presence of uncertainty, an estimate of the cost and benefit of the change needs to be made. |
Without estimating the impact of the requested change, those paying for the change are exposed to Un-Validated Risk. Will this change impact our return-on-investment? Will this change cause technical, cost, or schedule impacts we don’t know about until it’s too late? |
3 |
Deliver working products often |
How often? Every month, every two weeks? Every day? Estimating the impact, absorption rate, produced monetary value or disrupting costs is part of the decision making process. |
|
4 |
Work together with customers |
Always a good idea, no matter the development method. Those customers may have a fiduciary obligation to know the Estimate at Completion and the Estimate to Complete as you spend their money in the presence of uncertainty. |
So when those customers ask when do you think we’ll be able to start using the software? Or, what’s your estimate of the features we can deliver before the trade show? Or our board is interested in our sales forecast for the feature you’re developing What are you going to say, Oh we don’t estimate our work, or time, or how much money you need to give us. We’re a No Estimates shop, you’ll just have to trust we show up on time, and not spend too much of your money and the marketing and sales folks will get what they need to reach breakeven as planned |
5 |
Build products with motivated individuals |
Yep, can’t go wrong here |
|
6 |
Promote sustained develop rhythms |
Sustained rhythms need some insight into what can be sustained in the presence of uncertainty. The uncertainty that created risk. Uncertainty the results for Aleatory processes of the staff, tools, environments, externalities. |
If you aren’t observing (empirical) and modeling with that data, the confidence that the rhythm can be sustained has no basis of fact. It’s the old FedEx ad, where the guy on the phone says sure I can do that, several times, then when he hangs up askes himself, how can I do that |
7 |
Measure progress with working products |
If you are measuring after the fact you are executing the project with Open Loop Control. What will be cost to get this working product on the date we need the working product? What variance to this planned performance are appearing and what effort, cost or changes are need to get back on plan is Closed Loop Control. |
Without estimates, there is only Open Loop Control. |
8 |
Use face-to-face communication whenever possible |
Yes, good process. But face-to-face is just a mechanism. Answering questions in the face-by-face manner about direction and outcomes in the future in the presence of uncertainty is Closed Loop Control |
|
9 |
Technical excellence and good design improves agility |
Technically compliant products are good products. But there is Epistemic and Aleatory uncertainty is all products. What are the upper and lower control limits for these measures. What are the impacts on the product when the actual measures go outside the upper and lower control limits. Knowing how to set these upper and lower limits, knowing the Epistemic and Aleatory uncertainties that create risk to staying inside the bands is all done through estimates |
Without estimates there can be no Closed Loop Control in the presence of uncertainty. |
10 |
Simplicity is essential |
This is a platitude. How simple is essential is the actual question. This is a Systems Engineering question. We need to remember H. L. Mencken’s quote For every complex problem there is an answer that is clear, simple, and wrong. |
Assessing the parameters for how simple requires estimating the impact of the various components of the system on the complexity of the system. This is a systems engineering function. Addressable in many case by the Design Structure Matrix paradigm and the probabilistic and statistical interactions of these components |
11 |
The best architecture and requirements emerge from self-organizing teams |
This is actually an untested claim. System architecture in non-trivial systems can be guided by architecture reference design. ToGAF, DoDAF, Zachman and other formal framework. Again this is a Systems Engineering process |
Without estimates the interactions both collaborative and interference cannot be assessed, until the product or service is complete |
12 |
Regularly reflect and make adjustments on improving performance |
Making adjustments to the technical and programmatic process in the presence of uncertainty requires estimating the impacts of those adjustments. |
Without estimating the impacts of a decision, when the processes are stochastic, leaves the decision makers in the dark. |
Hoepfully it's clear that estimating is part of making decisions in the agile paradogm, just like it is in any paradigm where uncertanty exists.
To suggest that decision can be made in the presence of uncertainty withoiut estimating the impact of those decisions, ignores to basic principles of Microeconomics of decision making