The figure below shows one potential structure of a six-month release, comprised of five sprints. Each sprint goes through the full development lifecycle to demonstrate working software at the end of each month.

The Product Owner is responsible for ensuring effective release execution. Releases must be composed in a manner that increases the likelihood that the software completed during the various spirals comes together to form a capability that cannot merely be demonstrated, but released into operations.

An Agile Analogy:

When Sherpas are guiding mountain climbers, the Sherpas are constantly collecting information about the environment, information about the abilities of the climbers, the progress they are making, and the supplies available. They use this information to identify the best climbing routes and base camps that are along the route. When this analogy is used to discuss release execution, the team is balancing all the environmental inputs to identify the best path forward while using release meetings as base camp stops to assess their goals, progress, energy levels, and commitment to the overall climb.

Some traditional work planning approaches decompose work by component, whereas release execution plans center on capability. This means that even partway through a release, programs can deliver capability instead of partially developed components. Releases are particularly useful because they require that software development sprints not only be completed, but generate operationally useful capability. Stated another way, releases are useful in measuring and ensuring delivery of operational utility to the end-user. Under the waterfall approach, requirements do not dynamically change during the development process, which increases risk of delivering obsolete technology or capabilities that no longer serve the needs of the end-user. Another benefit of releases is that they also treat integration as a continuous activity, as opposed to a big-bang integration effort at the end of the release that can be overwhelming and resource intensive.

Regular program backlog grooming is the primary mechanism to assess progress and make adjustments in response to feedback from the customers, developers, and users. This grooming activity is designed to keep development throughput at the right level, generating complementary features that can come together for the benefit of the users when the release is deployed.

Regular Grooming of the Release Backlog

• The Product Owner and stakeholders integrate feedback from early sprints, operational considerations, technical risks, and other factors to ensure user stories are clear and in priority order.
• The development team validates estimated “story points” or related measures for how much time it will take to complete each user story.
• The product owner collaborates with the scrum master and program manager to validate that sufficient time remains in the release to accomplish the items on the release backlog and adjusts the scope of work accordingly.

Regular Grooming of the Program Backlog

• The Product Owner and stakeholders focus on the high priority user stories planned for the next release(s).
• The Product Owner and scrum master ensure the stories are clear and prioritized.
• The Product Owner and stakeholders revisit priorities on a regular basis.
• The development team integrates inputs from all stakeholder groups: users, testers, engineers, architects, cybersecurity, etc.

 “The end may justify the means as long as there is something that justifies the end.” – Leon Trotsky

During development, the team may make implementation decisions to create a solution that works and meets the need in the near term, but is not the best long-term solution. Eventually, the better long-term solution will be implemented, but until that solution is developed the team accumulates what is known as “technical debt.” For example, the implementation of an older standard because the new one is not yet mature, or not yet sufficiently understood.  The technical debt is the acknowledgement that an older standard is being implemented but will need to migrate and refactor to the new standard in the foreseeable future. From a software context, the “stubbing out” of less critical features or releasing the code before it’s been fully documented is another example of technical debt.  It is important that the team, including the Product Owner, recognize when a design or implementation decision incurs technical debt. The team must choose between delivering a near-term solution at the expense of additional, redundant development to “pay back” the debt and implement the better long-term solution, as summarized in the figure below.

Technical debt should be carefully understood, tracked, and communicated to all stakeholders. It is also important to determine whether the project has accumulated “too much” technical debt and the team needs to prioritize development of the longer-term solutions over additional near-term new functionality or “band-aid” fixes.

Additional reference: Escaping the Black Hole of Technical Debt, The Agile Coach.

Technical Debt Quadrants (source: MartinFowler.com)

Configuration management activities and associated tools are critically important in a program using Agile software methods – they can make or break the success of the program. Agile methods bring added complexity, more releases, more sprints, and each sprint must be managed in a tool. Testing may be underway for a previous sprint while developers are checking in capability for the next sprint. Configuration management tracks the acceptance of user stories with their validation in sprint execution and in effect provides the vehicle for traceability of software deliveries to user needs in the product backlog. The integration of a continuous integration tool suite can help facilitate configuration management and testing with increasing automation capabilities. Configuration management also includes the tracking of associated documentation and artifacts. Making sure these are included is important as well.

Additional references:

• Configuration Management, Defense Acquisition Guide
• Configuration Management, Acquisition Community Connection

Technical data management for an Agile development involves acquiring, updating, and ensuring the integrity of any technical data needed to support the program. In a program using an Agile software approach, these tasks are also identified in user stories and prioritized during backlog grooming. Continually breaking tasks into smaller and smaller pieces is what makes Agile difficult – how small should the task be in to complete it within a sprint?

For example, on a notional acquisition program that requires weather data, user stories might include acquiring the data from a source, maintaining the data on local storage, managing updates to the data, identifying appropriate sub-sets of the data, backing up the data, etc. A heuristic for many development teams is to have tasks within a sprint achievable in a day. Many of these tasks are ongoing, so it is challenging to define the scope of work that can be reasonably accomplished in a single sprint.

Communication is the key to the success of an Agile acquisition. The team should ensure transparency up and down the chain so users know what decisions are being made and what to expect and when, and the most senior leadership knows what has been done, what will be done, and how it is working in the field.

Additional reference: Technical Data Management, Defense Acquisition Guidebook

Implementation

Implementation in an Agile environment is accomplished using frequent monthly (or bi-weekly) sprint cycles, rather than one long development period. These smaller subsets of functionality help stakeholders to see progress, and assigning responsibility for different aspects of the program to smaller teams helps move development along incrementally. One of the many benefits of implementation in shorter spurts means that if a course correction is needed, it can be made more quickly as part of the adaptive development process. As a result, the program has wasted less effort on an incorrect approach. Scrapping work done during a sprint has far less impact on the overall Agile program than it would have on a traditional program, where course correction is much more complex. Daily communication (through standup meetings) provides a routine way to identify issues very early and take corrective action as soon as an issue is identified. This communication among the team is one of the key features of the Agile approach.

Integration

Few systems exist in a vacuum. Integration necessarily broadens the number of stakeholders involved, thereby increasing complexity. Integration involves incorporating sprint releases into current fielded software, related software in development, and perhaps large enterprises. The government program office, the development contractor, the user community, and testers must manage this carefully.

Systems engineers have increased responsibility in an Agile environment and are the key linchpins to successful integration. Systems engineers need to know the integration status and the timing of the sprints’ integration with other system pieces.

See Scaling Agile for additional information on integration.

Agile brings differences when it comes to the documentation strategy for testing as well as the overall project. Agile test documentation should be built upon the agile principles which promote a feeling of collective responsibility, continuous improvement and focus on end product. From and Agile viewpoint, traditional test documentation can be considered very heavy-handed, difficult to maintain, and often unused. Since Agile projects are iterative and incremented in sprints, the requirements are much smaller in scope which permits a “lighter” approach to test documentation. This lighter approach starts at the beginning with an overarching plan or strategy for releases which lays out the general approach to testing for the solution. This strategy can often be a page or two at most. The strategy should be a consensus by the entire team as the approach that would provide the highest degree of product quality. Test plans for sprints and releases reflect the high level strategy that has been approved and focus on the requirements planned for the specific sprint/ release. Again, a light approach to the plan is expected with a clear focus on documenting only what is needed for the team to execute the plan. The large volume of text that are included in traditional plans- such as back ground- are omitted with a focus on testing types/ approaches, schedule and traceability to the sprints/releases user stories/ requirements. Typical planning documents commonly used in agile projects include:

• Testing strategies describing how the product is usually tested
• Test plans for each sprint
• Test specifications / inventories containing test cases
• Test ideas for exploratory test and logs which note outcomes
• Checklists for routine testing areas

Since Agile testing has a high degree of automation, particularly at the component and unit level, a significant portion of traditional test documentation should be in a tool.

In a traditional development program, we commit to a set of requirements prior to beginning development. The basic “promise” of a program office is to deliver a product that satisfies the requirements. A fundamental concept of Agile development includes the principle of continual requirements refinement with specifications being produced during the sprint design period. This calls for the program office to attempt to hold the initial requirements at the highest level of abstraction as acceptable, and then perform some traceability to verify the requirements, targeting a specific spiral and release. This hybridized approach is necessary in many programs.

See also Digital Services Playbook: Automate testing and deployments