Agile at Scale (AAS)

Every organization is different; judgment is required to implement these practices in a way that provides benefit to your organization. In particular, be mindful of your mission, goals, existing processes, and culture. All practices have limitations—there is no “one size fits all.” To gain the most benefit, you need to evaluate each practice for its appropriateness and decide how to adapt it, striving for an implementation in which the practices reinforce each other. Also, consider additional best practice collections (such as the one from the GAO that is referenced at the end of this article). Monitor your adoption and use of these practices and adjust as appropriate.

These practices are certainly not complete—they are a work in progress. For example, as future additions we plan to include webpages addressing management and acquisition best practices for AAS.

Why is AAS Challenging?

Agile practices, derived from a set of foundational principles, have been used for well over a decade and have enjoyed much success and broad adoption in the commercial sector with the net result that development teams have gotten better at building software. Reasons include: increased visibility into a project and the emerging product, increased empowerment of development teams, the ability for customers and end users to interact early with executable code, and the direct engagement of the customer or product owner in the project to provide a greater sense of shared responsibility.

But business and mission goals are larger than a single development team and thus applying AAS is challenging along these dimensions:

1. Team size. What happens when Agile practices are used in a 100-person (or larger) development team? What happens when the development team needs to interact with the rest of the business such as quality assurance, system integration, project management, and marketing to get input into product development and collaborate on the end-to-end delivery of the product? Scrum and Agile methods such as extreme programming (XP) are typically used by small teams of at most 7-10 people. Larger teams require orchestration of both multiple (sub)teams and cross-functional roles beyond development.

2. Complexity Large-scale systems are often large in scope in terms of the number of features, the amount of new technology being introduced, the number of independent systems being integrated, the number and types of users to be accommodated, and the number of external systems with which the system communicates. Does the system have stringent quality-of-service requirements (e.g., strict real-time, high-reliability, and security requirements)? Are there multiple external stakeholders and interfaces? Typically, such systems must go through rigorous verification and validation (V&V), which makes the frequent-deployment practices used in Agile development challenging.

3. Duration. How long will the system be in development? How long in operations and sustainment? Larger systems need to be in development and operation for a longer period of time than products to which agile development is typically applied, requiring attention to future changes, possible redesigns as well as maintaining several delivered versions. This is a focus that some Agile teams would consider antithetical to the Agile principles. Answers to these questions affect the choice of quality attributes supporting system maintenance and evolution goals that are key to system success over the long term.