Does Agile Really Work for Safety-Critical Industries?

Transitioning to Agile can be a challenge for any team. New processes and terminology can take some getting used to. But for those in a safety-critical industry, the overall benefits can seem further away.

Traceability is essential for safety-critical teams. This alone can make managers believe that Agile won’t work for their development process. However, most objections to Agile development can usually be dispelled. Here are three common concerns and how to address them.

Objections to Adopting Agile For the Safety-Critical

We Won’t Get the Documentation We Need With Agile. 
A common definition of Agile is “working software over comprehensive documentation.” And it’s understandable that this would repel anyone who needs comprehensive documentation to pass an audit.

Proving that products have been thoroughly tested, and that all known defects have been eliminated does require meticulous documentation. And it’s necessary for the production of a safe, effective product.

However, this Agile tenet doesn’t mean documentation should be eliminated. It’s driving towards the elimination of wasteful documentation. Auditors don’t want to sift through useless paperwork — why provide more work for both them and your team?

The Agile methodology aims to produce valuable reports, of which a traceability matrix would be included if it’s for a regulated industry. Therefore, it can remain a part of your Agile process.

Maintaining concise, well-organized records that ensures traceability can be a challenge when you shift to Agile. However, a product development solution can simplify this. Certain solutions also automate the process, which can both instantly generate documentation and also streamline operations.

Read how Sennheiser is successful with Agile >>

We Can’t Use Agile Because We Can’t Do Sprints 
Sprints are used in Agile as a way to support the principle that working software is the chief measure of progress. Each sprint should produce measurable outcomes with a demonstrable, working version of the product. That way, work isn’t always 80 percent done — progress can be tracked accurately.

With embedded software, however, sprints don’t always produce features that can be demonstrated or evaluated. For this reason, purely Agile methodologies are not appropriate for this development. It's a primary concern when comparing Agile vs Waterfall. 

However, the point of using Agile isn’t to strictly adhere to every bit of it. The point is to improve the product development process.  It is perfectly fine to create an Agile/Waterfall hybrid.

And companies do this with great success. For some, it means using an Agile methodology at the team level and Waterfall at the project. For others — say those developing products with both hardware and firmware — teams developing hardware might stick to Waterfall while software developers employ Agile.

We Won’t Get Buy-in for a Decrease in Productivity 
Implementing any new process requires time for people to adapt. This can temporarily create a productivity lull.  Of course, any manager or team looking into Agile is likely doing so because of productivity issues. So the idea of slowing production further can turn people off — especially if there’s fear of it affecting performance reviews.

Two things will help with this issue:

• Management’s clear acceptance.  
• A pilot program.

The entire senior management team needs to accept that productivity will slow during the transition. If productivity is already an issue, the limited velocity of the first few sprints is irrelevant. Any improvement to the old process will slow people down. Once everyone is up to speed, the changes should make up for the slack.

Once all managers buy in, their acceptance needs to be clearly and repeatedly communicated to the team. Employees will be more open to change knowing they won’t be reprimanded for subsequent productivity loss.

To help minimize the impact on productivity, Agile process development can be confined to a single pilot group. Smaller pilot groups are easier to measure, manage, and plan for. Kinks can be ironed out more quickly. And as the pilot team shows progress, it can get the rest of the company excited for the transition.

Safety-Critical Agile Process Development

Once your company is committed to Agile, the next step is to adopt it for your team. Read Transition to Agile: Safety Critical Environments to learn about Agile changes specific to the safety critical industry. These include:

• Who is responsible for verification and validation.
• Risk Management and Mitigation.
• Requirements and user stories.

Hit the Ground Running 
Want to see how much faster you can get on track with a product development solution?

Helix ALM manages tests, issues, and requirements. It can be integrated with tools you’re already using, like Jira. And it supports an Agile/Waterfall hybrid.

Transition to Agile using Helix ALM to:

• Create an instant traceability matrix.
• Keep a single source of truth.
• Automate compliance management and reporting.

Sign up for the next demo, or if you’re ready, grab a free 30-day trial of Helix ALM.

Show Me How it Works  Get Agile Traceability