Every software project has risk associated with it, ranging from business, project, and technical risks. I’m sure that a variety of risks come to mind, but the key points are:
- There isn’t a software development project that doesn’t face risk.
- Reducing risk involves mitigation tactics on multiple fronts.
Requirements problems account for approximately 30-40 percent of a software development budget, based on figures by Dean Leffingwell (reported in his book, Managing Software Requirements, 2003). This includes the experience that Salesforce.com reported at the 2007 Agile Conference, where Steve Greene and Chris Fry noted that Salesforce.com “…experienced problems that most plan-driven projects experience, such as late feedback on features at the end of the release cycle...”
Late feedback at the end of the release cycle isn't bad, unless the feedback is about what you don't have right. When project teams are faced with enough of these requirements problems at the end of a project, discussions typically begin to either push out the project date or to drop features in order to meet the date.
Using an Agile development approach, on the other hand, significantly reduces the risk of this problem from occurring. Because there is continuous involvement from the business, there is less opportunity for misunderstandings to occur. And because of frequent delivery and inspection, a requirements problem will be detected early in the project, allowing the business to weigh the cost and prioritize a requirements change against other features.
Even if a new requirement emerges (a.k.a., scope creep), Agile development accommodates this through rigorous prioritization of the features based on value. Everything can’t be a priority, but if a new feature is determined to be important and valuable mid-way through a project, Agile development allows the feature to be prioritized and worked – with lower-priority items moving down in the queue (backlog).
Controlling scope creep itself if managed through continuous involvement and dialog. The benefit of collaborative development and managing scope creep was written about in an article by Capers Jones in 1996 (Strategies for Managing Requirements Creep), where joint development between user representatives and development was noted to cut requirements creep nearly in half. It is interesting to note that Capers Jones was reporting this in context of Joint Application Development that has been around since the 1970s. While the concept of collaborative development is not new, but Agile development exploits it.
Another way to mitigate risk is to improve project visibility. Understanding exactly what challenges and obstacles that a project team needs to overcome, plus getting a realistic appraisal of their true progress reduces risk because it become possible to intervene to help the team. In the 2009 State of Agile Development Survey sponsored by VersionOne, the second-highest benefit obtained from implementing Agile development was improved project visibility. 83% of respondents said implementing Agile showed either improved or significantly improved project visibility.
We’ve used increased visibility to mitigate risk at my own company. Those of us on the management team formally review each project weekly with the Product Owners and Scrum Masters. We also make every effort to attend the daily stand-ups. This way, we can get a good sense for what is going smoothly and what is not – and we can take action to do whatever needs to be done to help the team move forward.
This counts for the smaller, day-to-day problems and the larger, “we’re not going to make when we thought we were” problems. For example, we encountered one problem where it was apparent that the team was simply too big that is was literally tripping over itself, so we split the team in two and assigned Agile coaches to each team and improved our velocity as a result.
As I noted in my article, the concept of delivering working software can keep schedules and budgets in check, because the software is usable from the outset. If the project begins to take more time than planned, the business has the business has the option of discontinuing making further investment and using what has been delivered to date. Cutting an Agile project short doesn’t mean complete failure. You have some usable software, if you choose to use it.
Again, because Agile development delivers early and often, it gets around another all too common problem: the last 20% of the project takes as long or longer to complete as the first 80% of the project. A number of reasons can cause this: poor up-front estimation, late-stage integration issues as the project team attempts to “bring everything together,” requirements problems, quality issues (because a suite of testing was waiting for a code complete phase), deployment problems, etc. Here’s a couple of links to those who talk about the last 20% occupying large amounts of project time:
In terms of studies that that specifically quantify the risk reduction component of Agile. The 2008 and 2009 State of Agile Development surveys sponsored by VersionOne, contains an actual risk reduction category. 65 percent reported a significant improved or improved risk reduction in project risk, which was consistent with the 2008 figure of 64 percent.
There wasn’t a specific explanation in the studies about what risk covered, but another report, Agile Development: Results Delivered (by VersionOne, 2007), based on their 2006 State of Agile Development survey notes the following about risk:
“Agile development provides empirical control processes required when precision is needed and complexity or change is at a high level. Regular assessments through daily meetings and iteration reviews provide visibility throughout a projects lifetime. As a result, risk is reduced.
“Because planning occurs every iteration, the project risk falls because teams see actual results and reprioritize work to align with the business goals on an ongoing basis. Agile projects can dramatically reduce risk through delivering working software that meets the business goals faster. In contrast, with traditional development processes, risk remains high throughout the development process and is not significantly reduced until project completion.”
In general, the continual delivery of working software and the highly collaborative, visible nature of Agile development reduces many of the risks that traditional, plan-driven projects face. Agile development may not always eliminate the risk, but it should allow you to detect problems earlier, allowing you to and the team to adapt.