The Value of Learning

Last night during a panel discussion on the application of agility outside software development, I was asked how to quantify the value of learning.  I was caught off guard by this question as learning has always been at the core of agility in my mind and so I've never thought about the value of it separately from agility.  This experience prompted me to think about the difference between creating value regularly and learning regularly.

The agile manifesto values working software over comprehensive documentation.  Scrum focuses on the delivery of a (potentially) shippable product increment at the end of every sprint.  What probably doesn't get spoken of enough is that the value of accomplishing working product regularly is not just in the incremental value of the delivered product but the value of learning whether we are delivering the RIGHT value.  If we aren’t, we have valid evidence to support a change in direction.  Having functionality that is potentially shippable is NECESSARY to facilitate a valid learning feedback loop.  One could argue that the value of the delivered functionality is secondary to the learning created by the valid feedback loop.

One of the criticisms of applying agility outside of software is that you can’t/don’t release a partially completed gas plant or piece of farm equipment to customers.  They only get released when they’re ‘complete’.  All the value is present or none of the value is present.  I would argue that position only takes into account the functional value produced regularly, not the learning feedback loop.  When applying an iterative / incremental approach to other fields such as manufacturing or construction, that learning feedback loop can still be achieved without a holistic 'potentially shippable' product increment via the use of robust test fixtures.  This has tremendous value in these domains because most of the risk in manufacturing/construction is in the engineering/procurement rather than in the construction delivery activity. 

Project grammar

I sometimes wonder if the field of Project Management spends too much time emphasizing management of the noun vs management of the verb.

PROject (n)
A temporary group endeavour undertaken to create a unique product, service or result.

proJECT (v)
To thrust forward.
To estimate or predict based on present data or trends.
To direct one's voice so as to be heard clearly at a distance.
To cause an image to appear on a surface.

Isn't project management really about managing the actions/decisions necessary to achieve a desired outcome?  Focusing on projections of the desired outcome, based on present data or trends, is how we truly manage risk on a project; the risk of shipping the wrong product, the risk of shipping a low quality product, and the risk of shipping late or not at all.  The first key to mitigating these risks, of course, is to ensure that the present data and trends used to make the projections are both valid and valuable.  The second key is to update the present data regularly, accordingly update the projections, and then make decisions.  These concepts describe two of the primary elements of iterative/incremental development.  Successful proJECT management is much more akin to causing an image to appear or hearing clearly at a distance than it is to simply endeavouring to achieve a result.