Value First and #NoEstimates – two s > Recently I came across two approaches that claim to solve the problem "how to always succeed with your projects by delivering always on-time, on-or under-budget"Kai Gilb’s Value First and Vasco Duarte’s #NoEstimates.

As I have studied these approaches a bit deeper (I have a note on a workshop at Vasco’s at NovaTec and I attended a webinar with Kai, besides reading their respective books and other related stuff) in common but focus different areas of project work.

Part 1 of this small series of blog posts, Value First and #NoEstimates – two sides of a coin? Part 1: Value First provided a look at the key points of Kai Gilb’s Value first. Part 2 explains Vasco Duarte’s #NoEstimates. Part 3 compares both approaches.

Vasco Duarte: #NoEstimates

Vasco Duarte bases #NoEstimates on Lean foundations: Estimations are inherently waste. They do not add value to the customer. 25% of the actual results 75% of the time. These means are not exact and have a very little confidence level. This results in the wide variance we see in agile and traditional (waterfall-like) projects. Vasco duarte aims at reducing waste in a similar way to the lean production movement. Lean Production reduced inventories down to just in time production in the past. So let’s eliminate effort for estimation and focus on real value setting activities.

Why are estimates so bad?

Main reasons for the discrepancies between theories and reality according to Vasco Duarte are:

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law. (Douglas Hofstadter – in Gödel, Escher, Bach: An Eternal Golden Braid, 20th anniversary ed., 1999, p. 152. ISBN 0-465-02656-7.)
Parkinson’s Law: Work expands so as to fill the time available for its completion.
Accidental Complication (Ordev 2013): organizational structures (and how long does it take to get the approval for a new test environment?) And the changes made to it. The overall complication of a problem resulting from this accidental complication Ha) and the inherent complexity of the problem to be solved, called essential complication g (e), can be expressed by a function f (g (e), h (a)). H(A) usually has a much higher influence than g (e) when it comes to software development. These results in the fact that the functionality of the device is not the cost of a feature. But that’s the way estimation is done in most initiatives.
Inherent Complexity in software project is not predictable since it’s usually a learning endeavor. It resembles something like starting “By building a tent, then evolve into a hat, and then into a trailer, and later on deliver a castle” (Vasco Duarte). I like the picture of a castle – think of a medieval castle, built over years. It reminds me of some big systems I came across – not all legacy systems ….

What do we estimate for?

So why are we using estimates? Vasco comes up with three decisions or activities that are meant to be supported by estimates:

Project sizing and budgeting
How many people does the team consist of? How long will it take? How much does I need to pay?
Forecasting project progress towards a delivery: scope and time in meeting a release milestone
Will we deliver on time? What will we deliver at a given release milestone?
Removing risk of failure
What contingency plans do we need? What buffers (time and budget) do we need to do on time (so a budget of sizing and budgeting)?

How do we solve this?

This all comes down to following problems that are better with better methods than estimation:

speed & Distance– without estimates
How fast are we doing progress? When will we be ready to deliver a certain scope? #NoEstimates measures speed by counting in a sprint / iteration. As Vasco and others empirically find out more about how to do this. The distance to go is the number of stories in your backlog. Using past data from the past 3 to 5 iterations, you do not need to estimate. You can observe and forecast the system “Development initiative” System theory and process quality management have some tools to help you in observation and forecasting, e.g. control charts and the accompanying rules of quality control. It’s really surprising how good these forecasts are.
Using this speed forecast you can probably deliver milestone. Using upper and lower limits of the control chart (using one sigma is best for development processes as vasco experienced) you get a range of stories. Now you can start a discussion on the topics and stories you should include.
Remove Risk of Failure – without spending all the time planning
How do we tackle the risk of failure? Vasco recommends a plan to survive and not to plan for the absence of failure like it’s done in many projects in real life. To build a robust system – the technical system you develop as well as the development process – to survive in case of a failure. Use small cycles and feedback loops to reduce the risk to perish in case of a failure. Break down the work to remove risk not size! Vasco uses an interesting decision matrix for story break down (see picture).
Deliver on business goals – without waiting on the end of the project to know if we get what we need
How do you know focus on the right things to deliver? How do we know early, if we’re on track? Vasco proposes daily goal based on the business goals, to work only on those experiments >

Vasco Duarte’s decision matrix

How to size team and how to set budget

For project sizing, Vasco proposes analogous estimation at a high level to set team size at project start. Then use the usual PDCA cycle (plan, do, check, act – the Deming Cycle). As a budget is an investment in development, you should not base it on the cost >

# NoEstimate’s Main Takeaways

My main takeaways of Vasco’s workshop are:

A project is a system and as follows follows system theory. Performance is defined by system to a great extent. You can not predict system behavior of a sufficient complex system, e.g. a development project. You can only experiment and observe the result.
Size a project team using analogous estimation – or start with a small team. Then use PDCA cycle to make adjustments to project team as necessary.
Set budget by a investment decision based on the value you want to achieve. Check that decision and the result so far every few iterations or so.
Focus on most important thing to solve – prioritization is key to success, not estimation
Use #NoEstimates forecast for forecasting

What do you think? Is Vasco’s approach applicable at your place? Let us know your thoughts.

Value first and #noestimates – two sides of a coin? Part 3: value focus

Value First and #NoEstimates – two s > Recently I came across two approaches that claim to solve the problem “Always to succeed with your projects by…
Value first and #noestimates – two sides of a coin? Part 1: value first

Value First and #NoEstimates – two s > Recently I came across two approaches that claim to solve the problem “Always to succeed with your projects by…
My very first philippines trip part 1 – 2 without plan in manila

My very first trip to the Philippines – Part 1 Two without a plan in Manila – a travelogue How it all started is always such a question … But this time…
Manduca first baby carrier test �� your support consultant!

Manduca First Baby Carrier Experienced stretcher parents often respond instinctively to the Manduca brand when asked about suitable stretcher assistance….