Three fears about agile in the nuclear sector – and how to overcome them

Hannah Latham examines misconceptions around agile working in the safety-critical nuclear sector

I vividly remember a meeting that happened some years ago, just after I had been seconded from Rolls-Royce Digital to the Submarines business. Agile was the norm in Digital and, I explained, we would be running our projects this way. People shifted in their seats and shot each other sideways glances. Eventually someone blurted out: “Isn’t agile making everything up as you go along? Because that really isn’t going to work here.”

Three years on, we have several teams and projects working agile – proof that it does work in nuclear – and a burgeoning agile community of practice.

Below are the three main fears about agile in the nuclear sector, and how to overcome them.

Fear #1: “If we work agile there is a real risk we’ll compromise product safety”

Nuclear is one of the most safety-critical industries in the world. Failure is not an option, and the whole ethos of the industry is about providing multiple lines of defence against it. In this climate, agile methodologies that promote ‘failing fast’ and ‘continuous adaption’ can be inherently unnerving to many.

Traditional waterfall approaches feel ‘tried and tested’, and it isn’t always obvious that agile approaches could provide the same rigour. This is because agile is often perceived to be about delivering ‘pace over quality’. People recognise agile as a good fit for industries like IT that move rapidly and can tolerate emergent bugs, but it isn’t so obvious that it suits an industry where the product life cycle spans decades and requires ‘right first time’.

People will also question whether an approach that promotes ‘working solutions over comprehensive documentation’ really fits an industry that mandates high levels of regulatory documentation.

Five tips for overcoming this fear:

1. Share case studies of agile being used in safety-critical contexts elsewhere.
2. Don’t try to do your first agile projects in the most safety-critical areas – do them in research contexts, issues management contexts or in support functions.
3. Frame ‘failing fast’ as ‘getting feedback as early as possible’ and emphasise how this can increase quality and reduce waste.
4. Communicate that both waterfall and agile approaches can be rigorous: waterfall prescriptively says ‘what must be done’ while being flexible about ‘how it gets done’; agile approaches like Scrum rigorously define ‘how teams work’, allowing for more adaptability in ‘what work is done’.
5. Accept the need to do more documentation than is usually required. Add tasks to generate documentation into your backlog.

Fear #2: “If we start to embrace agile, down the road it could lead to chaos”

In the nuclear sector, agile is often set up in competition with traditional waterfall-type approaches. Agile is so often presented as ‘the new better way’ or ‘the magic answer to transforming your organisation’. Articles will list or give examples of the pros and cons of agile versus waterfall. Project managers are either ‘agile ones’, who have job titles like product manager, or ‘traditional ones’, like programme managers. You’re either for the old way or for these new ones.

This is very unhelpful in organisations that will always have to interface with very non-agile regulatory processes. It is just not possible for everything to be ‘done agile’, and this is a problem if agile and waterfall are perceived fundamentally to compete.

While leadership see that it might work out in the short term for some teams to do agile at a small scale, the more popular it gets the more there is a risk of destabilising clashes or unintended negative consequences if different parts of the organisation are working different approaches that are fundamentally at odds. This can lead to a reluctance to start down a path that could lead to conflicts no one knows how to resolve.

Four tips for overcoming this fear:

1. Demonstrate that agile and waterfall can be complementary, e.g. agile approaches could be used to deliver a milestone that is part of a larger waterfall programme.
2. Emphasise that different methods fit different types of problem, e.g. regulatory processes fit waterfall, dealing with emerging issues fits agile. It’s about choosing the right tool for the right job.
3. Take time to educate and get senior leaders on board with agile.
4. Plan for the fact that teams are going to be in what is known as a ‘scaled agile’ environment from day one – this is an ‘advanced agile practitioner’ topic, so ensuring an agile coach or someone with prior experience is there to support is key.

Fear #3: “To do agile, we need tools and software we don’t have”

Another fact of life in the nuclear industry is heavily constrained IT and rigorous data management policies. Many nuclear organisations operate on special standalone IT networks and are unable to use cloud-hosted solutions. Mobile phones, laptops and Wi-Fi are completely banned on some sites.

When people in nuclear organisations start to learn about agile, they see pretty quickly that, most of the time, groups working in this way are using ‘specialist agile software’. This often leads to the same doubt in people’s minds: we won’t be able to do agile successfully here because we don’t have the right tools.

Five tips for overcoming this fear:

1. Don’t overemphasise tools when presenting to nuclear audiences.
2. Consider running projects without any IT tools – create wall-sized Kanban boards using electrical tape and post-it notes. Put them somewhere very public.
3. Create Excel-based solutions to buy you time to bring in tools.
4. Get an on-premises version of an agile tool, e.g. Azure DevOps and Jira.
5. When you deploy tools, create lots of guidance, use case examples and grow a support network of people who can help on-board those wanting to give it a go.

Visit APM’s What is agile? resource page for more on agile working in projects.

You may also be interested in this recent blog post by Tom Eastup on the Five reasons why the nuclear sector needs to transform how it delivers projects.

Image: UVgreen/Shutterstock