Smaller Batches Increase Value Potential
Reading:
Smaller Batches Increase Value Potential
Imagine this…
You’re living in a “perfect” world and you have a number of features/projects you’ve committed to do this year. Since we’re living in a perfect world they will all finish On-Time, On-Budget and with 100% of the requested Scope.
Which of the scenarios would you prefer (and why)?
- Scenario A – All projects start January first and successfully completed by December 31st
- Scenario B – Half the projects start January 1st and finish successfully June 30th; the second half start July 1st and successfully end December 31st
If you’re like most folks that I present this scenario to you said “Well duh, B of course! I get the benefit of the value created by the first half of the projects and don’t negatively impact the delivery of value for the other half. The second half of efforts still finish on-time, on-budget with 100% scope on December 31st!”
NOTE: We’ve now clearly established that “Valuing FINISHING” work is more important than STARTING work”
Just to confirm this observation I follow up with the following question:
“What is the impact if you have a “Hot Project” (Feature) that emerges mid-year? Which scenario would be the one you prefer?” Again, if you’re like most folks I talk with you’ll again select B. You’ve not negatively impacted the first projects. … That value has been accrued for the first batch and you’re in a position to make tradeoff decisions regarding the projects you’re about to start.
In contrast, Scenario A has all projects halfway completed, no value is (yet) on the table.
You’re faced with either shoving the “hot” feature in the midst which will make all efforts go longer to the degree the new feature impacts resources. Alternatively, if you chose to table some partially completed features, you’ll have nothing to show for the time/resources expended … it’s been wasted.
So let’s continue with this mind experiment…
What if that “Hot Feature” cropped up a the end of Q1? Wouldn’t you be faced with a similar issue?
We’ve already established that “Finishing efforts is preferable to starting efforts (since finishing is where we see the value). Wouldn’t you prefer to have a third scenario that looked like C? And remember, we’re still living in the perfect world where we successfully meet all of our triple constraints of scope, budget and schedule.
Again, the value for the first couple of Features has been realized and we’re in a position to make tradeoffs and adjustments based on the new Feature that just cropped up. Much better…..
NOTE: We’ve confirmed (again) that “Finishing is more valuable than starting” and now begun to illustrate that “Smaller Batch size” gives us more options and the ability to pivot when new opportunities present themselves. In essence, we’re limiting our exposure to being partially complete with nothing we can productively use or sell to show for that effort an increasing the value potential of the work.
OK … NOW for the “dirty little secret”
We don’t live in a perfect world, Murphy exists and all those things you THINK are valuable may actually NOT be valuable! (That last one really gets me every time).
Everything we produce (software, product, services et al) are based on a hypothesis that we BELIEVE them to be valuable.
For example:
- IF we create software feature X our customers will self-serve and quit calling us (which is more expensive…we’ll lower our costs and increase our margin).
- IF we create service Y the market will prefer it over our competitors offering (and we’ll increase our market-share, top-line revenue etc)
- IF we create product Z the market will stampede to our door (and we’ll create a whole new market where none existed before)
At this point, you’re probably saying to yourself … “No kidding Sherlock … I knew that already! (…. well, maybe not that third part so much. I “know” that but I keep forgetting it because we’re always working frenetically trying to get stuff out the door and into PROD successfully”. )
So here’s the rub …
IF the “value” we’re expecting to accrue is based on a hypothesis
THEN we’re at risk of our hypothesis being wrong (outright or by some indeterminate amount)
True, we can take a bunch of actions upstream (future post) … but we’ll not KNOW until the feature or service is in the marketplace / PROD. At that point, we can CONFIRM that we’re getting our expected business outcome (lower call center volume, increased engagement or sales).
THAT is our most important feedback!
So let me ask you …
IF some percentage of your hypothesis were WRONG (outright or materially in amount) … which scenario would you prefer to have? A, B or C?
If you’re like most folks I pose this situation to you’re thinking “C”. The reason being that you’ve the most amount of time to course correct and make adjustments to realize your overall year-end vision or goal.
So here’s a pragmatic way to get smaller batches and faster feedback (Scenario C).
All features or projects have value and time components. Visually we could depict the value in the vertical and time in the horizontal.
More often than not these features or projects have “edge cases” or some part that requires a bit more effort than the rest to claw out the value. For arguments’ sake let’s say that 75% of the value can be achieved with 50% of the effort; the remaining 25% of value will take the other 50% of effort.
Having the smaller batch to get feedback faster presents the opportunity to:
- Adjust sooner (more runway to recover) if the value hypothesis is wrong or materially lower
- Increase the overall potential value achieved by swapping the “last 25%” value batch for something of “higher value”.
Bottom line …
- Perfect world or not … Value Finishing work over Starting (Limit Work In Process or WIP)
- The “value” for most of the software features or products we pursue are based on a hypothesis … we’ll KNOW once it is in production or available to the market; therefore,
- Get faster feedback on the value hypothesis (i.e. KNOWING) by using smaller batches!
Comments (3)
Yashodhan Kholgade
Excellent article Jim. Thanks. The illustration is useful and leads naturally towards basics of Agile. I really loved the simplicity of examples and explanation. Would look forward your other posts.
Jim Hayden
My pleasure! I’ve found that simplicity (not simplistic) helps explain things best. There are always complexities and caveats … it’s the principle(s) at play that are most important (e.g. How to think about the problem).
Oleg S.
Jim, this is truly a gem!
You have a gift of explaining things. I’d love to see more of the posts like this one.
Thank you!