Fotolia
Exercise risk management in Agile software development
With iterative development, teams can deliver features and patches quickly. And project managers must vigilantly avert new and more severe risks that pop up along the way.
Agile software development paradigms might seem perfectly suited to risk mitigation. However, Agile development emphasizes speed and flexibility, which can shift a team's focus away from risk.
While Waterfall projects include copious risk management processes, Agile teams can easily abbreviate or forgo those practices. They might think there's little risk when performance improvements, interface tweaks, bug fixes and new features are just a few iterations away.
In reality, risk management is every bit as important with Agile development. Yet, Agile project managers can encounter a lot of obstacles, as risk must be managed at both the project level and during each iteration.
There are ways to practice risk management in Agile projects; let's examine them.
Risk management basics
With risk management, organizations aim to understand the dangers inherent in an endeavor and put adequate responses in place to address them. Risk management traditionally takes place in five general steps:
- Identify the potential risks.
- Assess the relative severity of each one.
- Prioritize each recognized potential threat.
- Plan responses and contingencies for each risk, especially high-priority risks.
- Monitor and review the response plans.
For example, say a software team intends to run its project on a specific platform, so the developers identify potential risks in technical obsolescence. For mission-critical software projects, these prospective disruptions pose extremely high risks and, therefore, should be high priority. The disruptions might even require adjustments to the project's design plan for better processor-agnostic or platform-agnostic support. For noncritical software projects, the team might consider risks in technical obsolescence a low priority, and it might simply apportion expanded platform support to the project's future roadmap.
When you apply traditional gated or siloed concepts of risk management in Agile projects, it can leave each iteration without adequate risk coverage. Because it's cumbersome to perform these steps for each iteration, Agile practitioners can lose proper risk guidance. Agile methodologies often require risk mitigation at both the project and iteration levels.
Project-level risk management
To oversee risk at the Agile project level, teams should take a broad view that recognizes overall project goals; the project might begin with a risk management review. Project managers will update risk assessments after each iteration, with a continued focus on project-level concerns.
However, not all project-level risks are a factor in every iteration, and some might apply only to iterations that occur during different phases of project development. Any project-level risks involved in third-party integration can emerge later in the overall project lifecycle, for example, when development shifts to the creation and refinement of the project's API.
Yet, project managers can address risks earlier in the lifecycle when the focus is on user activities, such as identification and authentication. In other cases, risks can pertain to specific iterations depending on the nature of the project.
Iteration-level risk management
Risk management in Agile development must be iterative, just as software development is iterative. Ideally, project managers' post-iteration updates to risk assessments should focus on the issues pertaining to the upcoming iteration. This process usually involves input from developers, and the team should use its knowledge of the project roadmap and the goals of the next iteration to update the risk assessment.
Before the iteration occurs, follow the steps outlined above. Then, after the iteration occurs, monitor the response plans and review their effectiveness. If necessary, make subsequent adjustments to both the overall project plan and the upcoming iteration.
To be thorough, the team should review the results from monitoring after the iteration is complete and use that information to direct updates and changes to risk identification. The process forms a recurring loop that takes project managers and the development team through the project cycle with incremental improvements to code safety.
Vary your approach
This is just a high-level overview of the basic risk management process. There are countless possible variations that apply to Agile software development. Project managers can impose a varying degree of formality to the risk management process.
Some organizations use a point system to prioritize risks, while others use a scale system or another model. The actual processes and project or risk management tools you use will depend largely on the complexity and criticality of the software.
Also, work in the real world. While this process will ideally repeat for each iteration, it's not practical for all Agile paradigms -- particularly when new builds arrive several times each day. In these situations, project managers can break the iterative process into phases or groups of builds. With this approach, developers can keep the pipeline filled and project managers can revisit risk for sets of builds or project waypoints.
