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 solving the right problems the right way. 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.
