Adopting Agile Practices in Large-Scale Software Engineering

Some of the “low hanging fruit”, what I will call “primitive agile genes”, are ones such as Team Dynamics, Feature-Driven, and Iterative-Incremental. These are relatively easy to implement or adopt, as most of these practices dictate the behaviour of the software development team alone, and do not require much buy-in from other stakeholders in the product development organization (e.g. system engineering, quality assurance, management, etc.) So a development team can easily adopt these primitive genes. As is often reported, these practices are well received by developers, who will swear that they are doing “Agile development”, even though from a project performance perspective, there is nothing different or agile about the cost, schedule, or quality of the software as far as the customer is concerned. Especially when practiced within a larger waterfall context, these primitive agile genes have little impact externally on the overall project behavior. In other words, Agile development can lose some of its benefits when practiced within an otherwise-waterfall program. This approach is starting to be known as “Water-Scrum-Fall” (Figure 82).

On the other hand, some of the more “advanced genes” such as Continuous Integration and Customer Involvement require much more coordination and buy-in from other stakeholders in the product development system, on a wider scale.

Continuous Integration brings with it a whole new approach and philosophy to development environments, requiring new tools, processes, and changes to existing skillsets. It is an expensive venture that may involve retraining a team that has evolved over years of waterfall development. This is a cultural change as much as a technology or methodologies change. It means, amongst other things, that development and integration work has to be highly parallelized and integrated – This is often not the case in large-scale government software where development teams “throw work over the wall” to the integration team in assembly-line fashion.

Customer Involvement would be an even bigger cultural change, for the customer as well as the contractors: the contractor will have to be open to evolving and changing requirements as the project progresses, and the customer will have to be available (preferably present) for daily scrums and regular product demos, as well as open to incremental delivery models.

Considering the spectrum of primitive-to-advanced practices in the Agile Genome, and inspired by the concept of maturity levels, we may begin formulate an “Agility Assessment Model” (AAM) as shown in Table 15, where at each level a new Agile Gene is employed as well as all the genes of the levels below. A software development organization could be rated on a scale of 1 to 7, with 7 being the most Agile.