Let’s set the tone here with a quote from Michelangelo, the original Renaissance Man: “The greater danger for most...
of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.” In business, we need to have some measure of risk to succeed. There’s just no way to achieve greatness by always doing “sure things.” But except for those of us who are really lucky, we have to temper our risk with the same sort of tolerance that we have for risk taking that we have when we invest money for retirement – we have to understand what we’re getting into and feel comfortable with the ratio of risk to benefit, and start to lower our risk profile as we get closer to the date that we want to start reaping our investments. IT managers will learn a three-step process for assessing risk and satisfying customers.
Building the right software
What distinguishes Agile from other ALM methodologies is spelled out in the very first principle of the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Why should this be such a priority for developing software? That’s easy. Unless we focus on the business side of why some software is being developed, we lose sight of the prime directive in business. We lose sight of the fact that the business which funds the development must satisfy customer interests, so as to provide the basis for even funding the development of the software we need to build.
In an Agile world, we don’t just develop software to see how satisfied we can feel by designing an elegant solution. Agile teaches us that it’s just as important to build the right software as it is to build the software right! A corollary to the Agile Manifesto is that we can’t know what software is right by spending 90% of our time talking and writing about it. Understanding future business needs is a lot like defining pornography. A conclusive definition is impossible to state, but “you know it when you see it.” And, when we start seeing software that misses the mark, we save ourselves time and money by either changing our goals early or failing the work early, so we don’t expend time and money backing a loser.
Acknowledging Agile in our lifecycle tells us that we should learn from the misstep and find a better candidate for development. It’s investing in the software we build, and it’s all about feeling comfortable with the ratio of risk to benefit, and lowering our risk profile as we get closer to the date where we want to start harvesting our investments.
Three steps for assessing and managing risk
So, what exactly is the Agile way to treat risk in your ALM of choice? Here are three steps to follow:
- Examine your portfolio of work to do (which you might call a Product Backlog in the Scrum discipline of Agile) and perform a quadrant analysis. Items that are low risk and high benefit are put on the top of the heap. Items that are high risk and high benefit are next, followed by low risk and low benefit ones. Items that are high risk and low benefit should be put at the bottom of the heap and not even considered. So, with the exception of any “low hanging fruit,” start your pursuit of value with the high benefit items, even though they carry high risk with them. Many times, these items are breakthrough ideas that will excite your customers, but are unfamiliar to both you and them.
- To manage the risk that these risky items will actually meet your expectations, you need to gauge customer acceptance early. And, of course the best way of doing that is through the early and continuous delivery of valuable software. What you do not want to do is wait until the very end of a product development cycle to find out that you developed something at great expense that has no value to your customers. This is where Agile mitigates your risk with continuous improvements to both process and product. If your initial idea was a bad one, fail the project and/or product and learn not to make the same mistake in the future. Make sure that your ALM recognizes this to be Agile.
- And, finally, respect where you are in your lifecycle as you go. You can afford to take on risk with both your product and development methodology if there’s enough reason to still rate your risk-to-benefit ratio as low enough to proceed. But that ratio should change over time. For example, your ALM may allow for lessened documentation requirements for external APIs early on. That makes sense when you first start developing an idea in a small team. But when the idea gains traction because of continued “thumbs up” during periodic product snapshot demonstrations, and the number of people working on the product grows, you will have to lower risks going forward. In the example just stated, maybe you have to increase documentation requirements on those external APIs, allowing all team members to have a solid reference point to develop from.
Long-term risk is key to growth
We must take on risk to achieve the biggest gains. But we can’t afford to allow risk to all accumulate until the end of the development cycle, only to find out late in the game that we have missed the mark and overspent time and money chasing a losing idea. We must develop working software early to gauge customer acceptance, even if that means that our ALM treats some of our required development practices differently over time. Long-term risk is key to growth. But we must become more risk adverse as our timeframe to release gets shorter. Our ALM needs to respect that.
Remember your Agile principles when thinking about risk. Plan appropriately, keeping your options open for great future benefits as you traverse the journey from vision to roadmap to release to iteration to daily planning. Planning to succeed demands that we take risks, and the Agile principles of openness, transparency, frequent demonstration of the work in progress, and appropriate reevaluation of the course we take will deliver us to the land of plenty and not just the safest harbor we can imagine. Strict avoidance of risk along the way inevitably leads us down a course that avoids many of the benefits that could have been achieved on an Agile journey. We need to avoid setting our aim too low, and achieving our mark.
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.
Dig Deeper on Software Project Management Process