Risk analysis in agile methods

December 21, 2007 by Artem Marchenko

Risk analysis in traditional software development projects is often performed for real only before getting the financing and actually starting work. After the project ends there are often the "lessons learned" sessions, which in case of a failure are called postmortems. During these pre-project and post-project risk analysis activities an attempt is being made to reduce the risks and maximize the probability of success. The recent addition to this collection of methods is the idea of a premortem that is a risks review that happens before the project start as if the projects has failed already. While all the pre- and post-project risk analysis techniques are indeed useful and can help organization to improve own practices, they only look at the potential problems at only two moments of time. Therefore there is always a danger of missing the important factors that either did not exist at the point of analysis or team members did not have enough information about those.

Agile software development methods recognize the difficulties of predicting the future challenges and complexities of both nowadays market and technologies used. Agile methods advocate reevaluating the project risks frequently, after the fixed periods of time - before every iteration start. Such a steady rhythm brings an explicit attention to the issue. What is even more important, as much as possible, the analysis results are not just the general recommendations to follow. All the agile methods explicitly recommend attacking the uncertainties and risks by constantly prioritizing the most risky elements high and exploring the most uncertain areas first. In practice it means exploring and prototyping the most ideas right after they have been identified as risky. For example, whenever scalability of the current architecture is identified as a potentially big issue, the scalability related tests, experiments and improvements are recommended to be performed before adding any more features.

What do you think? Does the agile-like reprioritization-oriented periodic risk analysis make sense and bring the tangible benefits to the company?

Permalink