Risk refers to the factors that contribute to a project's success or failure. On agile projects, risk management doesn't have to involve formal risk documentation and meetings. Instead, risk management is built into scrum roles, artifacts, and events. In addition, consider the following agile principles that support risk management:
Standish Group's “2015 Chaos Report.”
Risk on agile projects declines as the project progresses. This image shows a comparison of risk and time between waterfall projects and agile projects.
Agile projects' declining risk model.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Working software is the primary measure of progress.
According to the Standish Group's “2015 Chaos Report,” a study of 10,000 software projects, small agile projects are 30 percent more likely to succeed than traditional projects. Medium-sized projects are four times (400 percent) more likely to succeed with an agile approach than a traditional approach, and large, complex projects are six times (600 percent) more likely to succeed with an agile approach.
Standish Group's “2015 Chaos Report.”This table shows some of the differences between risk on traditional projects and on agile projects.
| Risk Management with Traditional Approaches | Risk Dynamics with Agile Approaches |
| Large numbers of projects fail or are challenged. | Risk of catastrophic failure — spending large amounts of money with nothing to show — is almost eliminated. |
| The bigger, longer, and more complex the project, the more risky it is. Risk is highest at the end of a project. | Product value is gained immediately, rather than sinking costs into a project for months or even years with the growing chance of failure. |
| Conducting all the testing at the end of a project means that finding serious problems can put the entire project at risk. | Testing occurs while you develop. If a technical approach, a requirement, or even an entire product is not feasible, the development team discovers this in a short time, and you have more time to course correct. If correction is not possible, stakeholders spend less money on a failed project. |
| Projects are unable to accommodate new requirements mid-project without increased time and cost because extensive sunk cost exists in even the lowest-priority requirements. | Change for the benefit of the product is welcomed. Agile projects accommodate new high-priority requirements without increasing time or cost by removing a low-priority requirement of equal time and cost. |
| Traditional projects require time and cost estimates at the project start, when teams know the least about the project. Estimates are often inaccurate, creating a gap between expected and actual project schedules and budgets. | Project time and cost is estimated using the scrum team's actual performance, or velocity. You refine estimates throughout the project, because the longer you work on a project, the more you learn about the project, the requirements, and the scrum team. |
| When stakeholders don't have a unified goal, they can end up confusing the project team with conflicting information about what the product should achieve. | A single product owner is responsible for creating a vision for the product and represents the stakeholders to the project team. |
| Unresponsive or absent stakeholders can cause project delays and result in products that do not achieve the right goals. | The product owner is responsible for providing information about the product immediately. In addition, the scrum master helps remove impediments on a daily basis. |
Agile projects' declining risk model.All projects have some risk, regardless of your project approach. However, with agile project management, the days of catastrophic project failure — spending large amounts of time and money with no return on investment (ROI) — are over. The elimination of large-scale failure is the biggest difference between risk on traditional projects and on agile projects.
