Why Relative Size estimation works better?

A good estimation at its best is an informed Guess.

Traditional method has been to use historical data and provide an estimate of the effort required to complete an activity or task. The High level activity, could be broken down into sub activities and estimated at appropriate granularity & subsequently aggregated. The team may or may not participate in arriving at the estimates, they are at times arrived at by an expert group.

Once committed and execution begins, the project may start deviating from the plans. In such cases, the Program manager is dependent on the value of Remaining Work (which is continuously changing, and varies as time progresses) to provide re-planned dates.

Historical Data is from the past project, only after completing this running project, will the information gets appended to history data and re-adjusted. (historic values does not provide much support to the current running project)

Looking at the relative Size estimation that is prevalent with Agile processes, a different paradigm is followed. Metaphorically speaking, Here too the High level Activities (Epics) are broken down to smaller activities (Stories). But here the stories are compared against each other to arrive at their relative size (XS, S,M.L, XL etc.) and Points are assigned to them. The team participates in the activity and estimates are arrived at based on discussions and concensus

A few sprints are executed and schedule commitments are made based on the teams current velocity (not dependent on historical data); hence the schedule reflects the teams current performance.

Here too there can be deviations from plan. there is a better view of the Remaining work in terms of pending Story points. In case we realize the estimates are wrong, they tend to be wrong uniformly, hence the re-plan can be based on proportional readjustment across all stories (for example 1.2 x).

Thus Relative Size based estimates are better option with higher confidence on the resulting plans.

3 Steps to successful Org transformation

To make a successful organizational transformation, there are only three overarching needs, everything else is subordinate to these

I) Leaders need to believe in the transition process & the benefits of making the transition

II) Leaders need to demonstrate that belief, through their actions and communications.

III) Both 1 & 2 above has to be continued till the transition is complete and deemed Sustainable

Dilution in any one of the above is a recipe for failure, while perseverance demonstrated on the 3 Steps, guarantees Success

The Science behind Agile thinking

Agile Manifesto and principles form the premise for most Agile thinking. Donald Reinertsen in his book, “The Principles of Product development flow” helps us understand why it is economical to shift to an Agile mindset.

Here are a few key points that interested me (Refer the book for more breadth and depth)

For the product development Flow to be effective, we need to understand the economics of Queue’s, Variation, Work-In-process, batch Size, Fast feedback, Sequencing and their interrelations.

Queue’s increase Cycle Time, Variability and Cost of Process. As capacity Utilization increases Queues increase exponentially and processes become unstable.  The longer we delay adding capacity or shedding demand, the more expensive the problem becomes.

Variation is better managed by addressing the other parameters. Perform many small experiments (rather than one big one). Through repetition, reuse, and standardization variation is reduced.

By reducing project scope, we trigger a regenerative cycle of Faster Cycle time, Lower Risk, and shorter planning Horizons. This results in reduced need for oversight. Outcomes are more predictable as forecasting becomes exponentially easier for short time horizons. Accept variability in content to prevent variability in timing

Smaller Batch Size, improve Cycle Time and reduce variability in flow.

As Batch size become larger the consequences of failure increases exponentially, feedback is delayed, Overheads increase and rework will be more expensive. Large batches dilute responsibility and are de-motivating due to delayed feedback. Large Batches make Schedule & Cost grow up exponentially. When we batch together a no. of items the entire batch acquires the properties of its most limiting element.

Small batches reduces risk, there is less changes in technology or requirements to address. Small changes are easier to debug than large ones. Fast feedback improves efficiency because engineers are more efficient when something is fresh in their mind. Small batch size is a powerful tool to Increase urgency, motivation & Accountability. Short run lengths reduces Queues.

Always maintain a regular cadence. Regular cadence of small batch Size reduces Co-ordination overhead. A regular cadence for product introduction prevents delays in one product from cascading to other products. If we have to meet a regular product launch schedule, we need capacity margin to absorb schedule delays at intermediate milestones & variations.

To better understand on Queue theory, Variation, Work-In-process, batch Size, Fast feedback, Sequencing and their impact on product development, I recommend Don’s “The principles of product development FLOW, Second generation Lean Product development”