The PMBOK outlines the specific actions required for proper risk management. In this third installment of Michele Sliger's four-part column series, she looks at this risk management process and determines how compliance with the PMBOK practices correspond to activities that an agile team might do.
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.
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.
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).
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