There are four parts to our discussion of Agile at scale. First, we set the context by providing an answer to the question, “Why is AAS challenging?” The ten AAS primary technical best practices follow. We then briefly address how an organization can prepare for and achieve effective results from these best practices. We conclude with a listing of selected resources to help you learn more. Also, we’ve added links to various sources to help amplify a point—be mindful that such sources may occasionally include material that might differ from some of the recommendations below.
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.
I hate the idea of “Agile” software development. If you have poor management of software development you will have poor software development. There is no such thing as agile software development.
If you have poor cooking you do not call having good food agile cooking.
The problem with the government is that it is very poor in the management of software development projects.
You should start a software development project with a small number of competent software developers and a plan on the development.
You limit the risk that the project will be a failure by having developers at first work on the features that are most difficult and risky. If you can not find solutions to these features you might as well stop the project and not spend anymore money.
At the beginning of government contracts large numbers of staff are hired. Work is started on the easiest features and work is done by junior programmers and not competent software developers. There is no clear plan on the project.
Then there are the hired systems engineers who supposedly are going to define the work with large numbers of meetings with government individuals who are going to make requirements even though almost no work has been done. If SE’s were an effective method to develop software then you would start the product by only hiring SE’s.
Time to change how government does software development.