I have been reading about Agile Development, a method designed for software development, and wondered if it is a technique that could be applied to hardware, defence hardware.
Agile Development is like many approaches to complex problems, an amalgamation of various ideas and processes developed over time. It came together in early 2001 and was defined by 12 basic principles.
- Customer satisfaction by early and continuous delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Self-organizing teams
- Regular adaptation to changing circumstance
Wikipedia has a very good overview, click here to read.
Other similar processes have evolved, Scrum and Extreme Programming for example, but they are variations on the same iterative test as you go process.
Simplistic answers to complex problems are usually illusory but would it be worthwhile to test some of the principles on a smaller defence project to see if any of the principle might deliver some benefit to the defence acquisition process.
I particularly like the principle of requirements developing over time and finding a way to manage this. If we look at FRES for example, this is exactly what happened, it is just that we didn’t manage them very well!
With defence equipment development, the user defines the requirement at the beginning of the CADMID acquisition process with the User Requirement Document. Some trade-offs do occur during the concept and assessment phases but in general, the requirements stay relatively static (stand fast CVF)
I am drawn to Textron’s approach to the development of the Scorpion combat aircraft. Textron took an idea to a flying aircraft in two years, with no external support and with its own cash, reportedly in the ‘tends of millions’ of Dollars.
Textron concentrated on getting the right people, insisting on face to face communications within a self-organising team, a couple of principles straight out of the Agile Development rule book.
At the peak, Textron only had a couple of hundred people working on the project, rapid decision making was achieved and the results speak for themselves.
For developing a DOD (Department of Defense) aircraft, it was completely radical. The traditional way a military aircraft gets developed is the DOD, or one of the services, they sit down and write out all the requirements they want. Hundreds of pages, detailed requirements. We completely threw that away because we’d still be here trading paper back and forth if that was the route we were going to take.
Textron built a set of requirements but they evolved them over the course of project and whilst much is made of the re-use of existing components the real achievement was the process.
Whether it is a success or a flop, the process used to get it flying was, and is, impressive as hell.
The Urgent Operational Requirement (UOR) could be seen as an agile process but in general, it takes MOTS or COTS equipment and doesn’t develop anything. A hybrid UOR/CADMID project was the Foxhound Light Protected Patrol Vehicle. It was bought into service very quickly but no corners were cut.
Chris Maughan, Managing Consultant at Decision Analysis Services Ltd wrote an excellent analysis of the Foxhound LPPV acquisition process for RUSI, read it here.
He makes the point that the MoD is reluctant to adopt other models apart from the UOR and CADMID process;
The MoD appears to be generally reluctant to adopt alternative acquisition techniques (such as spiral development or incremental acquisition), which have the potential to mitigate the consequences of high technical risk and requirement uncertainty.
He concludes with a damning statement;
Smart acquisition was intended to lead to improvements in new equipment delivery performance. This has not materialised, and the practical application of CADMID by the MoD has been to create an ‘industry’ of supporting processes and management information, which is, arguably, largely a product of insecurity among decision-makers and their staff. The result is to direct the focus of teams, perhaps inadvertently, towards feeding the process and not delivering the product (the equipment to be acquired).
An industry of process, insecurity among decision makers and ‘feeding the process’ are the exact opposite of what Textron achieved and Agile Development purports.
Agile may not be the answer, the Textron approach might not work for the MoD but would it be beyond the wit of man to try a few alternatives like them?