Can Agile Work in a Nuclear Environment?
Silos Direct-encapsulation Plant project at Sellafield was one of the most complex, highly regulated projects in the UK. On the face of it, one would imagine completely unsuited to using Agile techniques…
Adopting an Agile approach for a project that is highly focused on the satisfaction of detailed technical requirements, which cannot be varied without the full approval of the nuclear regulator (a process that can take many months), doesn’t sound like a great idea on the face of it. However, all projects, no matter how constrained, will require innovation at some point in their delivery. If you can create the space in the traditional (Waterfall) schedule and the correct environment, Agile practices can have a dramatic impact on the direction of the project.
The Silos Direct-encapsulation Plant project at Sellafield was originally conceived as a means of treating some of the most hazardous and highly active waste on the site.
To break it down, the plant would receive a container of active waste from a silo, sort it in to different types of waste, repackage it in a new container and grout the contents in place with concrete. This whole operation had to take place remotely, since direct human access to the processing areas of the plant would be impossible.
The Silos themselves represented the second most hazardous facility in Western Europe and the design requirements were subject to a detailed safety case approved by the Office for Nuclear Regulation. Any changes that affected the safety case would require an amendment; a process that could take up to six months. In such an environment, it seems entirely appropriate for the project team to concentrate on a Waterfall solution, i.e. managing a series of sequential activities to deliver the requirements in full.
But there was a problem:
The project had suffered a number of delays and the budget had increased substantially since its original inception… over 20 years ago!
There were many scientific and safety reasons for this escalation, but there is no doubt that the necessity for the requirements to be fixed before the main contracts were placed did not help.
A traditional approach does not deal well with a project that is subject to constantly and suddenly changing requirements (bought on by changes in the scientific understanding of the hazard).
The fact that the commercial arrangements were linked to these requirements reduced the ability for the project to respond with agility to technical challenges. Once a project gets locked into a cycle of cost and schedule escalation, it is sometimes helpful to change the basis on which the planning is undertaken, introducing techniques that will change the mindset and allow new ideas to come to the fore.
Challenging the Solution
A Challenge Team was established to look at the solution again with a view to making significant cost and schedule savings, run in parallel with the delivery team to ensure there was no impact on the contract. The team looked at all aspects using the PESTLE model in the graphic below to challenge the assumptions and see where improvements could be made.
To encourage innovation, the Challenge Team was set-up in a separate environment, using different techniques from the main project team.
However, it was essential to keep key players from the main project fully engaged and bought in to the solutions proposed by the Challenge Team. To do this, the main project team sponsored the “experiment” and released key players to join the newly formed Challenge Team.
The Challenge Team ran in parallel to the Delivery Team to ensure there was no impact on the contract
The Agile Approach
So where did Agile come in? The Challenge Team organized the “experiment” to run in an Agile way. Sprints were defined to run through the key steps of developing solutions, whereby ideas generated became the basis of the Project Backlog and were then drawn down during the Sprints for evaluation and comparison against the requirements.
These ideas became features that could be implemented if the cycle time for addressing the requirements could be managed. Other Agile features of the Challenge Team included:
- A “War Room” established for the team to work in when together, housed in a different building with less stringent access requirements
- Full engagement of delivery team obtained by nominating key players as sponsors and advisors to the team, where they didn’t attend the Scrums or daily stand-up meetings, yet retained defined points where they could interact with the team throughout the life of the “experiment”.
- A Scrum board used for planning activities and tracking progress
- New features developed using agile and innovation elicitation techniques: i.e. Synergy, Generic-specific, Triz
- Features prioritised for adoption based on potential overall business benefit and then released in “waves” whereby more radical approaches were avoided in the initial phases to mitigate any severe resistance.
- Requirements elaborated using a ‘Just in Time’ model, making radical assumptions of what may be acceptable to ensure highly beneficial solutions weren’t dismissed early in the process.
- Finally, technology and governance solutions were developed in sprints as well.
MI-GSO | PCUBED’s Agile methodology includes all of these features and it is constantly being refined to ensure the latest practices are built into our “Delivery Kits”.
The Challenge experiment resulted in two options, radically different from the established design, potentially saving up to 4 years and diminishing the required budget by 50%.
Acceptance of the Approach
The Challenge Team concept was very well received by everyone involved in the project and has since been used elsewhere in the nuclear sector.
“Innovation in terms of ambition and success in changing was excellent – the Challenge Team was a great example of this”.
– Sellafield Managing Director
As important as the technical solution, was the energy and engagement of the stakeholders who found the whole approach refreshing and unique. It gave them an environment where new ideas became possible, away from the main project that was, quite rightly to ensure nuclear safety, was locked into its rigour of detailed evolution and control of requirements.
In the end a slightly more conservative option of creating a two-stream process rather than a long sequential process was adopted for further development. The simplified process design selected by the main project team was worked up into a new project plan which forecasting a 20% time saving and a 10% cost saving.
So, when returning to the question of whether Agile can work in a highly complex and highly regulated nuclear environment, the answer is yes. If this project is a candidate for Agile, maybe all projects can, and probably should, use Agile techniques. It’s just a matter of timing.
David Whitmore is the Head of MI-GSO | PCUBED’s Energy and Utilities business. He is an established nuclear engineer, project and programme manager. Whilst working for the AMA joint venture at Sellafield he set-up and led the Challenge Team that developed an alternative technical solution to the Silos Direct-encapsulation Plant project that was intended to treat waste from one of Europe’s highest hazard facilities.