Application of Agile Methodologies in Safety-Critical Systems Development

Safety-critical systems are those whose failure can result in severe harm to people, property, or the environment. As such, their development necessitates adherence to stringent engineering practices and compliance with rigorous regulatory standards, such as DO-178C (aerospace), ISO 26262 (automotive), IEC 61508 (industrial), and IEC 62304 (medical devices). These systems are predominantly found in domains such as aerospace, automotive, healthcare, and industrial automation. They typically follow structured and plan-driven development lifecycles, most often based on the V-model. Development in this context is characterized by comprehensive documentation, multiple big teams, thorough verification and validation, and extended release cycles to manage complexity and ensure safety assurance.

Meanwhile, Agile methodologies have gained widespread acceptance across many areas of software development, offering benefits such as increased adaptability, faster feedback loops, and enhanced stakeholder collaboration. This has led many organizations to investigate how Agile practices might be applied or adapted within the context of safety-critical systems, without compromising compliance or safety objectives. However, the highly regulated nature of these systems poses significant challenges to direct adoption of Agile approaches, often necessitating tailored adaptations of Agile methods.

In this blog post, I will explore the intersection of Agile practices and safety-critical system development, discussing the practical challenges, regulatory considerations, and potential benefits of integrating Agile principles in such highly constrained environments.

Why Agile in Safety-Critical Systems?

In traditional safety-critical software development, models like the Waterfall or Rational Unified Process (RUP) often involve lengthy development cycles, typically spanning 6 to 8 months. During such extended timelines, technological advancements, user expectations, or operational requirements may evolve significantly, leading to potential misalignment between the final product and current needs. This time lag can result in delivering software that no longer fully meets stakeholder expectations.

Agile methodologies, with their emphasis on iterative development, continuous integration, and early feedback, offer an attractive alternative. These practices facilitate early detection of defects, better alignment with evolving requirements, and more meaningful stakeholder engagement. These outcomes are especially valuable in safety-critical domains where late-stage changes can be both costly and risky.

Adapting Agile to Safety-Critical Development

In safety-critical software development, compliance with safety standards such as DO-178C, ISO 26262, or IEC 61508 requires rigorous documentation, traceability, formal verification, and process predictability. These elements may appear at odds with Agile’s lightweight and flexible nature. Agile teams must therefore strike a careful balance between agility and assurance. Typically, this involves maintaining a high-level understanding of long-term goals while focusing detailed planning efforts only on near-term iterations. Agile in this context does not eliminate traditional engineering rigor, but instead adapts its principles to support incremental compliance, concurrent development activities, and just-in-time decision-making, all of which can ultimately enhance both product quality and regulatory confidence.

Agile Framework for Safety-Critical Systems

In the development of safety-critical systems, a widely adopted strategy is to combine Agile methodologies with the traditional V-model framework. While the V-model provides a structured approach for system-level planning, integration, and certification, Agile enables iterative development and testing of software components. This hybrid approach is particularly effective when the necessary artifacts such as requirements traceability, test documentation, and hazard mitigation evidence are maintained to meet certification authority requirements. Research supports this fusion by proposing hybrid V-models and methods such as Agile-Planned that blend agile practices with plan-driven system engineering methods, ensuring compliance without sacrificing flexibility.

A notable example of this hybrid methodology is SafeScrum, developed by SINTEF and NTNU. SafeScrum integrates Agile software development with safety standards like IEC 61508, aiming to make iterative planning, documentation, and specification compatible with rigorous certification requirements. The key insight driving SafeScrum is that safety requirements are typically more stable and predictable than general product features. As a result, SafeScrum separates safety and functional requirements into dedicated Scrum backlogs and focuses solely on software development within the larger system engineering process. This allows teams to adopt Agile methods without compromising the stringent demands of safety-critical standards.

Figure 1: A Depiction of SafeScrum Process Model

In practice, system-level engineers responsible for end-user interaction and product integration may follow the V-model, while smaller sub-teams utilize Agile to deliver software modules incrementally. This division is especially useful when certain software components must be developed and tested early to support system-wide integration activities. In complex environments where multiple computing elements communicate over a network or shared bus, the top-level engineers often act as internal customers for Agile teams, accepting sprint deliverables and integrating them at the system level. Although final product certification is a formal, costly, and non-iterative process, Agile enables early releases of minimal viable features. These can later be expanded with additional functionality and regulatory approval in future sprints, ensuring both agility and compliance throughout the development lifecycle.

In a typical development lifecycle, the systems engineering team is responsible for initially formulating the high-level requirements. These are subsequently refined and modeled by the requirements analysis sub-team, which translates them into a high-level software architecture. Throughout this process, continuous collaboration between the systems and software teams is essential to ensure proper interpretation, negotiation, and clarification of the evolving requirements. Once the requirements and architectural design reach consensus, they are distributed across sub-teams by the requirements manager for implementation.

Each sub-team may be granted a degree of flexibility in choosing their software development methodology. For instance, while some teams may adopt a traditional Waterfall approach within a given phase, others may implement Agile practices such as Scrum. This results in a hybrid development environment where Scrum operates within the broader context of the company’s overarching project lifecycle. In this context, “Done” is not just code that works, it’s code that:

• Is reviewed and unit tested

• Has passed static analysis or formal verification

• Has traceable requirements and hazard mitigations

• Has updated safety and verification documents

Moreover, Agile roles can also evolve to support safety:

• Product Owner becomes responsible for safety-related priorities

• Scrum Master ensures compliance workflows are integrated into Agile sprints

• Safety Engineers and Quality Assurance participate in planning and reviews to ensure that critical elements are covered early

This ensures that safety artifacts are incrementally built rather than deferred to the end. As the phase concludes, various software components are consolidated into a single integrated release. This package is then handed over to the integration team, which prepares the final software delivery for submission to the project’s customer.

Figure 2: An Example Development Framework for Safety-Critical Avionics Systems Employing Agile Methodologies by Sub Teams in Overall Waterfall Model

Challenges to Address

Adopting Agile methodologies in safety-critical systems presents several challenges, stemming from both internal and external factors. Internally, teams often encounter resistance to change, particularly when trying to convince stakeholders of the advantages that Agile can offer in traditionally plan-driven environments. Externally, engaging with project customers poses another hurdle, especially when contractual agreements are structured around rigid, milestone-based deliverables.

In many cases, customers prefer contracts that align with conventional, plan-driven software development processes. For instance, such contracts may mandate the completion and approval of a comprehensive requirements specification before allowing any subsequent design or implementation activities. This expectation inherently limits the flexibility Agile methods aim to introduce.

Moreover, the regulatory landscape governing safety-critical systems further constrains the adoption of Agile practices. Regulatory standards typically prescribe a structured, documentation-intensive approach and do not allow teams the freedom to choose their own development methodology. Compliance with these standards often necessitates exhaustive documentation, thereby reinforcing the preference for traditional, sequential development processes over Agile’s iterative and incremental model.

A significant barrier to Agile adoption in safety-critical systems development is the influence of prior experience. Development teams are often deeply familiar with the traditional lifecycle models they have long followed. While the current project may involve a new product, the software development processes typically mirror those used in long-established projects within the organization. In such scenarios, adhering to familiar, low-risk strategies is seen as a prudent choice. Teams are confident in the outcomes of established processes, having witnessed their reliability and predictability over time. This familiarity fosters a strong preference for conventional methods.

One of the key concerns in adopting Agile methods solely within the software team of a safety-critical project lies in the potential for misalignment with other engineering disciplines. Software development does not occur in isolation, it requires close collaboration with systems engineering for requirements definition, and with hardware and firmware teams for integration. These interdependencies necessitate coordinated scheduling and consistent workflows across all teams involved.

Introducing Agile practices exclusively within the software domain raises the risk of disrupting this coordination. Agile teams typically operate in short, iterative sprints, while other teams may follow more traditional, sequential development timelines. This divergence in pacing and planning can lead to scheduling conflicts, miscommunication, and integration delays, ultimately compromising the coherence and efficiency of the overall project.

Furthermore, large-scale systems engineering projects often rely on substantial upfront design to synchronize the efforts of software, firmware, and hardware teams. Comprehensive requirements and design documentation are not only essential for collaboration but also serve critical roles in the safety certification process. For instance, standards such as DO-178B/C mandate the early development and approval of key artifacts like the Plan for Software Aspects of Certification (PSAC). Once approved, modifications to these documents are complex and time-consuming, requiring formal updates and re-approvals.

Thus, even when adopting Agile methods, a certain level of detailed design and documentation remains necessary to meet regulatory expectations and maintain alignment across interdisciplinary teams. The challenge lies in balancing Agile flexibility with the structured processes required in safety-critical environments.

Conclusion

Agile can absolutely be applied in safety-critical systems development, but it must be adapted and disciplined, not blindly adopted. The key is to embed safety assurance practices within Agile workflows so that each iteration contributes not only to working software but also to the growing body of compliance evidence. With the right toolchain, mindset, and safety integration, Agile enables faster feedback, higher quality, and better alignment with complex, evolving safety-critical system requirements.

Agile’s core principles, such as prioritizing individuals and interactions, working software, customer collaboration, and adaptability, align well with the need for responsive and quality-driven development even in regulated environments.