People accustomed to traditional project management often want to know how Scrum deals with “risk management.” An example of how many project managers think about risk management is on this page (highlighted in red even):
It is much better to reduce the risks at the start up phase of the project than to allow a contingency on a basis that things are bound to go wrong, but we don’t know what!
That thinking is probably useful for traditional projects with known requirements and established technologies. Here’s the bad news: When we’re doing new product development (somewhat unknown requirements, somewhat unknown technologies), things are bound to go wrong, and we don’t know what!
Depending what your risks are, doing Scrum well may help. Let’s enumerate some typical risks:
- Due to technology risk, we may not be able to build the product at all. We are anxious because previously we haven’t detected problems until late in the game, during integration, QA, or even after delivery.Frederick Brooks has written about this also: Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. Bad news, late and without warning, is unsettling to customers and to managers. Furthermore, delay at this point has unusually severe financial, as well as psychological, repercussions. The project is fully staffed, and cost-per-day is maximum. More seriously, the software is to support other business effort (shipping of computers, operation of new facilities, etc.) and the secondary costs of delaying these are very high, for it is almost time for software shipment. Indeed, these secondary costs may far outweigh all others.Scrum asks us to take risks early and often. Building a potentially-shippable product increment every Sprint requires doing the risk-exposing activities of integration and test earlier than we’d do in waterfall. If you’re concerned about technology risk, negotiate a definition of “done” that includes system testing every Sprint. During the Sprint Review Meeting, any committed item that hasn’t been system tested isn’t done, goes back into the Product Backlog, and doesn’t count toward velocity. Sometimes we use Scrum to discover early that the project isn’t viable at all. Fail Fast is seen as a good thing in these cases. By the way, if you find yourself obsessing with technology risk, consider Gerald M. Weinberg‘s Second Law of Consulting: No matter how it looks at first, it’s always a people problem.
- We may not be able to build the whole product on time/budget. Most software projects run late and beyond their budgets. Indeed, most do. Scrum can’t change the underlying fact that new product development involves unknowns. I encourage you to do Scrum well, with a robust definition of “done” (including functional testing, etc.) that takes you all the way to potentially-shippable product increment every Sprint. Stay within one Sprint of being able to get your product out the door at any given time. With a constrained date/budget, you won’t get everything you originally planned, but prioritizing (and reprioritizing) helps you get the most important stuff first. This may not be so bad when you consider most features of most products aren’t used very often.
- We might spend a lot of time and money building the wrong product. You probably will start out with the wrong requirements. Get your stakeholders (including end users) to your Sprint Review Meetings to detect and remedy this early and often.
- Our people may not have the skills/training/experience to build the product. They probably don’t, at least not individually. I often tell the story of a trip to California to help a Scrum team with some technical challenges. After observing them for some time, I realized collectively they had all the pieces of the puzzle, but due to bad ScrumMastering there was no collaboration or self organization taking place. This is one area a skilled facilitator can make a big difference. We have also worked with teams in bureaucratic organizations with low salaries and inability to fire people. When we got them to do Scrum, some people feared the increased visibility would reveal their lack of skills, and flew the coop. Others were quickly revealed as constant drag on team performance, and reassigned to places they could do the least damage. Scrum doesn’t solve these problems, but you can surface them sooner by doing Scrum well.
The motivation to do traditional risk management is largely a byproduct of waterfall development. Which sounds riskier to you: a timeboxed, empirical, “inspect and adapt” approach with built in reality checks (such as Scrum), or going over a waterfall?
Software Process Mentor
Download the PDF version: Scrum and Risk Management blog