Friday, May 7, 2010

Why isn't Risk Management included in Scrum?

There are a lot of fundamentally good ideas in Scrum, and a lot of teams seem to be having success with it, on more than trivial projects. I’m still concerned that there are some serious weaknesses in Scrum, especially “out of the box”, where Scrum leaves you to come up with your own engineering framework, asks you to come up with your own way to build good software.

I am happy to see that recent definitions (or reinterpretations) of Scrum, for example in Mike Cohn’s book Succeeding with Agile Software Development Using Scrum incorporate many of the ideas from Extreme Programming and other basic good management and engineering practices to fill in some of the gaps.

But I am not happy to see that risk management is still missing in Scrum. There is no discussion of risk management in the original definition of Scrum, or in the CSM training course (at least when I took it), the latest Scrum Guide (although with all of the political infighting in the Scrum community, I am not sure where to find the definitive definition if such a thing exists any more), not even in Mike Cohn’s new book.

I just don’t understand this.

I manage an experienced development and delivery team, and we follow an incremental, iterative development approach based on Scrum and XP. These are smart, senior people who understand what they are doing, they are talented and careful and disciplined, and we have good tools and we have a lot of controls built in to our SDLC and release processes. We work closely with our customer, we deliver software often (every 2-3 weeks to production, sometimes faster), we continuously review and learn and get better. But I still spend a lot of my time watching out for risks, trying to contain and plan for business and technical and operational risks and uncertainties.

Maybe I worry too much (some of my colleagues think so). But not worrying about the risks won’t make them go away. And neither will following Scrum by itself. As Ken Schwaber, one of the creators of Scrum, admits:
“Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices – such as risk management.”
My concern is that this should be made much more clear to people trying to follow the method. The contrast between Extreme Programming and Scrum is stark: XP confronts risk from the beginning, and the idea and importance of managing project and technical risks is carried throughout XP. Kent Beck, and later others including Martin Fowler, examine the problems of managing risk in building software, prioritizing work to take into account both business value and technical risk (dealing with the hard problems and most important features as early as possible), and outlining a set of disciplines and controls that need to be followed.

In Scrum, some management of risks is implicit, essentially burned-in to the approach of using short time-boxed sprints, regular meetings and reviews, more efficient communications, and a self-managing team working closely with the customer, inspecting and adapting to changes and new information. I definitely buy into this, and I’ve seen how much risk can be managed intrinsically by a good team following incremental, iterative development.

As I pointed out earlier, Scrum helps to minimize scope, schedule, quality, customer and personnel risks in software development through its driving principles and management practices.

But this is not enough, not even after you include good engineering practices from XP and Microsoft’s SDL and other sources. Some leaders in the Agile community have begun to recognize this, but there is an alarming lack of consensus within the community on how risks should be managed:

- by the team, intrinsically: like any other requirement or issue, members of the self-managing team will naturally recognize and take care of risks as part of their work. I’m not convinced that a development team is prepared to naturally manage risks, even an experienced team – software development is an essentially an optimistic effort, you need to believe that you can create something out of nothing, and most of the team’s attention will naturally be on what they need to do and how to best get it done rather than trying to forecast what could go wrong and how to prepare for it;

- by the team, explicitly: the team owns risk management, they are responsible for identifying and managing risks using a risk management framework (risk register, risk assessment and impact analysis, and so on);

- by the ScrumMaster, as another set of issues to consider when coaching and supporting the team, although how the ScrumMaster then ensures that risks are actually addressed is not clear, since they don’t control what work gets done and when;

- by the Product Owner: this idea has a lot of backing, supposedly because the Product Owner acting for the customer in the end understands the risk of failure to the business best. The real reason is because the team can resign themselves of the responsibility for risk management and hand it off to the customer. This makes me angry. It is unacceptable to suggest that someone representing the customer should be made responsible for assuming the risk for the project. The customer is paying your organization to do a job, and naturally expecting you as the expert to do this job professionally and competently. And yet you are asking this same customer to take responsibility for the risk that the project won’t be delivered successfully? Try selling that to any of the enterprise customers that I have worked with over the past 15 years…

Risk management for a Scrum project needs to take this into account, and take into account all of the risks and issues that are external to the project team:

- the political risks involved in the team’s relationship with the Product Owner, and the Product Owner’s position and influence within their own organization. Scrum places too much responsibility on the Product Owner and requires that this person is not only competent and committed to the project and deeply understands the needs of the business; but that they also always put the interests of the business ahead of their own, and of course this assumes that they are not in conflict with other important customer stakeholders over important issues. They also need to understand the importance of technical risk, and be willing to trade-off technical risk for business value in planning and scheduling work in the backlog. I am lucky in that I have the opportunity to work with a Product Owner who actually meets this profile. But I know how rare and precious this is;

- the political risks of managing executive sponsors and other key stakeholders within the customer and within your own organization - it's naive to think that delivering software regularly and keeping the Product Owner happy is enough to keep the support of key sponsors;

- financial and legal risks – making sure that the project satisfies the legal and business conditions of the contract, dealing with intellectual property and confidentiality issues, and financial governance;

- subcontractors and partners – making sure that they are not going to disappoint or surprise you, and that you are meeting your commitments to them;

- infrastructure, tooling, environmental factors – making sure that the team has everything that they need to get the job done properly;

- integration risks with other projects - requirements for program management, coordinating and communicating with other teams, managing interdependencies and resource conflicts, handling delays and changes between projects;

- rollout and implementation, packaging, training, marketing – managing the downstream requirements for distribution and deployment of the final product.

So don’t throw out that PMP.

It’s clear that you need real and active project management and risk management on Scrum projects, like any project: focused not so much inwards, but outwards. So much of what you read about Scrum, and Agile project management generally, is naive in that it assumes that the development work is being done in a vacuum, that there is nothing that concerns the project outside the immediate requirements of the development team. Even assuming that the team is dealing effectively with technical risks, and that other immediate delivery risks are contained by being burned-in to doing the work incrementally and following engineering best practices, you still have to monitor and manage the issues outside of the development work, the larger problems and issues that extend beyond the team and the next sprint, the issues that can make the difference between success and failure.


MyOpenDraft said...

Nice post, additionally there are some other factors which is missed in scrum, scrum or any other agile methodology is not “Final Process Model”, this means that you should adjust and scale it based on your needs, this happen when you apply continuous process improvement on daily work.

In my experience its very good to integrate some idea & techniques from Lean methodology in your scrum process model if you need it, for example in our scrum retrospective workshop we are using system dynamic diagram, 5 whys, value & waste analysis for our iteration.

Additionally you can integrate & adopt other techniques such as TQM, risk management and other tools from different methodologies.

Anonymous said...

Good read, I completely agree with your opinion on the risks external to the project team (or you might say external to the scope of SCRUM itself), especially re. the role of the Product Owner.

I am not sure if I understand you re "internal" risk management and the responsibilities of the Product Owner.

Your write "...The real reason is because the team can resign themselves of the responsibility for risk management and hand it off to the customer. This makes me angry. It is unacceptable to suggest that someone representing the customer should be made responsible for assuming the risk for the project. ...."

Why? The customer is in the end the one who wants to use the product together with *his* assets. He knows what the possible risks are, especially re. impact values. The main interface to the customer ist the PO.

The real reason is because the team can resign themselves of the responsibility for risk management and hand it off to the customer.

With the same argument a team can resign from delivering software quality and doing unit tests. But the team should be committed to delivering a high quality software. This includes mitigating or at least communicating known and found risks.

The customer is paying your organization to do a job, and naturally expecting you as the expert to do this job professionally and competently.

True, and a risk-sensitive customer might choose the implementator with the best track record in risk management (e.g. one that adheres to a secure development practise).

And yet you are asking this same customer to take responsibility for the risk that the project won’t be delivered successfully?

Well, this might be the definition of a border case of an outside risk.

In the end it all boils down to the specific situation imho. If you have a team that never developed a web application with web security in mind, you will have to put effort into it. This may get addressed fast (e.g. by a concious developer or PO, or whatever) or later (by a PenTest result, requested by the customer).

Jim Bird said...


Thank you for your recommendations for applying Lean techniques, this is something that I will continue to explore.


Thank you for your insightful comments. You raise some good points, especially about how risk should be shared between the team and the customer. I had a difficult time trying to express my point about the customer's responsibility for risk management. Let me try expressing it in a different way:

The customer is already responsible for the business risk associated with a project, the potential impact on their business strategy and operations, the vendor risk (as you pointed out) of selecting you to build the software, managing changes in their own environment and how these changes will affect the project, and so on.

So they are actively engaged and responsible in managing one side of the risk equation. Just like the development team is responsible for managing technical risks in architecture and construction and delivery. But as we have discussed here, there are other external risks that need to be managed by somebody. So we could take the approach that some of the risks are assumed by the team, and some by the customer, and share the responsibility for success.

Sharing risk management isn't easy, and I don't think it will stand up in most commercial situations. Or we can take the position that risk management is essentially the customer's responsibility.

But let's get back to the fundamentals of the transaction involved here: the customer has picked your organization and is paying you to do a job, and by doing so they are effectively laying off as much of the risk as possible to your organization. Unless there is some third party overseeing the program for both of you, someone who is getting paid to manage risk for both of you, your organization should expect to be held responsible for the success of the project. If the project fails, either you won't get paid, or your lawyers will end up fighting off your customer's lawyers in a law suit, or your professional reputation will be damaged, or there will be some other negative outcome.

Since you are going to be held responsible in the end, you should be prepared to do the work needed to ensure success.

Scrum Process said...

Thanks for sharing, I will bookmark and be back again.

Site Meter