The discussion around #NoEstimates was just about to come to an end, when Vasco posted a nice summary. Here's my take on his post in the domain and context of large, complex, mission critical, enterprise class software intensive projects.
Vasco's topics for the #NE rationale are below. But these phrases can be found on the programs we work as well.
- Focus of Value, Manage the Risk
- Value is defined by fulfilling the capabilities needed by the business or mission.
- These capabilities provide the ability to do something of value.
- The units of measure for these capabilities is Effectiveness. This means how effective is the provided technical and operational items at meeting the needs of the user.
- For a business capability, the MoE's can be measured in dollars, customer retention or satisfaction, inventory turns, and things like that.
- For mission capability, these are usually measured by the user. For example in a ground attack aircraft the technical requirement of holding a 7G turn, provides the capability to get back on target rapidly
- Discover the Product, Measure the Throughput
- The Product is the outcome of the project. It can also be a Service.
- The delivery of products at the planned time of need is the role of the Integrated Master Plan and Integrated Master Schedule (IMP/IMS)
- The IMP/IMS can be notional and represented by sticky notes on the wall, as long as the actual deliverables represent the delivery of a capability
- Measuring progress of these deliverables is done with Technical Performance Measures. These define and measure the technical or operational performance of the product or services (or the sub components).
- Use data you have, Measure Continuously
- The measurements start with Measures of Effectiveness, Measures of Performance, Key Performance Parameters, and Technical Performance Measures.
- These terms will have different meanings in different domains.
- For the light weight, small team, short duration, low risk, low cost project the terms can be developed with face to face discussions, hand waving, white board drawings, etc/
- For complex, large, distributed, high risk, high cost, mission critical projects, more formal methods are needed.
In the End
In the end, if I read Vasco correctly, he's proposing a set of Principles for managing the development of software using #NoEstimates. But I don't see anywhere in this informative post about No Estimating. But there are some inverted logic statements
don’t focus on estimating when the development will be finished, instead you let the rate of development (Throughput) inform your view on when the MVP will be ready.
But if you have your capacity for work and you know the remaining work then you have the ability to estimiate the completion date.
If you intentionally don't do that, well what can I say?
The suggested approach Vasco states in the post is good project management and follows the Five Immutable Pricnples, Practices, and Processes needed to increase your probability of project success. Can't go wrong with his suggestions. Can't go wrong with the 5 Immutable P,P,P's.
But where is the No Estimates part? Espically since measures your capacity for work and knowing something about the remaining work gives you the ETC/EAC for free. Is it just a stuborn you can't make me do estimates approach? That can't be.
So using the topics in the post, how does making no estimates support the delivered value.
What's Next?
- Connect #NE with reality of projects?
- I know #NE'ers don't want this to be a process or a method, but how can it be put to work?
