Agile methods in complex Aerospace & Defence projects
By Martin Kraus //
The origin of agile methods
About 25 years ago, the hype around “lean” took of: lean management, lean production, lean etc. Nowadays, the new buzzword is “agile”. At our clients and everywhere in the industry we find change projects around agility: agile company, agile management, agile development, agile processes etc. However, the understanding of what “agile” means and what these change projects are aiming at is very vague.
Its origin, to put it that way, dates to the mid-1990s with the process model described by Jeff Sutherland and Ken Schwaber in the “Agile Manifesto”, the application of which is known as “Scrum”. It focused on software developments where both the product features and the implementation path were not fully known at project launch.
Ralph Douglas Stacey developed a criteria catalogue, later named “Stacey matrix”, to determine whether a development project or project management should be carried out using “traditional” or agile methods.
The Scrum process model itself is simple, but so rigorous that the process itself cannot be considered agile. This is often a first misconception. Furthermore, Scrum is just one of many approaches to dealing with complexity, but it cannot reduce it. In my view, it has yet to be proven that Scrum has been successfully implemented in larger, complex software projects.
Transferring agile methods into Aerospace & Defence
Increasingly, there is a trend to apply the Scrum methodology to other product development projects and project management. This makes sense if the ideas and process elements of the “Agile Manifesto” are adapted as needed. Which means, however, at least from the perspective of the “ideological forefathers”, to depart from the original Scrum concept.
Riding the hype around Scrum, many companies have even started promoting their products as being developed with agile methods. In doing so, they turn Scrum and agile methods into a quality feature which they clearly aren’t.
The Aerospace & Defence world is greatly different from the software industry (e.g. gaming, VR, app development) or consumer goods in many aspects, for example:
- Projects are larger, typically involving big teams, many people, partners and suppliers.
- Often, projects are multinational, with partner companies located in different countries and sites. This means a multitude of process worlds and – even more importantly – company cultures.
- This complexity mirrors the customer side with different or even diverging requirements regarding a product or system, and with sometimes contradicting political and economic interests (e.g. local workshare).
- Development projects are complex and usually include components which test the limits of technical feasibility.
- Development and product life cycles are much longer than in dynamic, consumer-centric industries.
- Even though more and more functionalities are realised through software, the overall performance is determined by the integration of hardware and software and the system integration on platform level.
- Complex qualification and certification requirements influence the design itself as well as all development, production and verification processes.
Nevertheless, agile methods and mindset can be applied in A&D. To which extent and for which elements of a product or system should, however, be thoroughly analysed for each individual case. Certain phases of a project are potentially better suited than others. For example, the concept or definition phases of a project are suited for the Scrum approach. As a prerequisite, however, all partners and especially the customer or customers, respectively, must agree to such a model, which requires a high degree of interaction. It can result in an unambiguous product description or a specification which is agreed by all parties.
A software architecture or specific software functions may also be developed using Scrum or a derived methodology. Nevertheless, in any case, this requires completely new SW and SW/HW architectures. “App”-like applications in a functional SW system do not only allow for agile development methods, but also for more flexible updates during the product life cycle.
Agile methods as a contradiction to other procedural models?
For many projects in our industry, the application of the so-called “V-model” is a contractual requirement. Since its introduction (by the German public procurement agency, by the way), the V-model has been well accepted and even applied outside the military sector. You can sometimes hear or read that companies are planning to replace the V-model by agile methods. This is another misconception. These two procedural models are in no way contradicting. Agile methods can be easily combined with the V-model. The advantages and the logic of the V-model should not be neglected or waived. It has also proved effective as the formal basis for qualification and certification.
A frequently cited example for the application of Scrum in recent aviation history is SAAB’s Gripen E. However, in the public domain you will only find a presentation given in cooperation with the “Scrum Institute”. Further research and own discussions with SAAB have revealed that all processes have been changed to “agile”, and that even safety critical software has been developed using Scrum. Nevertheless, delays in the Gripen programme leave at least some doubt regarding the success of the implementation.
In the A&D industry, hybrid approaches in development and project management turn out to be the best solution. When applying agile methods, one of the challenges for both management and customer is to accept that neither schedule nor budgetary planning exist at (sub-)project launch and that it is also unclear in which sequence which partial solutions and intermediate products will be ready.
Company-wide agility
Turning the attention to company level, “agilisation” must be approached in a comprehensive manner. Per se, it is not enough to insist on the engineering or production areas becoming more agile. In that overall context, all operational core and support processes must be analysed and amended.
For a bigger, or even group-wide change project following the motto „We want to be more agile!”, it is first of all necessary to clarify and harmonise the understanding of “agility” and “agile” and to fix the aim of the project in an unambiguous and understandable way. If not, the change project itself is the opposite of agile and will not have the expected impact.
The ACTRANS team is here to support you with an initial discussion and the definition of aims for an “agile” change project.
