How is Risk Management in Agile Development Different From Risk Management in Waterfall Model?

Question

In a typical project lifecycle, as a manager you are expected to have a risk plan which (please correct me if I'm wrong) consists of identifying, assessing and prioritizing all potential risks of the project. However, I don't understand how these things are done in Agile development since many people say it is implicitly managed.

So if that's the case, then does that mean during the lifecycle of an Agile project, there is no risk planning? I'm confused as to how this all works. Or more specifically, how does the entire area of Risk compare with traditional and agile development?

Answer 1

As others have mentioned Agile modifies risk management as compared to Waterfall. A well managed project will include looking at risks outside the scope of the project, and these should be handled more or less the same.

There are areas of risk that Agile methodology should help mitigate.

• Time to Market / Scheduling Error: In a waterfall project it can be months or years before you release. With Agile you should have something that can be released every few weeks.
• Budget Risk: Waterfall projects tend to have significant budget risk as the timeframe to deliver is so long and estimates are often not accurate. While the cost of an agile project may not be estimated any better, it is easier manage to budget.
• Cancellation Cost: If a waterfall project is cancelled late, there may be significant costs with no product. The waterfall methodology may significantly delay the discovery that a project is impractical. A cancelled agile project should produce some functionality if it has run for any length of time.
• Scope Creep: Waterfall projects tend to run into scope creep problems as missed requirements get added to the project without removing other requirements. Agile projects should add the missed requirements to the backlog, push off lesser value requirements, and drop unnecessary requirements.
• Requirement Error: Waterfall projects specify the requirements long before they are delivered. An incorrect requirement can generate significant costs before it is discovered, and more costs in correcting or removing the requirement. Agile fleshes out the requirement when it is being implemented providing much more visibility and a shorter time frame to increase costs.
• Technology Risk: Waterfall projects may specify unproven technology, and it may be several months before problems with the technology are discovered. Agile projects should reduce the time frame before problems are noted, and make adaptation simpler.
• Security Risk: Waterfall projects don't provide a product that can be tested for security until well into the projects. Agile projects produced testable product every few weeks. If security issues are discovered, it may be possible to address them early in an agile project. If necessary, and agile project can adapt its process to deal with discovered security issues.

EDIT: I missed the risk of gold plated requirements. It is much easier to end an Agile project when sufficient functionality has been developed.

Answer 2

You are correct in saying that risk management is typically not explicitly addressed in Agile projects. That is, the process designers intended for typical project risks to be addressed through the practices outlined in the process. As a result, Agile teams traditionally do not use any kind of intentional risk management approach. This works for many teams and many projects, but I have found that ignoring risk is a huge missed opportunity and tends to increase project costs by learning through failure. Further, many projects are different enough from the 'ideal' scenario for a process that it is worth being skeptical about implicit risk management.

There is a great experience report published at the XP2008 conference (Explicit Risk Management in Agile Processes by Nelson, Taran, and Hinojosa) outlining one team's success incorporating the SEI's (Software Engineering Institute) Continuous Risk Management paradigm with Extreme Programming. A past XP team I was on had similar success.

When incorporating risk management practices into Agile teams I've found that there are some key things to keep in mind (some of these are summarized in the referenced paper):

• Remember that agile teams are democratic and self-organizing. There should be an appointed "risk manager" role, but the responsibility for identifying and prioritizing risks lies with the team. The risk manager is really just an enabler and facilitator.
• Keep the risk register public. Wikis work well for this as do other mediums.
• Focus on practices that provide maximum value. In my experience, using multi-voting for prioritizing risks is just as effective as ranking by exposure, takes a lot less time, and is an inclusive activity (good for Agile teams).
• Use the Mini-Small Team Risk Evaluation workshop instead of the full-blown workshop from the SEI. The mini version takes a day or less while the full version requires about 5 days. If your team is well versed in risk management, you can do even lighter weight workshops and still remain effective.

The current thinking in the Agile community is that risk management is important. Most of the Agile thought leaders have gone out of their way to talk about the importance of risk management with respect to agility. That said, I haven't seen much work done to make risk management more accessible to agile practitioners and there is still a wealth of popular literature available that completely ignores the topic.

Answer 3

does that mean during the lifecycle of an Agile project, there is no risk planning?

When people say it is implicitly managed, they hopefully mean it is managed continuously throughout the project. This is done by discussing risks at sprint planning, retrospectives, and so on. The Scrum Master also has an important role removing risks/impediments.

Continuing with Scrum as an example, it does not prescribe explicitly how risk is managed. However, Scrum is a framework and not a full-blown project management methodology: you have to define how to manage risks depending on your needs. Indeed, it is not uncommon for product owners and teams to keep lists of risks that are evaluated continuously.

Answer 4

Not an Agile expert - but I think two of the things that may cause it to look like no risk planning is done are the language, and how it's done in practice.

For the language, I see most Agile practitioners and references refer to "impediments" rather than risks. Same thing really, but it can create the illusion that risk management isn't done, when in reality, impediments/risks are discussed every day.

On the practice side - in a typical (waterfall) project scenario you're going to do risk planning up-front, primarily because you've got a longer duration project, and you're looking at the entire span of the project for potential risks. So you could be trying to identify risks that may be 6-8 months out. Additionally, you may be dealing with outside vendors (parts being manufactured or deliveries) which bring another type of risk and are down the road a bit. So you do 'risk' identification, planning and management.

In an Agile environment, this specific type of risk management isn't always necessary due to the processes used. In a 2-4 week sprint you're going to have a shorter time frame to look at. Also, if you're doing some type of Scrum variation then you may have the daily stand-up meetings, where risks can/will be discussed daily. In a larger type of project these may only get reviewed/updated during the weekly status meetings.