As agile coaches, we use and value metrics as an objective way to evaluate the…
- 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!”
- 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)
- 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”.
- 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!