Agile Development Reduces Risk

July 6, 2010

In my post, What is Better About Agile Development? (a reprint of the article Top 10 Reasons to Use Agile Development that I wrote for, my third reason for using Agile development is that Agile development reduces risk. This post examines the topic in greater detail.

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. 
The first paragraph in my article under reducing risk stated one problem with software development is the “delivery of software where the users ‘got what they asked for, but it isn’t what they wanted’ because the requirements were not understood in the first place.” I’ve experienced this myself more than once, and others that I’ve talked to over the years have the same experience.

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 reported at the 2007 Agile Conference, where Steve Greene and Chris Fry noted that “…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.


PM Hut said...

Hi Dave,

This is a controversial article that I'm not sure a lot of "traditional" Project Managers agree with. I've actually read a comment yesterday claiming that Agile solves the problem of risk in requirements altogether.

I hope you would have the chance to look at this short article that offers a totally different view on the subject.

July 7, 2010 at 11:52 AM
XebiaLabs said...

Hi Dave, nice article. I agree that Agile development helps eliminate risks, however, I would argue that to keep delivering working software in the faster iterations Agile allows, we have to go a step further and address deployment. I like your point about how using Agile reduces project time, yet without a successfully deployment process, like automation, operations teams may get bogged down by a backlog of software developments, rendering the advantages of Agile ineffective. Deployment automation is yet another way to bring down risks further in (both agile and waterfall-like) development projects. Do you agree addressing deployment is a crucial step to take Agile development to the next level?

July 15, 2010 at 3:46 PM
Dave Moran said...


There are a number of ways to render a project ineffective (Agile or Waterfall) as you noted about deployment. I personally like addressing deployment at the beginning of a project using an "iteration 0" concept of establishing a continuous build environment and deployment capability. If you don't strive to automate early, you risk creating a difficult-to-deploy product that requires individuals from the development organization to assist in the deployment (I've seen this happen).

You certainly don't want operations teams bogged down with deployment either. The last thing you want are deployment problems gating your ability to quickly respond and adapt to the business. So yes, I agree that deployment is a consideration!

July 16, 2010 at 12:38 PM
XebiaLabs said...

Well said. I agree companies should put automation practices in place early and like your idea of ‘iteration 0.’ Looking forward to reading more of your thoughts on this.

July 21, 2010 at 9:03 AM

Post a Comment