Who is responsible for risk management in Agile-style deliveries?

Question

I have a lot of experience of waterfall-style deliveries (or more accurately, incremental waterfall since I don't know of anyone who still does actual rigid waterfall any more), but none whatsoever in Agile-style deliveries.

I am considering how risk management is currently done in a well-run software delivery project and trying to figure out how it would be done in an Agile-style project.

I have read the Agile manifesto.

I have read this question and its answers

The barrier I keep coming up against is that the documentation and thinking around Agile-style deliveries focuses on the actual software build and delivery process, whereas more often that not the actual software build is just a part of an overall system/software delivery, which itself encompasses many moving parts to achieve a successful outcome.

So I would typically identify and actively manage risks that are largely external to the software build process. As examples, by no means exhaustive, I might consider the following:

• How ready are the users for devoting time to UAT? Can I achieve UAT without impacting materially on users' day jobs? How can I handle the push back?
• What are the risks of not getting key technical resources (human or mechanical) by the time I need them? How can I mitigate that and/or provide contingencies?
• What are the risks that the outbound data feed/integration that we are developing will not be acceptable within the downstream systems? Are the other teams, that are responsible for the downstream systems, ready for a new data feed? Can it be incorporated into their release cycles? Will their test environments be ready and sufficiently capable?
• Etc.

In other words, as PM I consider many things that surround the software delivery that would not be handled within the actual software delivery team and it is as much a part of my responsibilities to manage these things to successful conclusion as it is to deliver successful software to the business.

So who does this kind of thinking in an Agile shop for a specific Agile-delivery project? Do they wrap an Agile software delivery with more classical project management resource in order to achieve these and other non-development goals of an overall project?

Answer 1

In my experience I have worked building software through the use of Agile Scrum teams within a larger system of systems. There have been two ways of looking at risk in this structure. From the Program level of the system of systems the managing office used a more traditional method for risk management of identifying potential issues, their impacts, and their mitigations. It was always the responsibility of the higher management to watch over these risks as they bubbled up from lower down system projects.

With the Project (the Scrum Team) we addressed risk as a part of the continuous inspect-improve process that is at the core of Scrum. This entailed the Product Owner working with the Development Team to identify and discuss components or capabilities in the product backlog that might require a spike to get a better handle on the risks involved. Sometimes this was an investigation of a potential technology to see if it would solve a specific high risk problem or it might be to do a prototype within a sprint to test the technical impediments and gauge the complexity involved in creating the capability.

By continuing communications between the developers and Product Owner, and with the inclusion of research spikes we managed to handle product specific risks. It took interaction with the corporate management structure to deal with the non-product risks such as personnel retention, training, cross training, and so on.

I know this is mostly just an experiential response, but by executing Scrum we handled most of the things that do come up as risks that have turned into issues with the formal processes we adopted. So, things like scope creep and schedule impact were either embraced or mitigated without upper management needing to watch risks that far in the weeds. This left them free to worry about keeping good people through corporate policies and compensation, and recruiting new people should the unfortunate bus come along and remove a key asset.

Answer 2

"How ready are the users for devoting time to UAT? Can I achieve UAT without impacting materially on users' day jobs? How can I handle the push back?"

One of the most important parts of an agile transformation is to get a fully commited buy-in from the business users. The concern over impact on their day jobs is often a big part of this. I have seen many solutions, such as back-filling and business users going on sabbaticals in to the Product Owner role. The key part is that this discussion is had prior to starting with agile development.

"What are the risks of not getting key technical resources (human or mechanical) by the time I need them? How can I mitigate that and/or provide contingencies?"

With Scrum and many other agile frameworks the idea is to have the delivery team contain all the people necessary to deliver the working software. The concern over the unvailability of key resources is clearly valid and agile attempts to deal with it up front by eliminating the cause of the issue.

"What are the risks that the outbound data feed/integration that we are developing will not be acceptable within the downstream systems? Are the other teams, that are responsible for the downstream systems, ready for a new data feed? Can it be incorporated into their release cycles? Will their test environments be ready and sufficiently capable?"

Typically in agile development we work on user stories (i.e. requirements) that directly deliver business value, rather than working on technical tasks that contribute to delivering business value. In other words, we aim to deliver end-to-end within the team and hence avoid as much as possible integration with systems developed outside of the team.

This is one of the reasons agile teams are product focused, rather than being technically focused. As an example of this, it would be unusual to have an agile team that looks at just one tier of a multi-tier architecture. Instead it would typically focus on all tiers and deliver a complete solution. Clearly their are challenges with this approach, particularly in large-scale product development. There has been a lot of work done (particularly recently) on the scaling of agile product teams.

Finally, there is nothing in the agile approach that says you will ignore risks. In Scrum Teams risk is often disucssed between the Product Owner, stakeholders and the delivery team. We do not typically track risks in a risk log because the focus is on discussion rather than documentation. But that does not mean risk is ignored.