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?
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?