(U) NGA Program Level Agile Process.docx

Program Level Agile Process

Version 4.4 4 September 2014

Table of Contents

List of Figures

List of Tables

Appendices

Revision History

CHANGE STATUS LOG

DOC. NO.

· Updated Figure 4‑1 (section 4)

· Clarified Roles and Responsibilities (section 4.3)

· Features are created by Product Management Team (section 4.3.1)

· Testing is completed by System Team (section 4.3.1.4)

· Added DevOps Team (section 4.3.3)

· Added Research & Development (section 4.3.8)

· Updated Configuration Management (section 4.4.1)

· Added Operations Readiness Checklist (section 4.4.3)

· Added Test Readiness Checklist (section 5.7.2.4) Other comments addressed

· Updated Features (section 5.4)

· Roles and Responsibilities (section 5.4.1)

· Added Estimating (section 5.4.2.3)

· Added Prioritizing (section 5.4.2.4)

· Added Grooming (section 5.4.2.5)

· Updated Feature Template (Appendix D) Other comments addressed

· Updated Features Roles and Responsibilities (section 5.4.1)

· Updated Operations Readiness (section 4.4.3)

· Updated Design Artifacts (section 5.2)

· Added User Subject Matter Expert (section 4.3.4)

· Updated Figure 5‑1 (section 5.4.1)

· Updated RACI Matrix (section 4.3)

· Updated Estimating (section 5.4.2.3)

· Updated Acronyms (Appendix I)

· Updated RACI Matrix (section 4.3)

· Updated Configuration Management (section 4.4.1)

· Removed Service Concept Document (Appendix F) Other comments addressed

· Added Configuration Management (section 4.3.7.1)

· Updated Figure 5‑4 (section 5.6.3)

· Updated Testing (section 5.7)

· Updated Roles and Responsibilities (section 5.7.1)

· Updated Process Steps (section 5.7.2)

· Updated Figure 5‑5 (section 5.7.2) Other comments addressed

· Updated Roles and Responsibilities (section 4.3)

· Updated System Team (section 4.3.1.4)

· Added Verification & Validation Group (section 4.3.6)

· Added Infrastructure Service Provider (section 4.3.7.2)

· Added Integrated Product Team (section 4.3.9)

· Updated Figure 5‑4 (section 5.6.3)

· Updated Testing (section 5.7)

· Updated Figure 5‑5 (section 5.7.2)

· Added Unit Test (section 5.7.2.1)

· Added System Test (section 5.7.2.2)

· Added Independent Verification & Validation (section 5.7.2.3) Other comments addressed

· Updated Figure 4‑3 (section 4.3)

· Updated Figure 4‑1 (section 4)

· General updates

UNCLASSIFIED

UNCLASSIFIED

Introduction The purpose and intent of this document is to define the process required for the execution of Agile development of information technology (IT) at the National Geospatial-Intelligence Agency (NGA). NGA has adopted a 3-tiered hierarchical approach as its framework for Agile Engineering. Agile Engineering is executed through 3 levels of abstraction, the Portfolio, Program and Team levels, with activities at the lower levels dependent on activities at the higher levels for successful execution.

This Program Level Agile Process contains the roles and responsibilities, process steps, templates, checklists and other relevant information for the successful implementation of Agile Engineering at the Program level, which involves the following:

· Vision

· Design Artifacts

· Nonfunctional Requirements

· Features

· Roadmap

· Agile Release Train

· Testing

· Metrics Assumptions The following are the Program level assumptions in order for this to succeed:

1. The Portfolio Level Agile Process exists and clearly defines the artifacts, roles, and integration with this .

2. The Team Level Agile Process exists and clearly defines the artifacts, roles, and integration with this .

3. The Program level receives Epics from the Portfolio level.

a. The Portfolio level makes the determination as to whether or not an Epic is to be considered, and to which programs an Epic gets allocated.

b. Features that fit in programs are funded by Budgets at the Portfolio level.

4. Contract actions are performed by the appropriate Contracting Officer (CO)/Contracting Officer’s Technical Representative (COTR) in accordance with the Agency Agility Strategic Initiative (A2SI) within the NGA Agile Contracting approach.

a. There is at least one Agile program for which to allocate Epics. Where an appropriate program does not exist, a new Agile program may be created: utilizing the NGA (Agile) Acquisition process, improving an Agile program framework like an IDIQ (Indefinite Delivery, Indefinite Quantity), leveraging an existing contract vehicle by adding an ad-hoc CLIN (Contract Line Item Number), etc.

b. The contract for an Agile program allows for it to follow this .

c. The contract for a Define, Build, Test (DBT) Team allows for it to follow the .

5. At some point in the future, there will be multiple programs for which to allocate Epics at the Program level.

6. There is at least one DBT Team for which to allocate Features. Where an appropriate team does not exist, a new team may be created through the NGA (Agile) Acquisition process.

7. The National System for Geospatial-Intelligence (NSG) Online Workspace (NOW) Alpha/Beta environments are available to be used by the Program level.

8. JIRA is being used by the Portfolio, Program, and Team levels to track backlog items.

9. Architectural Design Artifacts include use cases (Unified Modeling Language (UML) diagrams and/or Department of Defense Architectural Framework (DoDAF) views), interface artifacts (e.g. Interface Control Documents (ICDs), service specifications, Service Level Agreements (SLAs), Memorandums of Understanding (MOUs), etc.), and/or metadata.

· The term User Stories is used to reference all types of Stories. There exists several types of Stories (as described in the ), such as User Stories and Refactors.

Big Picture

Figure 3‑1 shows the high-level overview of the entire NGA Agile Engineering process. The purpose and intent of this document is to define the process required for the execution of Agile Engineering of IT at NGA. NGA has adopted a 3-tiered hierarchical approach as its framework for Agile Engineering. Agile Engineering is executed thru 3 levels of abstraction, the Portfolio, Program and Team levels, with activities at the lower levels dependent on activities at the higher levels for successful execution.

At the Portfolio level, NGA strategizes on its missions and initiatives to create Epics in the Portfolio Backlog, and determines the programs where the Epics are allocated based on priority, funding, and value. NGA’s budget is divided into Budgets, which fund the continual operation of programs/products that the agency wants to run at the Program level. Each program, once it has been approved for development and the resources have been identified, is allocated a Budget and is responsible for delivering Enterprise value via changes to the NSG product/domain (known as a Value Stream) for which the program is responsible. For more information about the Portfolio level, please see the .

The Program level addresses how the content (Features) of each program’s releases are determined, prioritized, planned, managed, and ultimately delivered via time-boxed, iterative releases. The NGA programs create Features in the Program Backlog based on various inputs: Epics, Use Case Model, Design Artifacts, Feedback, Mission Owners/User Subject Matter Experts (stakeholder/users to review the Feature acceptance criteria), and engineering studies. The Features are then allocated to Product Owners at the Team level to be implemented during releases. The Program and Team levels combined are commonly referred to as an Agile Release Train. Unlike programs following a sequential/waterfall change paradigm (e.g. definite beginning and end, start/stop processes), NGA’s scaled Agile paradigm treats Agile Release Trains as vehicles for collaboratively providing value to the NSG following a cadence. Each Agile Release Train can apply the Agile self-organizing principle to determine how to best organize to support their Vision. This focuses on the Program level.

The Team level addresses how changes to the NSG are actually made, utilizing the inputs from the Program level. It includes the management and operation (define, develop, and test) of the DBT Team(s) assigned to each Agile Release Train, and the prioritization and determination of what software development changes will be included in the next Team level iteration of the release using User Stories in the Team Backlog. For more information about the Team level, please see the .

Figure 3‑1: Scaled Agile FrameworkTM Big Picture[footnoteRef:2] [2: “Scaled Agile FrameworkTM Big Picture,” version 3.0, http://www.scaledagileframework.com/.]

Process Overview This supports aligning and integrating the value (User Stories) created via the into larger compositions of value (Features) necessary to achieve broader NGA Enterprise objectives and value (Epics). The roles and activities at this level are organized around, and in support of, an ongoing series of incremental releases of product capabilities. Ultimately, the Program level process will support multiple products, each with its own cadence of continual releases.

As depicted in Figure 4‑1 (broken up into phases to facilitate readability), this involves the Vision, Design Artifacts, Nonfunctional Requirements, Features, Roadmap, Agile Release Train, and Testing. This entire process needs to be able to adapt quickly over time, as Budgets are created, new Epics are received from the Portfolio level, Features are defined at the Program level, and User Stories are developed at the Team level. The items in blue are artifacts, and the items red are Metrics.

Figure 4‑1: Program and Team Level Process Overview The first phase of work at the Program level involves the creation of the Vision, Design Artifacts, Nonfunctional Requirements, and Features in parallel (all of these activities feed each other), the Features being prioritized to create the Program Backlog, and the creation of the Roadmap. The second phase involves the Features being decomposed into User Stories by the Team level, and the Agile Release Train planning (which includes the Release Planning Event). Both the first and second phases combined take 8 to 10 weeks. The third phase involves the Agile Release Train execution (which includes sprint development by the DBT Teams), sprint demonstration to users (at the Team level), security scans and Testing of completed Features (at the Program level), and release to operations (at the Program level).

What is a Program?

A program manages a development team and has a release train.

· Throughout this document, the term program is used to describe an Agile program.

An Agile program manages DBT Teams, has an Agile Release Train, and follows the NGA Agile Engineering process. However, the term program should not be confused with the term Program of Record (POR). A POR is a funded NGA contract that may or may not follow Agile processes. A POR could have two (or more) different areas of focus: one that is responsive to the Product Manager/Program Backlog priorities, and a second that might deliver capability independent of the Product Manager/Program Backlog priorities.

Once Epic level architecture has been created, there should be a high level understanding of the intent of the system and components necessary to realize the functionality. At this point there should be an assessment of the current capabilities and an Analysis-of-Alternatives (AOA) must be performed to determine the appropriate path forward. It is during this AOA that a decision is made to create a new component or to enhance an existing component. Once this decision has been made, a capability provider (DBT Team or POR) should be identified. By identifying the capability provider at this point in the process, they can contribute their understanding of the solution space, the existing architecture, and contribute to the development of Features. This enhances their understanding of the Features and aids in the decomposition of User Stories during the Release Planning Event (FRPE). In some cases, the POR may indicate that the functionality being requested was already planned for in their POR requirements/roadmap. In the event that this occurs, the Product Manager must make a decision as to whether the program is going to wait for the POR to deliver the capability, or if a DBT Team needs to develop a stop gap. If a POR is planning to provide the capability in a release beyond the current, these future deliveries can be tracked on the Roadmap and the necessary dependencies can also be tracked.

In the event that a POR is planning to provide a capability that was not based on a program-defined Feature, they must communicate this plan with the Product Manager to ensure that the program is fully aware of the development, it is aligned to the Vision of the program, and it has been incorporated in the Roadmap. If the POR were to develop a functionality without alerting the Product Manager prior to development, an assessment must be made by the Product Manager as to whether or not the functionality should be included. In this case, the functionality should be treated in the following manner:

1. Promote into the NOW Beta environment for User Subject Matter Expert evaluation.

2. If the and User Subject Matter Experts determines it is a value added capability, an engineering study must be performed.

3. Study to determine if the capability should be included as-is, or if it should be incorporated with another current capability.

4. A standalone capability is included in the next Agile Release Train release to operations, and incorporation is captured as a Feature to be prioritized and worked in a future release.

The following checklist should be used to determine if a project is an Agile program. Does the project have:

· A high amount of uncertainty?

· Needs/capabilities are not all known/defined up front

· There is a need to vary the needs/capabilities

· “In agile, the business owner/sponsor can add to the backlog or reorder the priority any way they want, as long as the current iteration in progress is sacrosanct.”[footnoteRef:3] [3: Cindy Shelton, “Agile Acquisition – In Progress,” 2013, www.interscience.wiley.com, 30.]

· “During each project, the less valuable functionality sifts to the bottom of the backlog (capability/requirements/features/stories) and is never implemented.”[footnoteRef:4] [4: Cindy Shelton, “Agile Acquisition – In Progress,” 2013, www.interscience.wiley.com, 30.]

· The need to leverage the artifacts developed using the ?

· Vision

· Design Artifacts

· Nonfunctional Requirements

· Features

· Roadmap

· Agile Release Train (schedule)

· Testing (Test Report Template)

· The resources to support the ?

· Product Manager

· System Architect

· User Experience Designer

· System Team

· Product Owner

· Release Manager

· Release Train Engineer

· Mission Owner

· User Subject Matter Expert

· DBT Team

· Verification & Validation Group

· Security Engineer

· Infrastructure Service Provider

· Configuration Management

· Readiness

· Research & Development

· Integrated Product Team

· An Agile contract with the appropriate language?

· Adherence to the

· Acquisition strategy that is adaptive

· Reduction in acquisition life cycle time

· Requirements prioritization based on value

· Ability of CO/COTR to change priorities and direction

· Minimum documentation that is just-in-time/good enough

· “Establish disincentives within the participating organizations where they must pay any costs associated with lack or participation or delayed decision making.”[footnoteRef:5] An example would be an award fee deduction. [5: Shelton, 25.]

· “Agile delivery cycles require contract vehicles to be written to allow the flexibility to allow the value of agile practices to be realized and employ incentives for early quality delivery.”[footnoteRef:6] [6: Shelton, 29.]

· Funding?

· Ability to receive Epics from the Portfolio level for which to decompose into Features

· Budgets fund the Agile Release Trains Inputs/Outputs Inputs to the Program level are Epics, Feedback, and engineering studies. Items created to support the Program level are the Vision, Design Artifacts, Nonfunctional Requirements, Features, Roadmap, Agile Release Train, and Testing. The Mission Owners/User Subject Matter Experts (stakeholders/users to review the Feature acceptance criteria) and System Team/Verification & Validation Group (to create and review the Feature acceptance criteria) (see the Feature Acceptance Criteria field below in the Feature Template) provide an evaluation and recommendation of Feature acceptance criteria to the Product Manager during the Release Planning Event. Outputs from the Program level are Features (from business and architectural Epics) and completed capabilities delivered to operations. Features decompose into User Stories. The relationship from the Portfolio level down to the Program level is one-to-many; the relationship from the Program level to the Team level is one-to-many.

Figure 4‑2 depicts the data of the Program level (as shown in green) in the perspective of the Scaled Agile FrameworkTM (SAFeTM) model. The numbers next to the boxes show the relationship of the items (e.g. 1 Feature is realized by 1 to many User Stories).

Figure 4‑2: SAFeTM Data Model[footnoteRef:7] [7: Dean Leffingwell, “Agile Software Requirements,” Addison-Wesley, 2011, www.scaledagileframework.com, 489.]

Roles and Responsibilities This section defines the roles and responsibilities associated with the Program level. Figure 4‑3 depicts a RACI matrix that relates these roles and responsibilities to the Program level process workflow steps from Figure 4‑1. A Responsible, Accountable, Consulted, Informed (RACI) matrix is an acronym that associates process activities with the following types of roles:

· Responsible (R – who performs the work)

· Accountable (A – who has approval authority of the work)

· Consulted (C – who provides feedback and/or contributes to the work)

· Informed (I – who requests to be informed of the work)

Figure 4‑3: RACI Matrix

Product Management Team The Product Management Team includes the Product Manager, System Architects, User Experience Designers, System Team, and Product Owners. In general, the Product Management Team acts as the authority for the content of a release on the Agile Release Train to maximize the successful delivery of Features, and is the owner of the Program Backlog, Features, priorities, and acceptance criteria for Features.

The Product Management Team has the responsibility to scope, bound, define, design, and prioritize the Program Backlog, as well as to work with the Release Management Team, Epic Owners, and DBT Teams to optimize Feature delivery to the customers in balance with the enterprise’s technical and economic objectives. The Product Management Team is also responsible for identifying JARM Technical Services Taxonomy (TST)/Technical Services Category (TSC) and JARM Geospatial Intelligence (GEOINT) Reference Architecture (GRA) TSCs. NGA Systems Engineering and architecture support is required to support building and maintaining the program Vision, Program Backlog, and Roadmap. Systems Engineering support is also needed for defining Nonfunctional Requirements that contain standards and guidelines, as well as developing and maintaining program Design Artifacts.

Product Manager The Product Manager is the government lead in charge of the Program Backlog, Features, and priorities. The Product Manager works with the Mission Owners and Epic Owners to understand user priorities, works with the Release Management Team to approve the prioritized list of Features for the release, and works with the Product Owners during the Release Planning Event by arbitrating resource conflicts. The Product Manager works with the Release Management Team prior to and during the Release Planning Event to ensure that Features from the Program Backlog are being worked by individual DBT Teams for development. The Product Manager serves as the “content authority” for the Agile Release Train. The Product Manager is accountable for the following:

· Formulate a unified Vision based on input from multiple stakeholders

· Develop the product Roadmap with support from the Product Management Team and Release Management Team

· Approve all Features, ensuring that each Feature has clear and complete acceptance criteria

· Determine what is built through the Program Backlog

· Prioritize the Program Backlog

· Define done for Features

· Accept or reject work results for the program The Product Manager also works with the Program Portfolio Management Team (described in the ). In this role, the Product Manager provides support to help the Portfolio level estimate Epics as needed.

System Architect

· When defining architectural Features, the System Architect is the main point of contact for creating the Features and pulls in the DBT Team members as needed to elaborate any technical components of the Features (see Figure 5‑1).

The System Architect supports “Programs, and has the responsibility for maintaining a high level understanding of the user’s Vision for what the subject system needs to do, as well as maintaining and evolving an understanding of the implementation framework necessary to support current and upcoming user needs.

… System Architects … fulfill the following primary responsibilities:

1. Work with customers, stakeholders, Product Manager and Product Owner to understand and maintain a high level understanding of the current and upcoming requirements for the system

2. Understand and communicate the Nonfunctional Requirements for the system

3. Evaluate design alternatives, and perform cost benefit analysis

4. Develop and maintain whatever models and documentation are necessary to describe how the system does what it is intended to do, including recommended … [Design Artifacts]

5. Define and split architectural Epics into Features for the Program Backlog, and allocating respective items to the individual Team Backlogs for implementation

6. Present the technological Vision for the solution during … [Potentially Shippable Increment (PSI)]/Release Planning, provide domain models and exemplary Design Artifacts that describe larger system behavior, and participate actively and interactively during the PSI planning process

7. Serve as a resource to help the teams make appropriate system and component level design decisions during implementation

8. Work with Enterprise Architects at the Portfolio level to establish Architectural Runway in support of upcoming user and business needs”[footnoteRef:8] [8: “Scaled Agile FrameworkTM System Architect Abstract,” last modified January 15, 2013, http://www.scaledagileframework.com/system-architect/.]

The System Architect needs to work with the Enterprise Architect and DBT Teams to ensure that it creates designs that advocate a highly cohesive and loosely coupled architecture. High cohesion means that a specific component should be focused on performing strongly-related tasks. Loose coupling means that a change in one component does not require a change in all the components that use that one component.

User Experience Designer The User Experience Designer is involved with the quality of the end-users’ interactions with a website or application. The User Experience Designer ensures that the end product has a consistent NGA user experience, look-and-feel, and behavior (rewarding, simple, and intuitive). The User Experience Designer is concerned with presentation, functionality, content, language, help and support, Feedback, consistency, error management, visual clarity, navigation, and interaction in the use of products, applications, and services.

The User Experience Designer is a software engineer that integrates user knowledge, user-centered design, and user testing into a methodology that works. The acid test of the quality of the user experience is that the user should want to return to the online capability because of the Features it offers, its ease of use, and the frequency that the user is interacting online. The value delivered is a product that the user finds easy to learn, intuitive, has reduced errors, has reduced training time and effort, and has reduced user reported defects.

User experience is an important factor in Graphical User Interface (GUI)/widget design, and in web and product design. User experience is factored in as early as possible before the freezing of the User Interface (UI) design, and ideally, even before freezing of the requirements and scope. The User Experience Designer is responsible for creating GUI mock-ups for inclusion in the Design Artifacts; they are also be involved in the creation of the Nonfunctional Requirements.

X provides leadership and commitment to the User Experience Designer. The Product Owner should understand the users’ specific usability requirements. DBT Teams must be able to apply usability guidelines throughout the design and development of User Stories. The System Team and Verification & Validation Group evaluate products for usability defects.

System Team The primary focus of the System Team is to ensure that Features work as required to satisfy the stated system-level objectives, and that the current release/iteration did not break other Features. The System Team is also responsible for providing assistance with integrating code from the DBT Teams, testing platforms, test automation frameworks, performance testing, and performing end-to-end system testing.

Throughout the , the System Team is included in Feature elaboration discussions conducted by Epic and Product Owners. The System Team is informed about decisions regarding the content of a release, which includes the Program Backlog, Features, and prioritizations through the Release Planning Event. The Mission Owners/User Subject Matter Experts (stakeholders/users to review the Feature acceptance criteria) and System Team/Verification & Validation Group (to create and review the Feature acceptance criteria) (see the Feature Acceptance Criteria field below in the Feature Template) provide an evaluation and recommendation of Feature acceptance criteria to the Product Manager during the Release Planning Event.

Product Owner

· The Product Owner is a Team level role; each DBT Team has a Product Owner.

· The Product Owner is to the DBT Team, as the Product Manager is to the Program.

· When defining Features, the Product Owner pulls in the DBT Team members as needed to elaborate any technical components of the Features (see Figure 5‑1).

The Product Owner is the team's key stakeholder: a government representative that has the ability to convey this Vision and understand what needs to get built. The Product Owner defines the DBT Teams’ priorities for each sprint. The Product Owner is accountable for the following at the Team level:

· “Gather input about what to build

· Understand the relative value of each item

· Create prioritized list based on value, size, risk and other considerations

· Provide context to the team

· Allow the team to make their commitments

· Inspect functionality to identify done

· Adjust the [Team] Backlog and release dates based on opportunities, constraints and risks to optimize ROI

· Maintain & communicate a clear release acceptance criteria and release burndown

· Abnormally terminate sprint in extreme circumstances [(under the direction of the Product Manager)], otherwise don’t disrupt the team during a Sprint except when termination is required”[footnoteRef:9] [9: “Certified Product Owner Training,” LitheSpeed, www.lithespeed.com.]

· Approve all User Stories (including Spikes), ensuring that each User Story has clear and complete acceptance criteria

· Organize and prioritize the Team Backlog

· Define done for User Stories

· Accept or reject work results for the team

· Develops Sprint and Release Objectives for the team

· Responsible for the ROI (mission value) of the team’s products

· Managing Discrepancy Reports (DRs) from operations and Verification & Validation Group, and coordinate the work-off of Discrepancy Reports with the appropriate Scrum Master

· Inspect and ensure that the Apps Tracker Spreadsheet (ATS), deployment package ZIP file, and supporting documentation is thorough and complete in support of Testing and Configuration Management; once the package has been verified as complete, it is forwarded to the Product Manager for review and placement in More details are defined in the .

Release Management Team The main jobs of the Release Management Team are to assist the Product Manager with planning releases, negotiate the set of Features that get allocated to releases, roll up DBT Team Sprint Objectives into Release Objectives, communicate release burn down, ensure that Testing is passed, and obtain approval to release to operations. The Release Management Team is also responsible for managing and scheduling synchronized PSIs/releases across one or more programs. Members of this team could also be called “Release Coordinators” or “Release Facilitators” because their main responsibility is to coordinate and facilitate the delivery of productized software developed by the Agile Release Train to NGA operations for deployment into the production or staging environments.[footnoteRef:10] [10: “Scaled Agile FrameworkTM Release Management Team Abstract,” last modified January 15, 2013, http://www.scaledagileframework.com/release-management-team/.]

Release Manager The Release Manager has the primary objectives of ensuring the release commitments are delivered, and supporting the creation of the Roadmap. The Release Manager performs release management of all scrum teams, and coordinates with the Product Manager. The Release Manager works with the Product Manager and Product Owner to ensure the Program Backlog has complete Features, and teams have generated User Stories during the Release Planning Event. The Release Manager also facilitates meetings to identify cross team synergies, conflicts, and bottlenecks. The Release Manager is responsible for negotiating the alignment of Features into releases to be worked on by the individual teams at the Team level. After development is complete, the Release Manager is responsible for ensuring that the PSI/release has been accepted by the users, System Team, Verification & Validation Group, Security Engineers, and is approved to go to operations.

Release Train Engineer The Release Train Engineer is responsible for ensuring that the Features in the Program Backlog are prioritized, supporting the creation of the Roadmap, and facilitating the cadence of the Agile Release Train. The Release Train Engineer is the Scrum of Scrum Master for the Agile Release Train. “Generally the Release Train Engineer reports progress to the Release Management Team on a weekly basis, with working system software being the primary measure of progress. With proper tooling, reporting is also facilitated by the release burn down chart and feature status report.”[footnoteRef:11] [11: “Scaled Agile FrameworkTM Agile Release Train Abstract,” last modified January 14, 2013, http://www.scaledagileframework.com/agile-release-train/.]

Mission Owner The analysts from Analysis (A), Source (S), Xperience (X) and IT Services (T) are the most relevant stakeholders, but due to their other roles and responsibilities they are represented in this process by their corresponding Technical Executives (TXs). Mission Owners (normally A, S, X, and T TXs) have the ultimate responsibility for the value delivered by a specific Agile Release Train. They are responsible for understanding the Budgets that drive the train, have knowledge of the current mission and business context, and are involved in driving or reviewing the program Vision and Roadmap. The Mission Owners are also responsible for assigning mission value to Sprint and Release Objectives.

TX designated representatives are also referred to as Mission Owners. The Mission Owner is responsible for identifying User Subject Matter Experts that understand specific user needs, beyond the expertise of the TXs. The Mission Owner also collaborates with the Epic Owners, Program Portfolio Team, Product Management Team, Product Owners, and DBT Teams, as needed, to support the elaboration of Epics into Features and Features into User Stories. The Mission Owner is accountable for the following:

· Develop the program Vision

· The Mission Owners/User Subject Matter Experts (stakeholders/users to review the Feature acceptance criteria) and System Team/Verification & Validation Group (to create and review the Feature acceptance criteria) (see the Feature Acceptance Criteria field below in the Feature Template) provide an evaluation and recommendation of Feature acceptance criteria to the Product Manager during the Release Planning Event

· Assign mission value for the objectives at the Release Planning Event

· Determine mission value for the objectives at the PSI demo to the users A Mission Owner is a separate role from an Epic Owner; however, a Mission Owner can be an Epic Owner as well. The role of the Epic Owner is be defined in the .

User Subject Matter Expert The Mission Owner is also responsible for identifying and providing users that understand specific User Stories beyond the expertise of the TXs. The User Subject Matter Experts are the most relevant stakeholders, but their time must be utilized judiciously due to their other roles and responsibilities. Ideally, each Feature would have a User Subject Matter Expert which developers could coordinate with to answer any questions and ensure that the development is headed in the right direction. The User Subject Matter Experts assist with the following areas:

· Be able to address a specific Feature from an enterprise view versus a working group view

· Assist with developing acceptance criteria for the Features and User Stories

· Assist with clarification of acceptance criteria

· Assist with development Testing (Unit Tests done prior to System Test and Independent Verification & Validation)

· Provide Feedback on Features DBT Team The DBT Teams are found at the Team level. NGA DBT Teams are cross functional teams consisting of a Product Owner, Scrum/Agile Master, Systems Engineer, and Developers and are fully capable of defining, building, and testing increments of customer mission value in a short time box. Including System Engineers enhances the DBT Teams' ability to support the Product Manager and Product Owner for Feature and User Story decomposition, increases program efficiency and transparency by engaging teams early in emerging design and architecture. Systems Engineers also improve communication, as well as reduce hand-off interactions between the Program level (engineering) and Team level (development).

DBT Teams can be organized into Feature Teams or Component Teams, and should be co-located. A Feature Team focuses its efforts on developing code for a single Feature, or set of Features. The Feature Team works on the Features, cutting across the various components in the Architectural Runway. In this situation, a single Feature is allocated to a single DBT Teams for decomposition and implementation. A Component Team focuses its efforts on implementing all of the User Stories for a specific, specialized component. The Component Team is usually comprised of SME developers that are very familiar with the component code. In this situation, a single Feature is allocated to multiple DBT Teams for decomposition and implementation.

Verification & Validation Group The Verification & Validation Group is comprised of two offices: the TV office is the NGA Test Organization (NTO), and the TQ office is the NGA Image Quality and Utility (NIQU). Throughout the , the Verification & Validation Group is included in Feature elaboration discussions conducted by Epic and Product Owners. The Verification & Validation Group is informed about decisions regarding the content of a release, which includes the Program Backlog, Features, and prioritizations through the Release Planning Event. The Mission Owners/User Subject Matter Experts (stakeholders/users to review the Feature acceptance criteria) and System Team/Verification & Validation Group (to create and review the Feature acceptance criteria) (see the Feature Acceptance Criteria field below in the Feature Template) provide an evaluation and recommendation of Feature acceptance criteria to the Product Manager during the Release Planning Event.

The primary focus of the NTO is to ensure that the new interfaces work as required to satisfy the stated system-level objectives, and that the current release/iteration did not break any interfaces to other systems or Features. The NTO is also responsible for providing assistance with testing platforms, test automation frameworks, performance testing, and performing end-to-end system testing. NTO Agile Independent Verification & Validation is be led by the Agile engineering Test Director (TD) and Deputy Test Director (DTD). Each Agile Release Train has a TD and DTD. Enterprise Independent Verification & Validation has its own separate TD and DTD. Available NTO test engineers (including a cast of test support roles, Discrepancy Reports management, document Quality Assurance (QA), etc.) are tasked to assist the TD and DTD in Testing.

On the other hand, the primary focus of the NIQU quality assurance activities, separate from the NTO, is to verify the accuracy and utility of the delivered software products subject to use by the Intelligence Community (IC) for intelligence based decision-making. NIQU maintains an informed presence within the Team level (sprint) and is postured to provide surge support to TV as needed. TQ provides and advises developers of enterprise image product quality data standards to aid in the development of effective capabilities. An informed presence at the Team level affords TQ the insight to determine what capabilities fall within their area of core responsibility. The Nonfunctional Requirements that deal with product quality are provided through the PQ ORC. The PQ ORC documents the enterprise standards that TQ uses to assess capabilities, and developers use to build capabilities. TQ has points of contacts for the PQ ORC. Utility is assessed by such measures as National Image Interpretability Rating Scale (NIIRS), which defines the utility achieved at different levels of quality. NIQU achieves its mission by providing unbiased system engineering, test and evaluation services to the IC. NIQU specialties include: imagery analysis/science, statistical/metric analysis, systems engineering, imagery standards and scales. In support of the IAE, Desktop Environment, and the IC ITE, NIQU performs the following tasks:

· Ensures widget & application output accuracy

· Assesses pre-release and post-release apps and widgets

· Assesses usability and utility of the IAE, from the perspective of both the GEOINT producer and the GEOINT consumer DevOps Team The DevOps Team is a primary interface between development and operations, and includes the Security Engineers, Infrastructure Service Provider, Configuration Management, and Readiness. The DevOps Team ensures that the system is ready for deployment to NGA operations, coordinates infrastructure, provides assistance with managing versions of code from the programs, and facilitates the Operations Readiness process for deployment in operations.

The DevOps Team is also responsible for enabling the flow of products from the NOW Alpha environment to the NOW Beta environment to operations. This team manages and maintains the development application service platforms, including development platforms (NOW Alpha environment), test platforms (NOW Beta environment), Configuration Management, version control, and governance and management tools (e.g. JIRA, Greenhopper, Bamboo, Fisheye, Crucible, Confluence).

Security Engineer The Security Engineer works in the Office of the Chief Information Officer (OCIO) and has the responsibility to coordinate with the Product Management Team to ensure that the aims of information security management are met. The Security Engineer can stop functionality from proceeding to operations whenever the PSI/release does not meet security processes and standards. These include the Certification and Accreditation (C&A) process, Hewlett-Packard (HP) Fortify scans, the Agile Application Assurance (AAA) form, as well as Certification to Field for capabilities being deployed to operations.

Infrastructure Service Provider The Infrastructure Service Provider (ISP) is responsible for developing and maintaining IT infrastructure and Information Services (IS) for the NSG. The Infrastructure Service Provider delivers IT infrastructure services such as application hosting, transport, storage, enterprise management, and common services and applications (e.g., email, office automation). The Infrastructure Service Provider is consulted by the System Architect to help define Nonfunctional Requirements, create architectural Features, and develop Design Artifacts.

Configuration Management The Configuration Management group is comprised of members from the Schedule & Configuration Management Division (TTK) within AEG at NGA. This group is responsible for ensuring that the Configuration Management Process is being followed at each of the respective levels within the Agile process. Each individual playing a role in the Agile process is also responsible for their own piece of the Configuration Management Process. As an idea (Epic, Feature, Story, etc.) evolves and is worked though the NGA Agile process, each person who touches that idea must be sure to document their piece as outlined in section 4.4.1. Whether you are a System Architect, Developer, or tester, the Configuration Management group must ensure that you have documented your piece and point to it.

Readiness Readiness is a major component of the mitigation and management of risk. Prior to the completion of a PSI/releases, the Product Manager will complete a prescribed checklist (see section 4.4.3) which identifies the key functionalities and assesses an overall readiness to move the software forward into operations. The checklist ensures that the product meets the user’s needs and the NGA strategic implementation of the DoD acquisition best practices.

Research & Development The existing model has InnoVision as its own Agile DBT Team (with a Product Owner). An alternative approach is to include a Subject Matter Expert (SME) from InnoVision sitting on an existing DBT Team (supporting the Product Owner) and providing guidance. The intent is that InnoVision matrixes in-and-out of Agile DBT Teams. While InnoVision may not be the expert for how to deliver code, they are the SMEs of how to improve the code (e.g., algorithms). In this new model, InnoVision acts as the forward thinking pieces vice the actual development. InnoVision can “deliver” a prototype to end-users as a DBT Team approaches a PSI, though the prototype might not be delivered to NGA operations. The idea is to have InnoVision evaluate early and often using users (e.g. NOW Beta environment, GIAT servers). InnoVision should also be leveraging interactions with the Mission Owners at the Portfolio level.

Integrated Product Team For Agile, the role of the Integrated Product Team is to staff the DBT Teams on the Agile Release Trains, provide a venue to coordinate between Agile Release Trains, and manage Operations and Sustainment (O&S) of capabilities that have completed development and are fully deployed to NGA operations. O&S occurs when an Agile Release Train ceases to exist, yet the functionality is still in used by NGA.

Governance Governance is imposed on the Program level via a Configuration Management Process, Control Boards, and Operations Readiness.

Configuration Management Process Figure 4‑4 shows a high-level overview of the Configuration Management Process at all three levels. In order to completely capture the appropriate baseline management at the Program level, every product must maintain versions of the following documents for each release baseline using a Configuration Management Process tool:

· Vision – This document are maintained using Microsoft© SharePoint, or another file system Configuration Management Process tool.

· Design Artifacts – These documents may be captured in a separate tool, but the use cases, interface artifacts, and/or metadata files are be maintained in Microsoft© SharePoint. These documents may be updated based on input by the DBT Teams after the Release Planning Event.

· Nonfunctional Requirements – These items are maintained in .

· Features – These items are managed in as Program Backlog items.

· Roadmap – This document is a dashboard maintained using and/or Microsoft© SharePoint; it shows the high-level Features for the releases.

· Agile Release Train – This project file is maintained using Microsoft© SharePoint/Project Server, or another file system Configuration Management Process tool.

· Testing – The outcome of these activities is managed in and/or Microsoft© SharePoint.

All of these documents are explained in greater detail in the sections that follow. If the development code for a particular release needs to be rolled back a previous state, then the documentation for that previous state should be able to be rolled back as well.

Figure 4‑4: Configuration Management Process

· The ATS identified at the Team level was previously named the ER2 Spreadsheet.

· The Description Document identified as output at the Team level is the responsibility of the Release Manager from the Program level. This document will be maintained in the CM Library.

The NGA Agile engineering process does not involve the creation of a Request for Change (RFC) to act as approval to make changes to the release baseline. It does, however, involve the creation of a virtual RFC at the end of major milestones (e.g. version 1.0, 2.0, etc.) to “snap the line” on the baseline (documentation and code) after the fact; this type of RFC is considered “as built.” The virtual RFC process allows updates, modifications, and developments to be coordinated and approved in an expedited process. The steps of the traditional RFC process are modified to allow adequate coordination as required, without the need for the RFC to move through unnecessary steps.

Control Boards The Program level seeks feedback for the Roadmap from the Mission Technical Review Board (MTRB). The purpose of this meeting is to get another perspective on the current and planned technical outlook of the product. A detailed view of the Roadmap is depicted in Appendix E: Roadmap Template.

The Program level also seeks Operations Readiness approval to promote a PSI/release to operations. The purpose of this approval is to ensure that the product meets the NGA strategic implementation best practices, as well as to help mitigate and manage risks.

Operations Readiness Prior to sending a PSI/release to operations, the DevOps Team completes the following governance checklist which assesses an overall readiness to promote the Features from the NOW Beta environment into the operational environment:

· With respect to the Integrated Analytic Environment (IAE), the Application Services Governance Board (ASGB) performs the function of the DevOps Team to declare operational readiness.

· Has the Product Manager accepted the promotion of the Features to operations?

·…