2

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?

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.

0

"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.

  • Thanks. For clarity I was not seeking answers to individual risks, they were merely examples of delivery risks that are not of the class belonging to a software delivery team. I understand that within an Agile software delivery you largely do not seek to manage these risks, but someone somewhere does have to if they are present. – Marv Mills Mar 9 '16 at 21:14
  • The answers for the individual risks was highlighting how the agile approach avoids a number of classical project risks. By getting strong engagement with the business, by focusing on end-to-end development and by having all the skills in the delivery team necessary to deliver we greatly reduce the need to worry about these kinds of risks. – Barnaby Golden Mar 9 '16 at 21:25
  • None of the approaches you documented would work in the environments I work in. It is just not possible to do those things. Therefore the risks will persist and will need to be managed. I am asking who has the responsibility for managing them. I don't believe that any delivery approach can remove the presence of risks from the delivery, particularly when the approach focuses on the development of the software and not on the myriad other things outside of the sphere of software development. – Marv Mills Mar 9 '16 at 21:31
  • @BarnabyGolden I'd say that generally speaking, a lot of those types of tasks would fall to the Scrum Master in a scrum project if they crop up as impediments, would you agree? – Cronax Mar 15 '16 at 11:15
  • @Cronax The Scrum Master is a servant leader for the Scrum Team. If the delivery team or the Product Owner asks them to mitigate risks then they certainly would do this. I would also expect a Scrum Master to ensure that Scrum is being followed so that a lot of these kinds of risks can be avoided. – Barnaby Golden Mar 15 '16 at 12:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.