The entire world is getting agile. Well, almost.
If you are a software engineer moving into a regulated industry for the first time, you've probably experienced an extreme culture shock; especially if you are an agile practitioner. Regulated environments do not seem compatible with agile principles. For example, the agile value of favoring working software over documentation is counter to the very core of a project manager in aerospace.
In my experience, most managers in my industry are aware of agile and have a certain, visceral reaction to the a-word. Kind of like a cat coughing up a hairball. They are quick to dismiss agile as a crutch for lazy software engineers that don't want to document.
What I find interesting is that they do preach and evangelize Lean as a potent philosophy. Ironically, Lean is very compatible with many tenants of agile! In fact, in the church of agility, Lean Software Development is a simply a denomination for true Lean believers. I'll be speaking about Lean Software Development in detail in later posts. Like Lean, agile is about eliminating the things that do not provide value to the customer. Waste. Muda.
Does the pilot care that you created an awesomely formatted requirements document complete with your company's proprietary legal disclaimer? No. She cares about keeping the plane in the air and that the software within the flight management system is giving her the correct information. That is both Lean and agile.
However, part of keeping the plane in the air is the rigorous certification process. As a regulated entity, certain artifacts are required by DO-178B. Therein lie the rub. In order to ensure safety in crtical systems, we need comply with regulation and audits. Therefore the documentation required for certification is not optional.
The attraction to waterfall approach in aviation is because at a program management level, we need predictable steps within a phase-gated, development lifecycle. This provides the necessary alignment with DO-178B. On the military side, the DOD-STD-2167A model provides the phases and reviews required by the government. These standards provides the mechanism for the bean counters (no offense to bean counters intended), certification bodies and management to measure progress.
How can agile possibly fit into such as rigid waterfall culture? Is it even responsible to allow agile methods like Extreme Manufacturing (XM) into an aerospace company?
The answer is of course, yes. One could ask the same question of the classic waterfall. The negative effects of the waterfall have been clearly studied and documented. DOD project failure rates have been over the 70% (Larman). I see these effect for waterfall thinking when defects are caught late in the development lifecycle or when technical debt erodes the value of a product line.
Here's the secret sauce. Our industry needs to development best practices for various types of aerospace projects. We need to map methods like Scrum into the regulatory frameworks. For example, develop practices for mapping time-boxed iterations into the SOIs (FAA stage of involvement). Determine how to document requirements and design for verification and yet translate those high and low level requirements into a product backlog for sprints and kanban.
Our industry hasn't figured this out yet. And that is the purpose of this blog. To start finding agile success stories and developing the secret sauce that can provide 2X, 10X or 100X innovation and yet ensure a level of trust that is required to keep the aircraft flying safely.
I would be interested in your stories of introducing agile into aerospace or healthcare.
Tim Wendt
