How does Value survive over Time?

I have found it difficult to describe the Agile pay off, or value proposition when introducing Agile.  Perhaps your audience is aware of agile, maybe even attempting a few agile projects.  But how do you describe the value proposition?  Is it faster time to market? …True but not the entire scope initially.  Is it higher quality? …quite possible.  Is it more transparency? …sure but we have lots of meetings already.  Is it Customer Delight? … Perhaps, but how do you measure that?

What I have found to be useful is to plot Value over Time and compare it with a standard waterfall approach.  At the simplest level, both approaches will get something out to your customers.  But are both approaches equal in what they deliver?  Are they equal in Value to the customer?

Often Value is based on meeting the outputs, not the outcomes.  Meaning, a traditional waterfall approach in government contracting would recognize value as having met the contract deliverables.  In other words, having delivered on every requirement.  That is good, but often misses the mark on what is valuable to the actual end user/customer.  Why?  Because the vast majority of requirements defined upfront are not valued (Standish Group – 64% of features are rarely or never used).
Time is the enemy of Value

As time marches on, the value of anticipated IT delivery value reduces.  For instance, at the onset of a new solution, the perceived value is quite large.  This value is calculated (typically not formally, but in our heads…) based on the current reality, need, understanding, technology, etc. Time causes Value (real or perceived) to atrophy.  If the delivery of the value takes a year, several factors are lined up against the full delivery of that perceived value…  It is not possible to meet the perceived value established at the onset without continuous feedback from the customer on the understanding of that value through the course of that year.  Waterfall will put distance between the perceived value and actual value fundamentally through the help of time.  Technology understanding and innovation will have eaten away at the value of the delivery, the requirement understanding, and original needs that drove the initial value will have changed over the course of time (1 year) reducing the actual value.  Contracts will insist that all perceived value (i.e. requirements) defined up front, must be delivered.  The industry recognizes that 60+% of those very requirements are of little or no value.  The odds are against delivering value, and encourage the delivery of outputs that intrinsically have less value.

Agile tries to deliver a much more modest set of perceived value on a much quicker pace, perhaps every 3 months.  At best agile might deliver 25% of the originally perceived value (from a waterfall perspective), but much closer to 100% of the narrower expectations established for the 3 month delivery.  Although less than waterfall’s initial delivery, the primary difference is that the atrophy to that value from the time of the initial delivery to the next delivery is very little.  But how is that you may ask?  Remember that with agile, we are prioritizing on value to the end user and we do this on a regular cadence.  In addition, the user is looking at the incremental value every two weeks and can make adjustments to optimize the value.  When the next delivery of value occurs, the net gain in value delivered is higher.  Again, time has difficulty grabbing hold of the delivered value and pull it down because the next focused, high value delivery is just around the corner…

The following diagram describes this idea.  The reality is that agile, when done well, continues to deliver incremental gains in value while reducing value atrophy by reducing the time between value delivery.  One of the intangible value enhancers is having satisfied users.  User satisfaction is a multiplier to perceived value.  When users see incremental value delivery they remain satisfied.  When users do not see incremental improvements and have to live with a solution that does not deliver what they need with no improvements in sight, the net effect is a value detractor.  Not to mention that the original perceived value is less than thought due to a large portion of the delivered requirements are not useful.  Delivered product that has limited value becomes a value detractor that accelerates value atrophy over time.

Value over Time

Evergreen Factor

Another multiplier to frequent high value deliveries is the “evergreen” factor.  The evergreen factor is the notion that a project stays incrementally valuable longer.  Through short value delivery cycles, the solution is always being refreshed and relevant for the user, and evolving with the business.  This greatly slows the value atrophy.  This is significantly different than long release cycles with the occasional “fixes” updates.  Waterfall tends to not evolve with the business, it is in a perpetual dance of catch up. This dance accelerates value atrophy for waterfall projects.
Conclusion

Time is the enemy of Value.  It is critical to timebox deliveries, prioritize on the highest value items for the customer, and create a regular cadence to get an incremental solution out the door.  An agile approach helps to deliver value on a regular basis, engages the customer on a regular basis, ensures quality is maintained, and is the ultimate way to establish transparency.
[su_note]What are your thoughts? Is it possible to get on a quick cadence and avoid value atrophy on government contracts?[/su_note]