Finance concepts for managing uncertainty and its resulting risk to the value of an asset are finding root again in software development. Derivatives of various stripes have traditionally been used in the financial world to provide some level of insurance against the fluctuation in an asset’s price.
Alistair Cockburn recently questioned the reasoning of “Last Responsible Moment” as it pertains to agile thinking. In so doing he opened up a conversation on how best to handle risk and uncertainty in software development.
A later follow up to this post recognized Chris Matts, Olav Maassen and Karl Scotland for bringing forth real options into debate among the agile and lean communities. The topic is not necessarily new for software development. A quick search on Amazon or Google will show this. But it may be re-awakening as a potential way to help agile scale better. Chris Matts, Olav Maassen wrote about this in 2007 on InfoQ.
With the rekindled interest by the agile and lean communities for real options should we expect to see further evolution of risk management techniques in software development? History would seem to indicate so. As suggested by this blog post, agile techniques were largely a reaction and outgrowth to dealing with risk in one of the key areas of application development: requirements.
Requirements risk has been a consistent theme in software and application development and even the author of this article has written a few posts on the value in reducing risk around requirements through improved gathering techniques.
But at the heart of all these views is the underlying assumption: we can make software development more predictable, and less prone to waste. But can we?
Lean methodology theorists believe so. Jack Milunsky crafted some blog posts in 2009 on the 7 Software Development Wastes, paralleling Lean Manufacturing’s 7 wastes. His view is that these areas cause much of the variability in software development:
- Partially done work
- Extra Features
- Relearning
- Handoffs
- Task Switching
- Delays
- Bugs
But software development is also seen as a craft or creative effort. Those pushing this view often take exception to the Lean crowd’s comparisons to manufacturing. Gary Police wrote an article about art and craftsmanship in software. His position: great work (software or otherwise) come out of experimentation, mistakes, and a drive/passion to do one’s best. This view would seem to suggest that waste is an inherent part of creativity and by extension; software development.
So what’s your view? Can we drive further predictability in software development or by doing so are we destroying the very creative juices that make it so valuable?