... where "abused" appears to cover most good-faith efforts to implement Agile in practice. When it works it's Agile—despite the fact that these implementations have very little in common. When it fails the mantra is always "Agile wasn't implemented properly". Agile has every characteristic of a utopian ideal that cannot survive contact with reality, or at least the realities of safety-critical software.
Big-A Agile is often described in Utopian terms. Which is unfortunate, but little-a agile is understood to be a thing you grow towards with constant improvements and changes to both the process and the system being developed based on frequent, ideally continuous, feedback. Boeing, in my experience, didn't want to change their processes, they wanted to run the same processes faster. Which is decidedly not agile (and I hate Scrum for this).
The form that I've seen them adopt on programs I've been involved with is heavily inspired by Scrum. So they have sprints, they accept product releases from the subs and will, ostensibly, test it (running the integration lab they have the more complete test infrastructure, in theory). But, in practice, the released code isn't tested for months, but development continues, monthly or bi-weekly releases continue, and no feedback is ever provided to the developers. Finally, 6-12 months later most of the builds are discarded, the most recent one is tested, and it's discovered that, true-to-Waterfall, the wrong thing was built. Patches are quickly developed and applied, tests pass, and something is released to the customers.
Months or years later, the software is found to be defective, the test suite is found to be insufficient (again), and the process repeats.
> ... little-a agile is understood to be a thing you grow towards with constant improvements and changes to both the process and the system being developed based on frequent, ideally continuous, feedback.
Agreed, and I have no objection to the feedback and continuous improvement aspects of agile development. Or anything in the Agile Manifesto, for that matter. In my experience, however, when projects "go Agile" they tend to cargo-cult simplistic, visible changes like Scrum instead.
> Boeing, in my experience, didn't want to change their processes...
Yes, this is generally the issue. On the other hand, those processes are strongly influenced by industry standards such as DO-178 which codify "tried-and-true" practices established in the early days of software engineering—it isn't just a matter of corporate culture. It's not mandatory to follow these processes, but if you do then certification is basically assured, which is much simpler and more reliable than arguing the case for a brand-new process with no established history in the industry. For the most part these standards treat software as just another "component" to be integrated into the hardware, like an extra-complicated combinatorial circuit, rather than what it is: the design of a iterative, stateful process to be carried out by the hardware during flight. Novel development and certification processes are a huge risk; understandably, no one wants to go first, even when they agree that change is needed.
