The innovations to the 737 to accommodate new more efficient engines remind me of modern Agile practice.

Roughly, Agile practices consists of rapid software development through quick “sprints” each producing a minimum viable product that users (early adopters) can test out immediately.   The process accepted feature requests from stakeholders who needed to be satisfied with the product at the end of the sprint, where that satisfaction equated to a minimum viable product.

This approach to software was more successful compared to the earlier requirements-based development processes.   One of the reasons for the success was that the quick sprints allowed bad ideas to fail quickly, thus avoiding the lost investment in a more fully defined product that ultimately fails.

Initially, failure or success came out of the initial adoption of this approach in the Internet- or web-based applications geared primarily to consumers, either through direct retail or though selling of advertising through increased unique views.   Failure or success was from perspective of marketing or sales.  The stakeholders were investors seeking a return in investment.  Although consumers were involved in the process, they were not exposed to much risk outside of losing confidence in a particular company.

I watched more or less as a bystander the induction and evolution of agile practices involving quick iterations toward minimum viable products intended to fail quickly.   I recall being impressed at how quickly this practice became considered for more substantial projects, where the consequences of failure involved more distant stakeholders than the ones present during sprint reviews.     Experimentation showed that the process was applicable in areas far outside merely web-based software or even outside of software at all.

I was brought up in the requirements-first approach, often referred to as a waterfall model involving a large up-front investment in research and modeling of concepts before proceeding to throw-away prototypes and redesigns eventually leading to a production version available to the customers.   I experienced the frustrations of the failures of that process being blamed on inadequate research and modeling: those involved in that stage were ignorant of some requirement that was learned much later in the process.    I liked the idea of rapid deployment of some minimum viable product, far less than what is desired, but functional enough to get feedback from the intended end-users.

I continued to prefer the waterfall approach, as I hoped we could be smart and diligent enough to design something right the first time.  I still prefer that approach in theory even though I recognize the difficulty of achieving it in practice.   For large systems I have been involved in, there are multiple large teams involved.  Each team had many members of varying degrees of skill, expertise, and attitudes toward diligent.  It is difficult to get a team to cover their requirements.  For large projects there are lots of teams each with different areas of expertise appropriate for their goals.   It is even more difficult to get all of the teams to fully cooperate to converge to a complete set of requirements to provide the designers to implement.   The waterfall model recognized this with feedback loops: for example, designers would send their objections back to the research group for further review or refinement.

The waterfall model works particular well in very mature industries that have access to extensive experience from widespread deployment of earlier products used continuously in a nearly exhaustive set of circumstances.   Within such industries, the research and development teams have access to that experience, enabling them to competently define requirements even for major innovations.

One such example industry is the aviation industry.   Through its history of daily operations through nearly every possible scenario, it has the experience to prepare requirements for a new design.   The waterfall approach in this industry is very likely to succeed even for a completely new design.   Even with this confidence, the waterfall approach is a slow process and it likely produces an completely new product that would need to be adopted by the customer airlines and their pilots.

For the 737 Max, Boeing faced a need to adopt a new generation of engines that gained fuel efficiency through a larger diameter engine.  An appropriate waterfall approach would result in a new design that would require a long time and a lot of investment to complete.   Had this significant of a change in engine design been introduced a couple decades earlier, I have no doubt that there would not have been any hesitation to design an entirely new aircraft to take advantage of the new engine.   It appears that Airbus did just that, presenting Boeing with the competitive pressure to introduce their version.

Instead, Boeing chose to incorporate the engine onto an existing aircraft with extensive history of safe operation.  That aircraft, the 737, was designed for smaller-sized engines and as a result required a new engine placement design to provide adequate clearances for to accommodate the extensive experience of the various conditions encountered during takeoffs and landings.   During certification of this new design, new problems were discovered that Boeing chose to solve with a software-based solution they described as MCAS.

From my casual observation, this appears more like an agile approach than a waterfall approach.  As already mentioned, the waterfall approach to introduce a radically new engine design would be to design an entirely new aircraft around that design.   Instead, Boeing chose to add the engine to an existing design, making the minimal changes needed to get it to work.   That early prototype (without MCAS) was a minimum viable product: the aircraft with the new engine was available for test flights.   Those test flights exposed a new burden on pilots that at a minimum would have required new pilot training (a cost the customers needed to avoid), but may also have required additional mental and reflex skills that could have disqualified many existing 737 pilots.

The introduction of MCAS the newfound problem is quintessentially an agile approach.  It was introduced in a sprint-like fashion to spiral-out a existing design with a new feature to produce another minimum viable product, one that would be acceptable to the existing customers and their pilots.

I recognize that such last-minute design changes also occur in the waterfall approach.   After the extensive investment to get to a final product, any last minute problems need quick modifications.   Both the waterfall approach and the agile approach could have resulted in the introduction of the MCAS.   The difference, instead, is in the paradigm shift of the engineering involved.

The agile approach has a defining characteristic of the desire to fail quickly.   It gets some new idea implemented in order to get that experience as to whether the idea would fail.  Intuitively, it makes sense that the fastest way to prove something won’t work is to observe its failure in a finished product.  It just happens that in this case the failure involves terrorizing some test pilots, and later crashes with aircraft filled with unsuspecting passengers.

The waterfall approach would have strove to find these failures through research that subject prototype models through simulations of exhaustive known conditions from past experiences.   That approach would have taken a very long time, and cost a lot of money.  The result would have been a more costly aircraft and a delayed market entry that very likely would have resulted in a failure to deliver a profitable product.

Another differentiation between agile and waterfall approaches is the concept of early adopters.   In agile approach, the early adopters volunteer to try out the product and in the process implicitly accept that the product may fail.   The agile process strives to fail fast, and the adopters accept the fact that may fail or may even strive to find a way to make it fail.  Such early adopters are necessary to provide the evidence of failures needed to inform priorities to address in future sprints.   Early adopters in agile practice are similar to requirements testers in waterfall approach, but are very different in that the requirements testers follow specific test plans while earlier adopters apply the product in real applications with the hope that the product would give them a competitive advantage.   Early adopters hope that the product won’t fail even as they know it likely will.

I suspect the agile paradigm has taken over the aircraft industry, or at least in Boeing and the FAA.   The MCAS was a sprint for the 737 Max, and the 737 Max was a sprint to incorporate the new engine.    There was a lot of engineering and testing in these sprints: these sprints took a long time.   However, the fundamental thinking changed from a requirements-first approach to an agile approach that seeks to fail quickly.

For the 737 Max, the sprint approach successfully failed quickly for at least two sprints: one without MCAS and the other with it.

Currently there is a lot of attention of all aspects of this particular aircraft, ranging from the particulars of the design, to the larger issues of the independence and authority of the FAA with respect to approving Boeing products.   I have not seen much attention specifically addressing the role of the need for speedy introduction of new innovations into the market.   In this case, it was the need to take advantage of the more efficient engine that improves profitability of airlines while also delivering on the larger societal goal of reduced carbon emissions.    Presuming that there is a priority to reduce carbon emissions to address concerns about global climate change, there is a need for fast-to-market approaches.    Agile concepts deliver that speed at the expense of the change of perspective: agile concepts accepts that failure is unavoidable and perhaps even necessary to get the final satisfying product.

Given aerospace engineering conservative nature of respecting past practices, I doubt there was a deliberate choice to adopt agile practices.   Instead, I think the concepts have crept in through new ideas absorbed through the greater reliance on software for solving aeronautic problems, and those software engineers having at least a familiarity with agile approaches.

Acknowledging the presence within the industry of agile approaches of sprints producing minimum viable product, opens up a larger discussion as to whether we have a choice to avoid agile approach.   The agile approach delivers solutions faster than the waterfall approach.  It is faster to modify an existing aircraft to accept a new engine than it is to design a new aircraft around the engine (as would have occurred in the past).   This approach is also faster to adopt especially if it can avoid pilot retraining.

There is a gamble inherent in agile practices.   The pay off is the rapid introduction of a product to the market for a beneficial innovation.   The early adopters of agile products illustrate this gamble: the adopters will apply the new product in their businesses, hoping to reap the benefit of their early access to the innovation while accepting the risk of personal loss resulting from a likely failure.

The concept of early adopters implies that they are different from the wider market that does not want to take the risk.   The early adopters of agile products are a small subset of the total market.  The vast majority of the market waits for the multiple iterations to reach a generally mature product.

When applied to larger systems such as new aircraft, the witting early adopters are the airlines.   The information about the new aircraft may have underestimated the risks, but the airlines made the choice to accept the new airline for its efficiency benefits, and this at least implicitly accepts the inherent risk of trying something new.    However, the early adopters also includes the airline crews and the passengers who almost certainly were not aware of the choice.

In an agile model, the early adopters are part of the stakeholders in the sprint processes.  Additional entities such as airline crews and passengers are also stakeholders but they lack direct participation in the sprint process of identifying priorities or accepting the viability of the product.   In the past, they had some representation through the government entities such as the FAA and other aviation authorities.   These authorities have been part of the industry for a long time, but they may not have been keeping up with the demands of the faster pace of innovations, and particular of the changes brought about by agile thinking.

The airline crews and passengers rely on these outside authorities to represent their stakes in the new products.   The problem is that these outside authorities may not be keeping up with the new developments.   For example, there are claims that the FAA lacks the resources to perform the level of oversight they once did and that they are deferring more of this oversight to the company itself.   This deferral assumes that the manufacturer is continuing to follow established practices.   When agile practices start to replace the older established practices (and this may have happened as a natural change-over of the practitioners), the new processes leave out the stakeholders of airline crews and passengers.

Agile practices deliver new innovations that deliver new benefits along with the risk (if not expectation) of failing quickly.   The early adopters voluntarily accept the risk of the failures in order to enjoy the potential benefits.   The problem with applying agile practices to large systems is that the early adopters get expanded to a larger population who did not volunteer for the risk of failure.

I think this is something we may have to accept going forward.   When we look at future priorities such as global warming, the debt crisis, or large scale population migrations, we do not have the prior knowledge to follow the waterfall approach of carefully researching requirements for a working solution.   Even if we did have that intelligence, we may not have the time to follow that approach.   To the extent that we need solutions, the better approach may be of the agile approach with its rapid delivery of a minimum viable product that comes with the implicit expectation of failing in order to do so quickly.   For such large systems, the early adopters are the entire population, whether they volunteer or not.

We may be facing a choice of accepting some solution that could save us from some future catastrophe but that solution may risk some nearer term tragedy.   From this perspective, the 737 Max with MCAS situation is an example of the trolley dilemma, a solution for smaller carbon emissions to help save us from global warming catastrophe requires iterations of minimum viable products for early adopters to quickly find the failures.