According to the PMBOK, "The objectives of Project Risk Management are to increase the probability and impact of positive events and decrease the probability and impact of events adverse to the project." The framework of the agile software development process fosters these objectives by making risk management an intrinsic part of the project lifecycle. Continuously identifying, analyzing, monitoring, and responding to risk triggers and risk events are part of the agile team's iterative planning discussions, which is to say that risks are addressed by everybody all the time. Daily stand-ups, iteration planning meetings, release planning meetings, and retrospective and review meetings are all venues for risk management activities on an agile project.

Agile teams can perform these risk management activities either overtly or organically. Overt risk management on an agile team is clearly stated as such, and things are labeled as risks, mitigation, etc. Organic risk management is that which is intrinsic to the agile process, and risk management emerges out of iterative planning and review activities. Potential risks are instead labeled as "obstacles," "assumptions," or "concerns." In the following examples I'll cite both overt and organic techniques used by agile teams.

Risk-Management Planning
The goal of risk management planning in the PMBOK is to create a plan that describes how the team will do risk management during the course of the project. In an agile environment there is no need to create a formal risk management plan; the method of addressing risk is built into agile procedures. The only decision the team may need to make is whether to conduct risk management activities overtly or organically.

Risk Identification
In traditional project environments, risk identification is conducted in meetings with only a subset of the team members, who use checklists, document reviews, assumption analysis, and various other information gathering techniques to identify project risks and record them in a risk register (what we commonly call a "spreadsheet"). In an agile environment, the whole team does this exercise on an iterative basis during planning meetings, recording results on whiteboards or flipcharts. If the agile team is managing risk overtly, then an agenda item for the team to identify and prioritize risks is included as part of the meeting, with the results influencing the work that is being planned for that iteration. If the agile team is managing risk organically, then potential risks are identified as part of the agenda items "What assumptions are we making?" and "What concerns do we have?" (see Figure 1). Risks continue to be identified daily as part of stand-up meetings, either as obstacles (organic) or new risks (overt).

Risk Analysis
Traditional projects use both quantitative analysis (assigning real numbers to the costs of safeguards and the amount of damage that can occur) and qualitative analysis (using judgment, intuition, and experience in determining risks and potential losses). Agile projects generally perform only qualitative analysis, agile's short development cycles and constant reviews making this feasible and effective. The end result in both cases is a prioritized list of risks to respond to and risks to watch. In an agile environment these emerge from the planning meetings and are posted in a highly visible fashion, as a constant reminder to the team.

Risk Response Planning
Developing options and actions to reduce threats and increase opportunities is performed in both traditional and agile environments. The key difference is that in an agile environment the entire team participates in developing options and actions to reduce threats, a task that is conducted with more frequency than is common in traditional plan-driven projects. Many agile teams doing overt risk management follow Tom DeMarco and Tim Lister's recommended category breakout as explained in their book Waltzing with Bears": Avoid, Mitigate, Contain, or Evade. Figure 2 shows an example of risks being managed using these categories, which are displayed on a whiteboard. The pink Post-its indicate an identified risk, and the smaller, yellow Post-its indicate some action being taken to mitigate or contain that risk.

Risk Monitoring and Controlling
Risk audits, variance/trend analysis, and technical performance measurements are conducted at the end of each agile iteration as part of the iteration review meeting. This meeting provides a forum for the team to review the burndown chart, team velocity, and any other types of metrics the team may be noting. Risk reassessment occurs during the agile iteration retrospective meeting, where previous risks or concerns are revisited as part of determining changes that need to be made going forward. And finally, risks are monitored on a daily basis by the use of highly visible information radiators, such as task boards and burndown charts, which show the current status (see Figure 3 for an example of this organic risk-monitoring tool). Daily stand-up meetings contribute to the constant monitoring process by exposing potential risk triggers and new obstacles.

Summary
The team owns risk management in agile projects. The agile project manager facilitates the process and makes the results visible--whiteboards and flipcharts for collocated teams or in an online information-sharing tool for geographically dispersed teams. Risks are identified in all planning meetings: daily stand-ups, iteration planning meetings, and release planning meetings. Risks are then analyzed and addressed in these same iteration and release planning meetings, with the focus being on qualitative analysis rather than quantitative. Risks are subsequently monitored by the use of high-visibility information radiators, daily stand-ups, and iteration reviews and retrospectives. Risk management in an agile environment is incredibly successful, due to the team's involvement and the agile framework of iterative development that lends itself to active responses to risks and the continuous identification.

Click Here to Read Relating PMBOK Practices to Agile Practices Part 1 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 2 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 4 of 4