SCRUM & Software Assurance

I'm not familiar with ED109A or ED153, but it appears that ED12C is a European standard that is otherwise identical to DO-178C. I'm not aware of all of the details of DO-178C, since it didn't exist when I was working in aerospace. However, I used to work with it's predecessor, DO-178B.

Agile methods, including Scrum, have been used in regulated contexts successfully. Although the examples are from regulated medical devices, Nancy Van Schooenderwoert and Brian Shoemaker have written about using agile methods for safety-critical systems along with some case studies. Many of the medical device standards are similar to and even reference standards in other industries, including aerospace's DO-178.

Unless things changed a lot more than I can gather, DO-178C/ED12C doesn't preclude iterative and incremental software development methodologies. It's true that agility is more than iterative and incremental development, but they are a foundational concept of the agile methods, including Scrum.

The biggest challenge is reconciling the agile values and principles with these standards. The Manifesto for Agile Software Development doesn't say "individuals and interactions without processes and tools" or "working software and no documentation". The values suggest what to favor. The processes and tools that are in place should take into account the humans doing the work. Documentation produced needs to support the working software, and the documentation is irrelevant without the software.

Without knowing specific questions about what problems you're facing, I will say that transitioning to agility in a regulated space does require the people responsible for the processes, often a quality management organization, to have an open mind. Plan-centric, documentation-heavy processes seem like an easy way to satisfy the regulations, but aren't conducive to building high-quality software in a cost-effective manner. It takes work to understand the intent of the regulations and put together a cohesive picture of how the development organization satisfies those intents. Ideally, the way the development team works (which includes the tools they use and how they use those tools) can produce records that can be used to support an explanation that would satisfy auditors and regulators.

Is it possibile to reconcile these two ways of working?
 

Ask yourself if you can afford not to. Is a complex challenge being faced, for which increments must be Done to that standard if empiricism is to be established?

If a standard doesn’t contribute to the Definition of Done for products that are used, ask why not.