Applying Scrum to the Army - A Case Study

Agile methods are now a mainstream production process and its proponents are no longer considered hackers or cowboy coders. Still, in embedded and safety critical domains there is somehow the expectation that the approach be “more” plan-based; at least, many of the current normatives seem to lean toward such approach. A definite change in attitude has emerged with the latest DoD standards in the United States; in Italy, this change has been introduced through a new initiative taken at the 4th Logistic Division of the General Staffs of the Italian Army. This paper reports on this new initiative.Given the recent budget cuts and the concurrent but opposite need to develop a new software system, the General Staff of the Italian Army has decided to partially internalize its software development, asking their contractors to build a mix of military-civilian development teams, composed of around 6-10 developers, and to organize the overall development using an adaptation of Scrum. To this end, the two top officers of the Division have received the appropriate training to become Certified Scrum Product Owners. The project started with one team and, after about one year of operation, has grown to about seven teams, partially geographically distributed. The teams feature approximately one third of military people and two thirds of civilian developers, mostly with an education equivalent to an MSc in Computer Science, Computer Engineering, or closely related area. Data about the production process has been collected following a non-invasive approach. The results have been impressive and reassuring on the approach, even if criticality has emerged with respect to a natural resistance toward change and the need of support at the highest possible level to ensure the perdurance of the selected process.The defense software development process is a highly complex endeavor because it has to deal with a complex domain, it has to provide a very high quality solution and it has to satisfy very specific and complex needs. Command and Control software in particular must meet functional requirements that are often extremely detailed as the situations that create them involve a large number of assets and human resources that have to be coordinated in a way that minimizes losses, as any trade-offs may result in the loss of lives.Additionally, defense operations are conducted in conformance with a specific set of strategic rules called “doctrine,” and are further specified in very minute detail in a set of operational manuals that are meant to create familiarity in a series of tasks that have to be executed in difficult situations, e.g., under strict time constraint or in the presence of unknown threats.At the same time, considerable freedom must exist to choose the most favorable course of action, given that the situation evolves continuously and often in unpredictable ways. In a command and control system, for example, the leader in charge of the operations must be able to decide the courses of action for any units under his or her control; and these actions must be communicated rapidly and reliably to any and all such units. The feedback loop is also crucial to understand how the situation evolves in the field.Given the environment in which defense software needs to operate, it is not surprising that until recently, most of the software development process was plan-based: that is, processes that would ensure a high repeatability and predictability. In fact, process standards have been developed by defense agencies and armed forces to prescribe a series of features that every defense software development effort should possess (Benedicenti et al., 1999).In recent years, however, a number of factors have come to disrupt this plan-based software development process culture inside defense, the most disruptive of which has been the change in the very nature of defense efforts. Whereas traditional conflicts have involved symmetrical opponents, and most doctrines have made that assumption at their very core, recent events prove that more and more conflicts involve asymmetric opponents.Evident examples of this change are the fight against terrorism and organized crime. In these situations, a large and highly structured force is poised against a smaller but nimbler contingent. The two opponents often have profoundly different value systems and cultures, which makes very difficult to construct effective strategies without incurring in uncomfortably high risks.This rapid change introduced by asymmetrical opponents has a profound impact on the software development effort. Whereas in the past requirements were very detailed and complex but relatively fixed, recent requirements have become more volatile although they remain equally detailed. This dichotomy cannot be addressed using a standard plan-based development process (Boehm and Turner, 2003).Another disruptive factor is the cost of software development. While the complexity and volatility of requirements increases, the cost of developing a system also increases accordingly. In our experience with the Italian Army, the cost traditional defense software development has risen to approximately 130 Euro per line of code. In of itself, the rising cost of development would not be disruptive, but when it is associated with a considerable reduction in the defense budget and the need for frequent requirement changes, it becomes such (Martinelli 2015).To address the problem described above, we hypothesized that agile development can be an adequate approach for developing software in the defense sector even for mission critical applications. To this end, it is worth recalling how some of the tenets of agile can be structured in the production of software for defense (Cotugno 2015; Messina 2015), in particular with respect to the following aspects:•Frequent releases•Change management•Effective cooperation in a complex environment between requirements owners (goal owners), acquisition owners (gold owners), and contractors, who are numerous in the defence sector and do not traditionally interact easily with one another•Focus on small and empowered teams, to be able to react fast to evolving customer needs and emergency situations, a mentioned in the previous sectionImplementing a Scrum derived agile software development cycle in the Italian Army has required a great effort both for the technical and cultural change. This effort can be summarized by the four “pillars” of effort. The second “pillar” is the most critical since no specific innovative tools are available and the current implementation of the development environment are based on the adaptation of “traditional” software tools and experimental products.The first “pillar” was needed to instill the initial knowledge within the organization. The third “pillar” was necessary to create a user community governance structure which could authorize selected experts to act as delegated “Product Owners” with the same decision power as their heads. This step also required the involvement of the top level authority in the Army. The other pillars have been developed in parallel and are still under construction. It was necessary to create a brand new training process capable of generating agile agents able to act as Product Owners and Scrum Masters in the mission-critical software arena. Probably the most critical “pillar” to build was, and still for the most part is, the innovative CASE tool suite to support and assist software development. To this end traditional tools have been adapted and some new ones have been generated. The criticality is the non-invasive nature of the tools. If the programmers’ time has to be allocated to feed the support environment, the effectiveness of the production cycle decreases. Last but not least a doctrine had to be developed to ensure that any replica of the process throughout the military environment be coherent with the “Italian Army Agile” methodology.The agile approach adopted in this project is based on Scrum. The defense environment, however, required a few changes to make this approach effective. The first step was to obtain a Scrum Alliance certification for key project members. This was achieved relatively painlessly; but creating an agile culture in a plan-based environment required a serious change management effort, as previously discussed. By taking advantage of the pre-existing hierarchical structure of the Italian Army to instill a sense of need, we created the motivation to adopt the new agile method. We then closed the virtuous loop through the standard mechanisms of Scrum enabled through the four pillars mentioned above. As the first few sprints proved the incremental nature of Scrum, delivering increasingly more functional prototypes, the team’s level of confidence in the process grew accordingly.Even though Agile Methods have been discussed for, at least, the last 15 years, there are no conclusive studies on their effect or on the effect of some of their practices. An earlier study of some of the authors of this paper (di Bella et al., 2013) focusing on Pair Programming reported that from 1998 to 2011 there were 30 comprehensive studies, and among these studies there there is a tendency to show that Pair Programming has positive effects on quality, albeit with major concerns. However, there is no convincing statement on the effects of Pair Programming on productivity.Since then a few additional works have appeared but they have not clarified such relations. In particular, the meta-analytical study of Rafique and Mišić (2013), has shown the lack of evidence (or even the presence of counter evidence) of the positive effects of test-driven development (another agile practice) on productivity, especially in industrial settings. Moreover, apart from the aforementioned study by di Bella et al. (2013), most works relate either to academic settings or to small experimentations.The novelty of this paper therefore lies on:• the military domain of the study, which is substantially completely unexplored in other studies,•the very large size of the experimentation - 17 months for a growing team of up to 7 teams,•the fact that productivity is fully considered as part of the analysis and that there is clear evidence of the (positive) effect of the adopted agile methodology on productivity.Under each of these three perspectives the results of the poster are innovative and unique.After slightly more than a year in the process, the timeframe described in this paper, the Italian Army has 7 Agile Teams in place and working. The full Scrum of Scrums complex production line is active and synchronized. The teams are turning on progressively taking charge of the full architecture of an overarching strategic Command and Control tool that implements full spectrum of the decision support activity, stretching from the facilities management to the operational Field Application Services (FAS). The project is still evolving past its initial release and has now stabilized on a 5-week sprint delivery cycle.In addition, major benefits were found in the dramatic increase of customer satisfaction which was driven by the incorporation of final user experts into the development teams. Although it is very difficult to run an effective comparison with former projects it is safe enough to say that the current level of satisfaction of the operational user of the C2 system developed is higher than 90% since none of the sprint deliveries failed to receive the approval from final users.