Risk management within Agile Projects

There are many reasons why companies are adopting Agile both within their IT division and for other areas of the business. One of these is the ability to “fail fast”. While it might seem counterintuitive to invest time and energy in a framework that hints of failure, in fact the ability to drop an unsuccessful initiative at an early stage limits costs and wasting of time. We all have at least one “death march” project in our experience that went on for years past the estimated completion date. Even where such a project is completed, the results are never what the customer wanted, the requirements that were originally stipulated are far removed from what is required today.

Does an Agile Project need a Formal Risk Management process?

The nature of an Agile project is geared towards managing risk; the riskiest work is tackled first, in a short and manageable work package, the Sprint. As each subsequent Sprint is tackled, the work to be completed becomes steadily less risky, and the confidence levels in the project increase. In the event that the project is not working, it can be halted at the end of the Sprint, or even in mid-Sprint, an evaluation can be performed and a decision taken whether to cancel the project or continue after applying some radical changes.

From this perspective, it can be said that risk management is inherent in every Agile project. This is why many proponents of Agile feel that adding a risk management process to the project is unnecessary, and perhaps for a simple product, perhaps it is overkill. However, where a project is complex and there is a great deal of uncertainty in the viability of the product to be developed, there is nothing to be lost in applying traditional risk management principles.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course: