The PMO prepares the strategy during the MSA Phase, with greater definition required before the program can proceed into the Technology Maturation and Risk Reduction (TMRR) phase. The strategy outlines the capabilities required, the acquisition approach, program schedules, tailoring, risk management, business/contracting strategy, sustainment strategy, cost estimates, funding, organizational structure and manning, and other statutory and regulatory required information.

“A successful Acquisition Strategy becomes a story about the program—its people, goals, and pathways. Like a good story, it needs to be centered on a common theme that holds it together. The best way to make this theme consistent is to recognize that while it takes a team to write the Acquisition Strategy, in the end, the PM is the story teller; the better the strategy tells the story, the easier it is understood.” – John Mueller

One of the core tenets of Agile software development is the prioritization of working software over comprehensive documentation. While policy and law require an extensive amount of information from DoD acquisition programs, DoD also has generated ample guidance to tailor the documentation to the aspects of the program. Most laws dictate the information required at a high level, while policies, guides, and templates offer varying levels of detail about information required. Defense acquisition executives continue to work with Congress and across DoD to remove low-value documentation and streamline or tailor documentation processes wherever possible.

At this stage, the acquisition strategy focuses primarily on the notional program structure and schedule, requirements management, core systems engineering processes, and ways to build a more mature technical baseline, prototype capabilities, develop a preliminary and affordable design, and foster competition. The strategy should integrate Agile tenets and methodologies as outlined in this model to include how functional processes are tailored to support smaller, frequent releases; an integrated, empowered government-contractor Agile team and culture; and how the program plans to regularly deliver capabilities to the users and react to changes.

Programs can structure their documents in various ways and should discuss their proposed approach early in the process with their chain of command. The size, complexity, urgency of need, ACAT level, and MDA will be key factors in shaping the document structure. Listed below are three approaches.

• Few major documents – Merge most information required into 3–5 major documents (e.g., acquisition and sustainment strategy, cost estimate/analysis, systems engineering and test). This approach limits the amount of documentation coordination needed and can help set expectations for a constrained amount of content. As the amount of information increases, so does the amount of coordination and number of oversight organizations.
• More, smaller documents – Structure information via standard acquisition document templates, each with its established reviewers. This requires coordination of more documents but avoids approval delays that could result if one flawed document prevents approval of significant unrelated documents. The documents can then be built out in further details for subsequent milestones.
• Capstone documents with annexes – Develop capstone documents for the acquisition, systems engineering, and test strategies at an overarching program or portfolio level to enable smaller scoped releases to navigate the process quickly. Once a program begins development, each release could include a small plan and/or annexes to a few key documents to outline the details of the constrained scope or deviations from the capstone document. The program should request the MDA delegate approval of the small annexes for releases to subordinate executives/managers.

In an Agile environment, planning is a continual process throughout the program’s lifecycle with increasing resolution and confidence with the near-term events laid out in more detail. The details of each release and sprint are outlined during the planning phase of each. At regular intervals, the Agile team reflects on its strategies and methods and adjusts them to be more effective. Given the difficulty of capturing all program requirements that might emerge in the future, the PMO faces a challenge in documenting all the acquisition, systems engineering, test, and sustainment strategies in comprehensive documents before development has begun. The Agile culture and environment recognize this; they place emphasis on the details necessary to complete the immediate next steps and accept lower resolution in planning for future activity.

Testing on a project using Agile differs from testing in a traditional acquisition. Rather than constitute a discrete phase at the end of the product life cycle, it is continuous and integral to an Agile approach. Key differences that are critical to success include:

• Agile teams test continuously. In an iterative, incremental development environment, continuous testing is the only way to ensure that new features are integrated and complete.
• Testers are embedded into the development team so that the development team is coding and testing on regular cycles. Testing becomes a foundation for the development process.
• Automation is a critical feature for Agile development teams. Because of the short cycles/ sprints, the ability to automate test execution becomes critical. Successful Agile development is not feasible without automated testing. Requiring code test automation as features are developed influences the design and architecture of the code so that it is easier to test.
• Test documentation as well as project documentation are kept to a minimum. This avoids the time and effort involved in creating large numbers of deliverable documents that are not needed or relevant.
• The iterative and incremental nature of Agile requires quick feedback from testing. There are a wide variety of test and other feedback automation technologies currently available to include unit, acceptance, security, quality, performance, and load. It is critical to ensure that teams have skillsets in diverse automated testing/feedback mechanisms.
• Agile testing is cumulative. For example, as new code is tested, it must also pass all the previous tests. This reduces re-work in the future.
• Collaboration between developers and the Product Owner is a key ingredient for successful Agile testing. Test teams must pair with developers to automate and execute tests and work with the Product Owner to define quality expectations.

See also Digital Services Playbook: Automate testing and deployments