Appendix D_DLA Agile Playbook_Version 1.0 .pdf

Defense Logistics Agency

DLA PORTFOLIOS/PROGRAMS AGILE

PLAYBOOK

Version 1.0

DLA Portfolios/Programs Agile Playbook Revision History Table

Version Date Summary of Changes Prepared By

1.0 4/12/2023 Approved Baseline Version J62LA, SE Team

The Chief Engineer and the Program Executive Officer (PEO) hereby approve this Agile Playbook for DLA Portfolios/Programs for immediate use.

Approved By:

Manikyamohan Pinisetti, PEO Chief Engineer Office of the Chief Engineer, J62L

James Johnson, Acting Program Executive Officer Program Executive Office, J62

Table of Contents

1.0 Introduction

2.0 Agile Scrum Overview

2.1 Roles and Responsibilities

2.2 Key Scrum Events and Artifacts

3.0 Agile Software Development Lifecycle (SDLC) at DLA

3.1 Agile Planning and Preparation – Sprint 0

3.2 Sprint Lifecycle and SDLC

3.2.1 Sprint and Release Planning

3.2.2 Daily Scrum

3.2.3 Sprint Development and Review

3.2.4 Sprint Retrospective

3.3 Challenges

3.4 Benefits

3.5 Lessons Learned

4.0 Tools

5.0 Agile Versus Waterfall

6.0 Agile Playbook and Systems Engineering Plan (SEP) Relationship

Appendix 1.0 References

Appendix 2.0 Acronyms

Appendix 3.0 Definitions

Appendix 4.0 Scrum Checklist

Appendix 5.0 Training Plan Checklist

Appendix 6.0 Test Checklist

Appendix 7.0 Test Readiness Review

Appendix 8.0 Technical Activities

Appendix 9.0 Operational Readiness Review

Appendix 10.0 Defects Report

Appendix 11.0 Top-Level Schedule

Appendix 12.0 Engineering and Enterprise Platform Key Agile Points of Contact

Tables

Table 1: RACI Matrix Table 2: User Story Examples Table 3: Agile Tool Examples Table 4: Waterfall, Agile and Hybrid Comparison

Figures

Figure 1: Agile Sprint Lifecycle Figure 2: Epic, Release, Sprint Hierarchy Example Figure 3: Example of a Burndown Chart Figure 4: Example of a Sprint Velocity Chart

1.0 Introduction

The Defense Logistics Agency (DLA) Agile Playbook provides an overview of best practices for the implementation of the Agile methodology by program and project managers to deliver Information Technology (IT) functionality to customers/users. While there are several Agile disciplines, such as Scrum, Kanban, Spiral, and Scaled Agile Framework (SAFe), the focus of this document will be on the Scrum discipline.

This Playbook provides the Chief Engineer’s perspective on the Agile methodology. It also discusses some of the differences between Agile and Waterfall methodologies, and the use of a Hybrid approach. This Playbook also addresses the incorporation of the development, security, and operational (DevSecOps) approach for the development lifecycle with an emphasis on the cybersecurity perspective. The Agile methodology encompasses continuous requirements evaluation, effective integration, testing, evaluation, cybersecurity, implementation, and the use of automation into the development processes, where possible, to help ensure programs and projects are executed successfully.

This Playbook is intended to be used by programs and projects that have decided to apply the Agile methodology for their development lifecycle implementations. These best practices are intended as recommendations and should not be considered prescriptive. The Agile methodology is meant to be tailored to the project to promote efficiency of implementations. Agile can also be scaled to apply to larger program development initiatives.

This Playbook is written for managers, teams, and people, who are using Agile methodology for their programs and projects including, but not limited to, Portfolio/Program/Project Managers (PMs), Systems/Architectural Engineers, Test Leads, Use Case Managers, etc. (For more information, refer to the Roles and Responsibilities section.). This Playbook is intended to provide overall guidance and is not intended to be a substitute for formal Agile training. Agile participants are strongly encouraged to seek training relevant to their Agile roles as described in this document. This playbook is expected to evolve as DLA’s Agile maturity evolves and future versions may include the use of Agile for projects with objectives beyond delivering IT functionality.

According to a 25-year study of project success and failure rates done in 2020, Agile projects are twice as likely to succeed, and less than half as likely to fail as comparable Waterfall projects (Standish Group Chaos Report, 2020). In this development environment where scope change is a constant risk, and costs related to change are escalating, the use of Agile methodologies reduces risk and introduces a measurable amount of predictability in the development lifecycle.

2.0 Agile Scrum Overview

This section provides an overview of key Agile Scrum concepts to provide a foundation for understanding the remaining of the document. Section 3 builds on this foundation by providing more detail regarding the implementation of Agile at DLA and its relationship to the SDLC.

https://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects/

Agile Methodology Definition: An iterative and incremental (evolutionary) approach to software development, which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely manner, which meets the changing needs of its stakeholders.

DLA recommends following a Scrum Agile methodology for the software development lifecycle. Scrum is an iterative, incremental framework for project management; it emphasizes short, fixed time length (timeboxed), repeating delivery cycles known as Sprints. A checklist description of Scrum activities is provided in Appendix 4.0.

The key Scrum principles include:

• Focus on Customer Satisfaction: Scrum roles, events, and artifacts are designed to achieve customer satisfaction through frequent feedback, predictable delivery, and continuous improvement

• Adaptability to Continuous feedback: Small Sprints delivering potentially useable functionality allow for continuous feedback

• Value of “face-to-face” communication: Conversations whether in person or remote facilitate rapid information exchange and problem solving. The key Scrum events, including the Daily Standup Meeting, are all designed to facilitate dialogue.

Documentation only used if it adds value and/or is required

• Respect for ability of motivated team to accomplish objectives: Small, cross-functional Scrum teams are empowered to deliver all parts of the requested Release to Production and Scrum process facilitates continuous improvement and incorporation of lessons learned

2.1 Roles and Responsibilities

The Scrum Agile Methodology is especially suited for self-organizing teams managing and running software development or maintenance projects where the list of requirements, or the priority of the requirements may, and usually do, change. The four roles below include the three Scrum key roles and a Functional Stakeholder role, which has been added due to its importance to the Agile process:

• The Product Owner (PO): PO is the voice of the customer. and creates the Product Backlog, prioritizes items in the backlog, and ensures that the team delivers value to the customer

• The Scrum Master (SM): The SM coaches the team on Scrum principles, removes any impediments, and keeps the team focused. The SM conducts the Daily stand-up meetings and ensures the team delivers the Sprint goals. There are some similarities to a Waterfall Project Manager, but the SM does not directly manage the Development Team which is self-organized

• The Development Team: The Development Team is responsible for developing, testing, and integrating software to meet the requirements. The optimal team size is between five and nine individuals. The team includes all the skill sets needed to deliver functional software including developers, designers, software engineers, cybersecurity engineers, testers, etc.

• Functional Stakeholders: Sometimes referred to as customers. The Functional Stakeholders coordinate with the PO by providing input to the backlog requirements, attend demonstrations, etc., as needed, and attend the Sprint Review Meeting

The Appendix 4.0 Checklist Assignment of Roles section lists these roles. Scrum does not define a Project Manager role since many of these traditional Project Manager responsibilities are redefined in the SM and PO roles. Project Managers who will be fulfilling SM and/or PO roles should be trained and/or certified in these roles. The SM has the ultimate responsibility for ensuring that the Scrum events occur in accordance with Scrum principles. Table 1 depicts a Responsible, Accountable, Consulted, Informed (RACI) matrix for the roles as they apply to activities supporting Scrum events and artifacts described throughout this document.

Scrum Roles Product

Backlog Sprint

Plannin g

Sprint Backlog

Daily Scrum

Development Sprint Review

Sprint Retrospective

Product Owner

RA RA RA C C* C C

Scrum Master

C C C RA C* RA RA

Development Team

C C C C RA C C

Stakeholder C C C N/A C* C C*

Table 1: RACI Matrix

Each cell will be filled with an R, A, C and/or I to indicate:

• Responsible

• Accountable

• Consulted (* as needed)

• Informed

2.2 Key Scrum Events and Artifacts

Scrum Sprints consist of four events to achieve the program or project objectives:

• Sprint Planning Meeting: The Sprint Planning Meeting is conducted at the beginning of the Sprint and lays out the work that will be completed during the Sprint. The PO describes the Sprint’s objectives from the product perspective. The Scrum team identifies what can be completed during the Sprint from the Product Backlog which results in the Sprint Backlog. The Scrum team then further decomposes the Sprint Backlog items into tasks with a day or less duration. The tasks required to accomplish the Sprint Backlog are tracked by the Development Team during Sprint executions. The Appendix 4.0 Checklist Sprint Planning section lists related activities

• Daily Scrum Meeting: A daily meeting chaired by the Scrum Master typically time-boxed to 15 minutes where each team member responds to three questions:

o What have you done on the project since the last meeting?

o What will you do between now and the next Daily Scrum?

o With what do you need help?

The Appendix 4.0 Checklist Daily Scrum and Sprint section lists related activities

• Sprint Review Meeting: Takes place at the end of each Sprint. The Team presents and demonstrates achieved functionality. The team evaluates the outcome of the Sprint to ensure that progress is being made toward the overall project goals. This event is where the PO and stakeholders can observe what has changed and take that into account as they work to prioritize future Sprints. The Appendix 4.0 Checklist Sprint Review section lists related activities

• Sprint Retrospective Meeting: Gives the team the opportunity to evaluate what went well during the Sprint and what could be improved. Captured as a list including specific lessons learned, action items, etc. with a copy provided to the Portfolio/Program Manager. The Appendix 4.0 Checklist Sprint Retrospective section lists related activities

Scrum leverages four key objects to plan for and deliver useable functionality:

• Product Backlog provides the project goals. It is a prioritized list that contains the features, bug fixes and tasks needed to achieve the project/product objectives. This in the form of a series of User Stories that may be associated with one or more Epics. The Appendix 4.0 Checklist Product Backlog Refinement section lists related activities

• Sprint Backlog lists the Sprint’s User Stories typically associated with a Sprint Theme (e.g., a specific area of functionality, accessibility, etc.). This artifact is created by the PO and the Development Team and is used by the Development Team to identify the tasks that the team plans to accomplish during the current Sprint execution. The Appendix 4.0 Checklist Sprint Planning section lists related activities

• Increment represents potentially useable functionality developed during a Sprint

• Release represents functionality delivered to the customer. A release contains the functionality of one or more increments. The Appendix 4.0 Checklist Release Planning section lists related activities

3.0 Agile Software Development Lifecycle (SDLC) at DLA

The Agile SDLC includes both initial planning and preparation and repeatable lifecycle activities that occur with each Sprint. The Agile SDLC at DLA can be considered a hybrid approach due to potential required Department of Defense (DoD)/DLA processes/artifacts (Agile constraints) and tailoring applicable to the needs and realities of a specific program/project. Both the need for DoD/DLA processes/artifacts and tailoring are dependent on each program/project’s size, scope, and context. Points of contact for Programs utilizing or considering utilizing the DLA Enterprise Platform are listed in Appendix 12.

3.1 Agile Planning and Preparation – Sprint 0

During the initial planning and preparation phase, which occurs prior to the start of the first Sprint, sometimes referred to as Sprint 0, steps need to be taken to ensure the Scrum Team is ready to begin development Sprints. The following steps should be considered for all Scrum teams whether new or existing with the caveat that existing teams may only need to validate where appropriate:

• Identify the Scrum Master, Scrum Master then:

o Determines and plans for Agile training needs (see Appendix 5.0, Training Checklist) o Prepares the virtual and/or physical team space as appropriate o Determines any overall required documentation (e.g., Charter, Scope, etc.)

o Sets up development environment/tools (in coordination with Development Team)

• Identify the Product Owner, Product Owner then:

o Identifies key customers/stakeholders o Determines the overall vision/goals of the Program/Project o Develops the initial Product Backlog (e.g., Epics, User Stories) o Determines initial applicable release planning o Ensures that User Acceptance Testing (UAT) is incorporated into each Sprint and/or conducted as a separate event where warranted; for more details regarding this decision see Appendix 6.0 Test Checklist

• Determine Development Team roles and candidates (e.g., Design, Coding, Test, etc.)

• Determine initial list of both required documents/artifacts (Agile constraints) and documents/artifacts deemed useful by the Development Team

These steps are sequenced in the rough order in which they typically occur with steps listed underneath each Agile role that typically perform the steps. For example, the Scrum Master would typically determine and plan for Agile training needs. The step sequencing and typical key roles are presented for guidance only, and management teams should tailor as they deem appropriate.

3.2 Sprint Lifecycle and SDLC

The Sprint lifecycle activities support the four key meetings that repeat for each Sprint:

• Sprint Planning Meeting

• Daily Scrum Meeting

• Sprint Review Meeting

• Sprint Retrospective Meeting

In addition, Sprint Release meetings can be utilized for programs and projects that are planning formal releases where each release may include more than one Sprint. Figure 1 depicts the four key meetings that occur for each Sprint and the product development activities that occur between the Sprint Planning Meeting and the Sprint Review Meeting. The figure emphasizes the importance of high visibility and continuous feedback to the Agile process allowing for flexible adaptation to changing requirements.

Figure 1: Agile Sprint Lifecycle

3.2.1 Sprint and Release Planning

The PO is primarily responsible for Sprint and Release Planning. For a new Agile program or project, planning proceeds through four levels from strategic to tactical:

• Vision

• Roadmap

• Release

• Sprint

The DLA IT Modernization Strategy should be considered throughout the entire planning process. A vision statement is often used to describe the effort’s overall objective. The statement would typically include the following items: customers, high level functionality being provided, need it satisfies, and how it is different from the status quo. The PO meets with the customers to develop and refine the vision. Unlike the Roadmap, Release, and Sprint content, the vision statement rarely changes once the project has started.

A Roadmap is a high-level depiction of the planned releases with each release made up of one or more Sprints that achieve a goal (or Epic) needed to achieve the project’s vision. A Roadmap is a living depiction designed to be regularly refined and adjusted, and it can be started at a very high conceptual level with more detail added later. An Epic describes functionality that cannot be achieved within a single Sprint. One Epic may be associated with one Release, or an Epic may span across multiple Releases depending on the size and scope of the Project. A high-level Roadmap typically depicts the following information and can be depicted graphically:

• Releases

• Delivery Date Target (e.g., Quarter, Year)

• Goal or Epic release supports

• Sprints

A Release is functionality deployed to the customer. A Release contains “Ready to deploy” functionality from one or more Sprints. Sprints may be bundled into a Release so that related functionality is included in one Release to facilitate release planning with the customer and end-users or for other reasons.

Figure 2 depicts an example of the relationship between Epics, Sprints, and Releases. Programs should tailor the use of Epics, Sprints, and Releases to fit the specific needs of their Program.

Figure 2: Epic, Release, Sprint Hierarchy Example

As part of Sprint and Release planning, Programs may consider defining and utilizing a Minimum Viable Product (MVP). As described in the Government Accountability Office (GAO) Agile Assessment Guide, “the MVP is a concept popularized in Eric Ries’ 2011 book, The Lean Startup, the MVP is a version of a working product that allows teams to learn from and interact with their customer with the least amount of effort.” As such the MVP is typically used for a new IT Product or solution and its use may not be applicable to all IT development efforts. See the GAO’s Agile Assessment Guide for additional information.

To prepare for a Sprint, the PO first creates or refines an existing Product Backlog, which is a list of User Stories created in coordination with the customers. The PO then works with the customer to prioritize the Product Backlog. The creation and prioritization of the Product Backlog (aka Backlog Grooming) may take some and require multiple workshops or sessions with the customers depending on the nature and complexity of the Program/Project; the PO should plan accordingly.

User Stories typically take the following statement format:

“As {role} I want to {business function} so that I can {business value}.”

The following table provides examples of User Stories with associate Acceptance Criteria and Story Points listed in an Agile Backlog.

# Backlog Item (User Story) Acceptance Criteria Story Point

1 As a system user, I want to make the fund code a required entry so that it is not accidently left blank.

The system will display an error message and not allow the fund code entry to be saved without being populated.

2 As an Account Manager, I want the ability to record project type so that accounts are recorded correctly.

The system will allow Account Manager(s) to record only approved project types.

3 As an Account Manager, I want the ability to transfer costs between accounts, so that costs can be correctly expensed.

The system will allow Account Manager(s) to transfer costs between accounts without errors and notify the Account Manager(s) of potential errors.

4 As a Project Manager, I want the ability to sort by project type, so that similar projects can be compared.

The system will allow Project Manager(s) to sort by project type without errors and run comparison reports.

Table 2: User Story Examples

The following are key points applicable to User Stories:

• User Stories are needed to depict high level requirements and to track Sprint completion and the projects “burndown” rate

• User Stories should have an acceptance criterion for validation completion determined by the customer in coordination with the PO and the Development Team that ensures its functionality is completed. The acceptance criteria are specific to each User Story and forms the basis for the required Sprint testing defined in the Definition of Done

• Story Points are a commonly used estimation technique. Story Points estimate the complexity of each User Story and are determined in coordination with the Development Team. The points are used to help estimate how much work can be accomplished in each Sprint. Various methods can be used to estimate Story Points. See the Department of Defense Agile Metrics Guide for more information

• Benefits of well-written User Stories include:

o Increases value delivered by focusing on small and immediate customer needs o Provides understanding to the development team and focus on customer requirements o Increases collaboration; this reduces risk and cost increases, while increasing transparency o Used to create effective test cases

• Challenges faced when creating effective User Stories:

o User Stories are too big, or not concise and cannot be completed in one or two Sprints o User Stories are unclear to the development team or PO, there is no acceptance criteria, and the development team struggles to understand the scope of the story. This can cause a waste of time during the Sprint o Lack of conversation/input regarding User Story development and refinement

For more details on Sprint information, see Appendix 4.0, the Scrum Checklist.

Sprints contain useable functionality that typically represent completion of a Theme consisting of User Stories. The Sprint’s Theme depicts the Sprint’s overall goal and is used to ensure that the Sprint’s User Stories logically support the Sprint’s goal and that the Sprint represents potentially useable functionality.

The Sprint Planning Meeting is attended by the Scrum Team and is typically led by the PO. The overall goal of the Sprint Planning Meeting is to have an agreed list of User Stories that will be completed by the Development Team during the Sprint in accordance with each User Story’s acceptance criteria and the overall quality standards that apply to all Sprints described by the Definition of Done. The Definition of Done’s quality standards include testing/validation types (e.g., User Acceptance, System, Section 508, etc.) required for the Project. Sprint Planning Meeting inputs, planning considerations and outputs are depicted below:

• Sprint Planning Meeting Inputs:

o Prioritized Product Backlog in User Story Format with Acceptance Criteria for each

Story o Sprint duration (important for Sprint durations to remain consistent) o Potential Sprint Theme (if applicable)

• Planning Considerations during meeting:

o Integrating DevSecOps practices that ensure cybersecurity and operations considerations are applied throughout the SDLC o To agree upon User Stories that can be completed during the Sprint, the team scopes items in the potential Sprint Backlog using Story Points (or another method), prior Sprint Velocity (if applicable), and any known constraints o PO provides feedback from stakeholders on product, deadlines, etc.

o Input from other teams or subject matter experts as applicable (e.g., incorporation of

UAT into Sprints)

• Sprint Planning Meeting Outputs:

o List of User Stories to be completed during Sprint (Sprint Backlog) o Input for adjustments to Roadmap as applicable o Validation that UAT will be incorporated into Sprints (UAT should only be held where warranted; see Section 3.2.3 and Appendix 6 for more details)

3.2.2 Daily Scrum

Although the Daily Scrum meeting can be initiated prior to the start of a Sprint, it’s critical that the Scrum Team frequently communicates using a consistent format once the Sprint has started following the Sprint Planning Meeting. The Daily Scrum Meeting is chaired by the Scrum Master and typically time-boxed to 15 minutes where each team member responds to three questions:

• What have you done on the project since the last meeting?

• What will you do between now and the next Daily Scrum?

• With what do you need help?

This meeting frequency, conciseness, and action-oriented format is needed to ensure Sprints continue to make progress and problems and impediments are quickly resolved. The Scrum Master ensures members stick to the meeting format and should schedule separate meetings with appropriate attendees, if needed, for deeper discussion involving issues that can’t be rapidly resolved during the meeting. The Scrum Master may also accept an action item for resolution as appropriate.

3.2.3 Sprint Development and Review

The Sprint Development Team begins working on the Sprint immediately following the Sprint Planning Meeting. The Team should refer to their Portfolio/Program’s approved Systems Engineering Plan (SEP) if applicable to support the determination of required and potentially useful documents/artifacts. Otherwise, the Team may refer to the J62 SEP maintained by the Office of the Chief Engineer (J62L). The Team is self-organized and dynamic and is responsible for determining:

• Required documents/artifacts in compliance with DoD/DLA policies and procedures (constraints)

• Useful documents/artifacts (that are not required)

• Needed roles and who will fill each role

• Team progress

• When Sprint User Stories are completed in accordance with the acceptance criteria in coordination with the PO

The Sprint Development Team follows the SDLC lifecycle phases to build useable functionality for each User Story. The Team determines which User Stories can be worked on concurrently.

The Team incorporates required DoD/DLA deliverables into their lifecycle. The Team may also elect to develop and use items that they may find useful but are not required. For these items the Team decides on the needed format, formality, etc., and is responsible for complying with applicable DLA Records Management Guidelines.

An overview of typical lifecycle phases is provided below:

• Design: During the design phase of the SDLC, the software architects and software developers will architect the Sprint solution and update the impacted enterprise architecture models and required/useful design documents that are in scope for the current Sprint. Requirements traceability to the Sprint’s User Stories typically begins during design

• Develop: During the Development phase the software developers, system configurators, customer representative, security and any other resources required to complete the tasks will create the required artifacts to build the solution. This may include, but is not limited to Code, Configuration files, Network connections, endpoints or customizing data. Key development objects/artifacts will:

o Conform to the designed solution o Comply with governing policy covering style, quality, security, accessibility, Quality

Assurance (QA) policy, etc.

o Be fully tested in compliance with coverage requirements as prescribed by application development policy o Be covered by a review document be it a code review, configuration review or additional review required by the owning division

For potential technical activities refer to Appendix 8.0.

• Test: During the testing phase, the testers will develop or amend the project test plan based on the User Stories completed during the Sprint. Teams may consider the use of automated test tools per DevSecOps principles.

o Testing will be considered complete for each User Story when the associated User

Story acceptance criteria has been completed in accordance with the required testing described in the Definition of Done o Team should incorporate UAT into the Agile Sprint and only consider UAT as a separate event when warranted (e.g., exceptionally complex/critical functionality, introduction of significant new technology, prior to a release that incorporates multiple Sprints, etc.)

See Appendix 6.0 Test Checklist, Appendix 7.0 Test Readiness Review Checklist, and Appendix 10.0 Defects Report for additional information.

• Sprint Review Meeting: The PO schedules the Sprint Review Meeting on the last day of the scheduled Sprint duration. The objective of the meeting is to demonstrate achieved functionality. Key points regarding this meeting are:

o Attended by Scrum Team and other Stakeholders/Customers that PO deems appropriate to invite o Only functionality (User Stories) that are completed (passed acceptance criteria) should be demonstrated/presented o When UAT has been incorporated into the Sprint, UAT results are typically finalized/recorded at the Sprint Review Meeting o Functionality/User Stories that are not completed should not be presented o Meeting is time-boxed to typically four hours

See Appendix 9.0 Operational Readiness Review (ORR) Checklist and Appendix 11.0 Top-Level Schedule for additional information.

The PO will record completion of User Stories in the Sprint and Product Backlogs and update the Roadmap as appropriate following the meeting. User Stories that have not been completed will be considered for inclusion in the next Sprint at that Sprint’s Sprint Planning Meeting. The completed Sprint functionality will be included in the appropriate Release and deployed to a production environment as scheduled in accordance with DLA Release Management policy (Info Ops Support - s8351.01-01.pdf - J6_Standard_Operating_Procedures (dps.mil)).

3.2.4 Sprint Retrospective

The Scrum Master schedules the Sprint Retrospective Meeting with the Scrum Team following the Sprint Review Meeting. The purpose of this meeting is to identify what went well during the Sprint and what can be improved. This typically takes the form of a potential improvement list with associated action items. It’s important to ensure that improvements are included in upcoming Sprints to ensure continuous improvement.

https://dlamil.dps.mil/sites/InfoOps/IOS/J6%20SOP%20Repository/Forms/J6%20Standard%20Operating%20Procedures.aspx?id=%2Fsites%2FInfoOps%2FIOS%2FJ6%20SOP%20Repository%2Fs8351%2E01%2D01%2Epdf&parent=%2Fsites%2FInfoOps%2FIOS%2FJ6%20SOP%20Repository

Scrum teams typically become more efficient as they work together completing Sprints and continuously improve. The following are some tools that can be used to measure Sprint success and Scrum progress.

The use of Burndown charts visually represents to the stakeholders and the development team what tasks have been completed during the Sprint and how many might remain. This is a great tool to use to forecast the scope of future Sprints. The Burndown chart below makes it clear how much value a Sprint has already delivered and how close a project is to completing its commitment to the customer.

Figure 3: Example of a Burndown Chart

Sprint Velocity charts measure how many Story Points were completed by the team, on average, over the past few Sprints. It can be used to predict the team’s output in the upcoming Sprints.

Figure 4: Example of a Sprint Velocity Chart

Measuring Velocity is a powerful tool because it is a results-based metric, i.e., how much value was delivered to customers in a series of Sprints. It is important to note not to compare Velocity across teams because Story Points and the “Definition of Done” can vary between teams.

Lead time measures the total time from the moment a story enters the system (in the Backlog), until it is completed as part of a Sprint, or release to customers. It measures the total time for a requirement to be realized and start earning value. Lead time is important because it measures the entire efficiency of the Agile system from end to end. By reducing lead time, the entire development pipeline is becoming more efficient.

Cycle time is a subset of lead time, i.e., it measures the time of a task to go from “started” or “in progress” to “done”. This is a very simple metric that can raise the red flag when items within Sprints across your entire system are not moving forward.

3.3 Challenges

When adopting Agile, like any significant change, there will be some resistance and challenges.

Agile methodology is a change to the way traditional development has been done and a change in team culture and dynamics. It represents a change to the way people think and their habits of developing software. Training and team coaching are keys to a successful Agile implementation.

Agile Scrum relies heavily on self-organizing teams with strong support from management with increased communication and collaboration. The need for daily communication sessions is very important. From the Team perspective, requirements need to be clear, concise, and able to be completed in the time allotted. The challenge is to keep the team and the customer engaged in every step. It is especially important to reach out to and engage with support teams outside of the Scrum Team (e.g., Architecture, Cyber, etc.) early to ensure any help and support is available when needed.

3.4 Benefits

There are several benefits to using the Agile methodology:

• Early Delivery of Working Software o Faster, more consistent deployment of products/updates o Continuous customer involvement/feedback o Improved quality of overall product/ application o Reduced overall cost

• Better Visibility of Process and Team Success o Sprint Issues are highlighted and worked early o Sprint Team Metrics are inputs for future Sprints o Multiple Sprint Team Metrics are inputs for Portfolio Management

• Improved Change Management o While a Sprint cycle is locked, prioritized User Stories cannot be changed o A new requirement may only need to wait until the next Sprint cycle

• Improved Team Dynamics o Project teams work more closely to help deliver product updates o Teams achieve a greater level of transparency, alignment, interaction, accomplishment, success, ownership, and fun o Self-managing teams resolve issues with less management oversight

3.5 Lessons Learned

Studies have shown that projects using Agile methodologies have higher success rates than Waterfall as measured by project completion including on time, on budget, on target (scope), on goal, value, and user satisfaction. The key to implementing Agile is adaptability and continuous improvement. The following lessons learned should be considered when adopting Agile:

• Per DevSecOps principles, the PO and Development Team should involve security and operations considerations early in the lifecycle rather than as an afterthought. The release process should support the efficient bundling/release of functionality appropriate to the project.

• Learn by doing; consider running a trial Sprint to get the team used to the Agile methodology

• Consider utilizing Agile coaches to support new Scrum Masters

• The skill and experience of the Development Team members in performing their roles

(e.g., coding, testing, etc.) is important for all methodologies including Agile

4.0 Tools

There are various tools to support Agile-managed programs/projects. The table below identifies only a few of the tools available for use and their roles.

Tool Name Role of Tool Comments

JIRA Collaboration, Sprint management

ServiceNow Collaboration, document storage, backlog management, programs/projects management

Azure DevOps Spans SDLC; enables Agile and DevOps capabilities

Table 3: Agile Tool Examples

5.0 Agile Versus Waterfall

Agile and Waterfall are both well-known project management methodologies that have been around for years and suitable for various forms of application development projects. The use of either method is dependent on the team culture and application being proposed.

Waterfall is linear with a formal process flow from project inception to implementation, which requires development teams to complete each phase prior to moving on to the next phase of the project. Agile, however, is more flexible; it allows teams to work separately and on multiple phases of a project at the same time or to take a modular approach to application development.

In Waterfall, planning is done in detail and requirements are gathered at the beginning of a project; any changes to that plan can impact the scope of the project, duration, staffing, and cost.

Agile’s initial planning regarding cost, scope, and timing are conducted at a very high level at the start of the project. However, these initial estimates are supplemented by more specific planning within each iteration (phase/Sprint) of the project. Once the iteration is complete, the plan can be revised as needed.

With the Waterfall methodology, projects are reviewed for status at predetermined milestones and checkpoints. In Agile, application demonstrations for customers and stakeholders are conducted at the end of each Sprint. At that time, any change in requirements or defects can be addressed and implemented, as needed, in later iterations. This contrasts with the Waterfall methodology, where issues, defects, or missed requirements are discovered either very late in the development cycle, or during the predetermined milestones and checkpoints. Therefore, the Waterfall methodology results in delayed discovery of items requiring attention.

Agile development encourages collaboration within each iteration (phase/Sprint) during the testing; customers will work closely with developers and technical staff. In contrast, with a Waterfall project management method, customers and technical staff work separately. Tasks are monitored by project management, who report status to the project management office (PMO).

Many organizations have opted to use a combination of Agile and Waterfall methodologies, better known as a Hybrid approach. This incorporates the more flexible structure of Agile and uses a form of Waterfall within each iteration (phase/Sprint). There are a couple reasons to go with a Hybrid approach. One is when developing applications in a highly regulated industry where documentation, security, and time to delivery are a priority. Another is team culture;

Waterfall is a widely used development methodology and people are used to the process.

Therefore, the use of Waterfall within the construct of an Agile framework can provide some of the development efficiencies that Agile has to offer and the need for due diligence to process that a government application environment requires. Using a Hybrid approach can ease them into the Agile methodology and educate them along the way. Table 3 provides a comparison between Waterfall, Agile and the Hybrid methodologies with suggestions on what to consider when starting a project.

Waterfall Agile Hybrid Project Type A physical product, highly structured Software Tech-focused project where development is just part of the bigger picture.

Scope Any size with a defined scope

Small-to-medium, iterative (but can be scaled)

Any project size or scope

Budget Fixed Flexible Flexible, but with an understanding of boundaries

Deadlines Work toward planned milestones

Work in Sprints or iterations with the flexibility to push tasks to a future Sprint when needed

Can use Sprints and milestones in any order that works for the project

PM Role A traditional PM who sets the plan, monitors progress, and follows up on tasks throughout the project

Scrum does not define a Project Manager role since many of these traditional PM responsibilities are redefined in the SM and PO roles. PMs who will be fulfilling SM and/or PO roles should be trained and/or certified in these roles

A project leader who creates and follows up on tasks but gives the team space to get work done during Sprints

Team • Cross-functional

• Works on several projects at the same time

• 100% dedicated

• Able to self-organize

• Agile-trained

• Experienced collaborators

• Multitasking with time to work on the project

• Able to self-organize

• Experienced with Agile

• Collaborative in nature

Stakeholders • External and/or internal

• Engage at milestones or when needed

• Internal

• Engage daily

• External and/or internal

• Engage often (not daily) or when asked

Planned Communications

Task- and milestone-level updates with project status report and meeting

Scrum ceremonies (Sprint planning, daily standups, Sprint demonstrations, and Sprint retrospective)

Combination of needed Scrum ceremonies and regular status updates

Table 4: Waterfall, Agile and Hybrid Comparison

6.0 Agile Playbook and Systems Engineering Plan (SEP) Relationship

Systems Engineering (SE) is a systematic approach for the design, development, and implementation of a system. SE balances design, cost, schedule, and performance while involving a certain amount of risk. The purpose of the SEP is to provide guidance to the SM when conducting SE activities. SE helps ensure successful development by using a systematic analytic and technical process throughout the lifecycle.

J62 Enterprise Portfolios are required to create a SEP for their programs and/or projects. No matter what SDLC methodology used, the SEP will provide guidance on the documentation needed to stand up an application in DLA. This Playbook presents Agile best practices that align with the SE perspective. The intent is to also align the Playbook with the SEP.

When developing a project plan the team should consider the following for inclusion in the SEP:

• Integrated Master Plan/Integrated Master Schedule (IMP/IMS) or Sprint work breakdown schedule

• Project Product Backlog

• Risk Management Framework (RMF)

• Risk and Issue Management Matrix

• Other performance metrics and measurements

It is important that the SE group is involved early to facilitate in the application implementation process.

Appendix 1.0 References

1) DoDI 5000.87, Operation of the Software Acquisition, October 2, 2020

2) Standish Group Chaos Report, 2020

3) Carnegie Mellon University Software Engineering Institute (http://www.sei.cmu.edu)

4) Government Accountability Office, Effective Practices and Federal Challenges in

Applying Agile Methods, GAO-12-681, July 2012

5) MITRE Defense Agile Acquisition Guide (https://www.mitre.org/about/corporate-overview)

6) Handbook to Implement Agile in DoD, December 15, 2010

7) Agile Systems Engineering (AiDA) (mitre.org) (https://aida.mitre.org/agile/agile-systems-engineering/)

8) User Stories - Examples and Template, Atlassian

9) 17 Useful User Story Examples to Get You Started, Justinmind

10) Challenges with User Stories (seilevel.com)

11) Program Executive Office (PEO) J62 Systems Engineering Plan (SEP), version 2.0, August 2019

12) GAO Agile Assessment Guide, GAO-20-590G, September 2020

13) Department of Defense Agile Metrics Guide, version 1.1, September 23, 2019

14) Application Release and Deployment Management Standard Operating Procedure, DLAHQ J6 SOP 8351.01-01, April 25, 2016 https://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects/ http://www.sei.cmu.edu/ https://www.mitre.org/about/corporate-overview https://www.mitre.org/about/corporate-overview https://aida.mitre.org/agile/agile-systems-engineering/ https://aida.mitre.org/agile/agile-systems-engineering/ https://www.atlassian.com/agile/project-management/user-stories https://www.justinmind.com/blog/user-story-examples/ https://seilevel.com/requirements/challenges-with-user-stories

Appendix 2.0 Acronyms

BS Business Scenario

CAPE Cost Assessment and Program Evaluation

CCWG Configuration Control Working Group

CDR Critical Design Review

CM Configuration Management

CS Customizing Size

DevSecOps Development Security and Operational

DLA Defense Logistics Agency

DoD Department of Defense

FIPS Federal Information Processing Standards

FS Functional Specification

GAO Government Accountability Office

IMP Integrated Master Plan

IMS Integrated Master Schedule

IT Information Technology

KM Knowledge Management

KPP Key Performance Parameters

LMS Learning Management System

MVP Minimum Viable Product

ORR Operational Readiness Review

OTA Operational Test Authority

OUSD(C) Office of Under Secretary of Defense (Controller)

PEO Program Executive Officer

PICL Privacy Security Checklist

PM Project Manager

PMO Project Management Office

PO Product Owner

PPSM Ports, Protocols, Services, Management

QA Quality Assurance

RFU Ready for Use

RMF Risk Management Framework

SAFe Scaled Agile Framework

SD Specific Development

SDLC Software Development Lifecycle

SE Systems Engineering

SEP Systems Engineering Plan

SM Scrum Master

STIG Security Technical Implementation Guides

TRR Test Readiness Review

TS Technical Specification

UAT User Acceptance Testing

UI User Interface

Appendix 3.0 Definitions

Backlog: An ordered list of user-centric requirements that a team maintains for a product.

Burndown Chart: A graphical representation of the work remaining versus the time left in the timebox.

Definition of Done: Agile teams make an agreement about what constitutes potentially shippable product, called the Definition of Done. The Definition of Done serves as a contract the delivery team writes with its stakeholders, as well as the team’s standard of excellence.

Definition of Ready: A team’s checklist for a user-centric requirement that has all the information the team needs to be able to begin working on it.

Demonstration: At the end of a Sprint the team demonstrates functionality that meets the Sprint objectives. Demonstrations involve end users and/or product owners to run through the application capabilities.

DevSecOps: The connection of three disciplines: development, security, and operations. The seamless integration of security testing and protection throughout the software development and deployment lifecycle.

Epics: A body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers or end-users.

Iteration: A timeboxed cycle of development on a product or deliverable in which all the work that is needed to deliver value is performed.

Kanban Method: An Agile method inspired by the original Kanban inventory control system and used specifically for knowledge work.

Minimum Viable Product (MVP): A version of the product with just enough features and functionality to be used by the customer who can then provide feedback for future product development.

Product Backlog: An ordered list of user-centric requirements that a team maintains for a product.

Product Persona: Agile Product Personas represent characteristics of the people that are most likely to use the product.

Retrospective: A regularly occurring workshop in which participants explore their work and results to improve both process and product.

SAFe: The Scaled Agile Framework is a set of organizational and workflow patterns for implementing Agile practices at an enterprise scale.

Scrum: An Agile framework for developing and sustaining complex products, with specific roles, events, and artifacts.

Scrum Master: The coach of the development team and process owner in the Scrum framework.

Removes obstacles, facilitates productive events, and defends the team from disruptions.

Spiral: The Spiral model is a systems development lifecycle method used for risk management that combines the iterative development process model with elements of Waterfall. The Spiral model is used by software engineers and is favored for large, expensive, and complicated projects.

Sprint: Describes a timeboxed iteration in Scrum.

Timeboxed: A fixed period, for example, 1 week, 2 weeks, 3 weeks, or 1 month.

User Stories: A User Story is the smallest unit of work in an Agile framework stated in an informal format to explain a software feature written from the perspective of the end user.

Velocity: A measure of how many Story Points is completed by a Scrum team during a Sprint.

Appendix 4.0 Scrum Checklist

SCRUM CHECKLIST

YES/NO Checklist Items Comments

ASSIGNMENT OF ROLES

Purpose is to establish a plan and goals that the Scrum Team and organization can understand and communicate

Identify & Assign Attendees:

Product Owner (list name) Scrum Master (list name) Development Team Members (list names) Functional Stakeholders (list names)

SPRINT TEAM AGREEMENTS

Has the team addressed the rules of engagement?

Have the collaboration methods been identified (Microsoft (MS) Teams, Government Zoom, etc.)?

Has the goal/expected benefit of the application been identified?

Have the requirements been gathered?

Has the team agreed on the Sprint team schedule of events (to be plotted on the application roadmap)?

Who is assigned as the backlog documenter? *Note: The Product Owner will be responsible for prioritizing the backlog

Is there a Sprint team agreement in place (capturing the above)?

DEFINE SCOPE & PRODUCT

BACKLOG

Confirm what will be included within the iteration and how the team will build the functionality

Have the user stories/requirements for the Minimum Viable Product (MVP) been identified?

Decomposition to granular requirements for User Stories

Are there any business process SOPs, design, or architectural products?

With which systems or applications will the application interact?

Are the User Stories being developed?

Are the Product Personas identified? E.g., as a <persona> ("Loan reviewer"/"Procurement Manager"...)

DEFINE SCOPE & PRODUCT

BACKLOG

Confirm what will be included within the iteration and how the team will build the functionality

Are the Product Themes and Epics identified?

Is the Product Backlog prioritized?

Does the Product Backlog have Ready

Stories for the next 2 Sprints?

Do the Ready Stories have acceptance criteria and estimates?

Are the transition requirements identified and included in the Backlog?

RELEASE PLANNING

Are there any potential constraints to deploying the application?

Is there an initial assumed Sprint velocity?

Is Length of Sprint established? Usually 2 weeks; up to 4 weeks Do the Items in the Product Backlog have point estimates? (At least for three-month horizon)

Is there a Product Vision statement?

Is the Project Roadmap visualized/plotted?

Are the releases indicated in the roadmap?

Is the Initial Product Burndown plotted?

Are the resource requirements identified

(e.g., Application Software, Tools, etc.)?

Is a Risk/Assumptions Register initiated for the project?

OPERATIONS/MAINTENANCE TASKS

How will the Backlog be managed?

What will be the Coding/Development Environment? Are they available?