5.6 Application of Life Cycle Processes to Agile Evolutionary and Iterative Life Cycle Models

A PEO BES PMOs Program Manager selects a system life cycle model (see the BES BPD Document N0. SWGD041 - System Development Life Cycle Methodologies Guide, 13 September 2017) based on the nature of the program and application, the methods and tools to be used, and the required controls and deliverable artifacts. The selected life cycle methodology is coordinated with the customer, stakeholders and senior management and is reflected in the acquisition PWS. PEO BES PMO organizations that adopt agile methods use the BPD Tailoring Worksheet (see Appendix A - Tailoring Worksheet for AAM Projects Template) to tailor the application of the life cycle processes identified in Figure 5-1, including organizational, technical management, and technical processes. An example of a BPD Tailoring Worksheet Checklist for life cycle processes is provided in Appendix A. The sequence of the lifecycle processes is determined by project objectives and by selection of the Agile Framework (i.e. SAFe) and life cycle model (Scrum, Kanban, XP). An agile project, because it transforms or combines activities while creating or improving working software, will find it more appropriate to claim full conformance of the life cycle processes to outcomes rather than activities and tasks. Full conformance to outcomes is achieved by demonstrating that all of the outcomes of the declared set of IEEE 12207 life cycle processes in the PWS have been achieved.

In AAM agile projects, the SAFe life cycle stages of concept exploration, development, construction, testing, transition, and retirement of legacy software can be performed concurrently for successive iterations. Agile projects perform re-planning concurrently with the activities mentioned above. During the Product Planning and Features Mapping in a Sprint 0 (see Figure 5-2), the product owner and stakeholders engage in release planning sessions to prioritize the Epics, Features and User Story items in the product backlog assigned to an AAM release. Then at the beginning of each sprint, the Development Team works with the Product Owner to refine User Stories, estimate their size, break them out into Tasks, and prioritize the Sprint Backlog. In Agile methods, re-planning is performed in release planning and sprint planning points between designated iterations (e.g., sprints or pre‐defined time‐boxed cadences) so that each of these iterations can be treated as a stage.

Besides applying a highly iterative and evolutionary Agile life cycle model, the BES PMO adopting agile methods may have specific practices for the Project Planning and Project Assessment and Control processes (i.e. see Figure 5-2 - Evolutionary, Iterative Agile Development Life Cycle Model) that are applicable to how they plan, schedule, monitor and control acquisition task order execution. Rather than establishing major control points at the transition between stages or processes, agile projects often hold less formal checkpoints or retrospective reviews at the end of a time‐boxed cycle to agree on improvements for the next cycle. Each iteration includes design, development, and test activities (test‐driven development). After a sprint of approximately four weeks or longer, new working software elements are accepted as “done” — completely developed, verified (tested) and validated. Lessons learned and process improvements are identified, and work begins on another sprint. Continuing learning, risk management, and process improvement can be facilitated by continuous release planning and sprint planning meetings to perform backlog refinement that are initiated for each iteration and retrospective meetings held at the end of each iteration.

Exhibit 5-2: Evolutionary, Iterative Agile Development Life Cycle Model.

Agile methods emphasize the Stakeholder Needs and Requirements Definition process to facilitate change through a high degree of ongoing Product Owner and stakeholder involvement. In SAFe contract agile acquisition projects, key stakeholders, such as the PMO or Product Owners (user representatives), are not just approvers of information, measurements, and evaluation reports, they are involved in every technical process, including the BES BPD Tailoring Worksheet process at the beginning of the project. They are closely involved in requirements management, at each iteration, by bringing new requirements and changes in priorities and participating when prioritized requirements are selected from a product backlog of undeveloped features and user stories and further refined for development in Release Planning. The iterative approach encourages flexibility to add, reprioritize, or defer requirements which are recognized as being within the general scope of the project. Also, product owner and stakeholder involvement in the approval of tested software in each iteration means that validation is continual throughout the project.

With the incremental definition of evolving requirements, the concept of project scope differs in an agile project from projects where scope is defined by a predetermined baseline of specified requirements. In Agile projects, defined product scope is initially tied to high‐level Epics and User Story fundamental requirements. More detailed levels of product definition are refined as additional knowledge is gained throughout construction. Agile level of effort work efforts may also control scope through time‐boxed schedules or resource‐limited teams. This approach is particularly appropriate for software maintenance efforts, where the extent or content of corrective or adaptive work is not fully specified initially.

The preparation of specifications, design artifacts, and information items or documentation during AAM agile projects is often limited, while software developers apply their time and skills to transform a scenario or narrative of a function (“user story”) into a working, testable software feature. Rather than preparing elaborate review packages for briefing at infrequent major milestone reviews, the team meets with the product owner and stakeholders frequently to present informal evidence of completing features (a set of user stories) and to agree on the content of the next iteration. Documented information items focus on what will be needed for transition, operation and maintenance, such as operator and end‐user documentation and baselines of tested and released versions of software with test automation plans, test cases, test scripts and cybersecurity artifacts. Projects reuse organizational procedures for configuration and release management, verification, and incident and problem management. Where possible, bidirectional traceability is enabled and enforced by integrated automated systems and procedures for requirements management, architecture and design, configuration management, and measurement that are approved by the PMO for use on the AAM project.