Instruction_Manual_102-01-004-01_DHS_Agile_Development_and_Delivery_for_IT.pdf

DHS Agile Development and Delivery for IT

Instruction Manual # 102-01-004-01 Revision #00 ii

Testimonial

“The Department of Homeland Security is visionary for its embrace of Agile methods. The private sector uses Agile to deliver software faster, better, and cheaper than their competitors. DHS has realized the country can’t afford for them to do anything less.”

- Jeff Sutherland, CEO of Scrum Inc. and co-creator of Scrum iii

TABLE OF CONTENTS

1. Introduction

1.1 Purpose and Scope

1.2 Why Agile?

1.3 Document Structure

2. Agile: The Basics

2.1 Understanding the Agile Approach

2.2 Agile Methodologies and Frameworks

2.2.1 Selecting and Preparing to Use a Methodology

2.3 Agile Methodologies and Practices: A Comparative Overview

2.3.1 Selecting the Right Agile Practices for the Project

2.4 Agile Teams, Roles, Responsibilities, and Resources

2.4.1 Program Manager

2.4.2 Project Manager

2.4.3 Product Owner

2.4.4 Development Team

2.4.5 Test Team

2.4.6 Agile Coach

2.4.7 Additional Expertise

2.4.8 Oversight Bodies

2.5 Success Factors and Risks

2.5.1 Stakeholder Engagement

2.5.2 Contracting Environment

2.5.3 Common Reporting Techniques and Metrics

2.5.4 Resource Availability

2.6 Culture Change

3. Agile and the Project Life Cycle

3.1 Integrating Agile Practices into the DHS IT Governance Frameworks

3.1.1 Assessing the Project

3.1.2 Identifying Opportunities to Apply Agile Practices

3.2 Options for Tailoring the Systems Engineering Lifecycle Activities iv

3.2.1 Reference: Agile Terms as Used in this Instruction Manual

3.2.2 Agile Practices and Data Tracking

3.2.3 Project Strategy and Structure

3.2.4 SELC Tailoring Plan Development

3.3 SELC Tailoring Considerations

3.3.1 SELC Tailoring Communication

4. Applying Agile within DHS

4.1 Establishing the Project Plan

4.1.1 Emphasizing Flexibility in Agile Project Planning

4.2 Building the Agile Project Team

4.2.1 Agile Team Composition

4.2.2 Agile Team Training

4.2.3 Agile Team Operations and Communications

4.3 Agile Contracting Considerations

4.3.1 Government-wide Contracting Guidance to Support Agile Development

4.3.3 Contract Performance Metrics, Vendor Qualifications, and Related Challenges

4.4 Establishing Tools, Processes, and Metrics

4.4.1 Agile Management Tools

4.4.2 Agile Project Management Processes

4.4.3 Agile Project Metrics

5. Applying Agile: Tips and Practical Lessons

5.1 Tips for Preparing to Run an Agile Project

5.1.1 Get and Maintain Leadership Buy-In

5.1.2 Identify Interdependencies and Plan to Manage Them

5.1.3 Plan for Project Team Resources and Processes

5.2 Tips for Preparing and Organizing the Agile Project Team

5.2.1 Team Training and Development

5.2.2 Understanding and Fulfilling Roles

5.2.3 Establishing Communication Methods and Standards

5.2.4 Identifying and Working with an Agile Coach

5.2.5 Beginning with a Pilot Project

v

5.3 Tips for Contracting for Agile Projects

5.3.1 Structuring the Contract

5.3.2 Contract Incentives for Agile Projects

5.3.3 Contract Performance Assessment

5.3.4 Vendor Selection

5.4 Tips for Executing the Agile Project

5.4.1 Determining Focus and Rhythm for Meetings

5.4.2 Keeping Focused on the Work

5.4.3 Maintaining Discipline in Team Processes

5.4.4 Scope of Control

5.4.5 Integration Management

5.5 Conclusion

Appendix A: The Agile Manifesto .................................................................................................................................. A-1

A.1 12 Principles behind the Agile Manifesto............................................................................................... A-2

Appendix B: Agile Methodologies ................................................................................................................................. B-1

B.1 Scrum .................................................................................................................................................................... B-2

B.2 Kanban ................................................................................................................................................................ .. B-6

B.3 Extreme Programming (XP) ........................................................................................................................ B-8

B.4 Lean Software Development .................................................................................................................... B-12

B.5 Disciplined Agile Delivery (DAD) ........................................................................................................... B-15

B.6 Scaled Agile Framework® (SAFe®) ........................................................................................................ B-17

Appendix C: Metrics and Reporting ............................................................................................................................ C-1

C.1 Agile Metrics ....................................................................................................................................................... C-1

C.2 Agile Reports ...................................................................................................................................................... C-5

C.2.1 Backlog Reports ...................................................................................................................................... C-5

C.2.2 Release Plan and Progress Report ................................................................................................... C-6

C.2.3 Burndown Charts and Burn Rate Reports .................................................................................... C-6

C.2.4 Test Reports .............................................................................................................................................. C-6

Appendix D: Training and Additional DHS Resources ........................................................................................ D-1

Appendix E: Lexicon .......................................................................................................................................................... E-1

Appendix F: Acronyms and Abbreviations ............................................................................................................... F-1 vi

Appendix G: PM Checklist ................................................................................................................................................ G-1

FIGURES

Figure 2-1: Waterfall Management Model Figure 2-2: The Agile Scrum Framework as a Time-Based, Iterative Methodology Figure 2-3: Sample Project Practices and Methodology Selection Process Figure 3-1: Agile Practices Most Commonly Used in DHS Figure A-1: Manifesto for Agile Software Development ...................................................................................... A-1 Figure A-2: Twelve Principles Behind the Agile Manifesto ................................................................................ A-3 Figure B-1: Agile Development Timeline ................................................................................................................... B-1 Figure B-2: The Agile Scrum Framework at a Glance ........................................................................................... B-3 Figure B-3: Kanban Work Item Board Sample ........................................................................................................ B-7 Figure B-4: Extreme Programming Planning and Feedback Loops ................................................................ B-9 Figure B-5: Lean Software Development Principles .......................................................................................... B-12 Figure B-6: Lean Software Development Along Product Lifecycle .............................................................. B-13 Figure B-7: Agile Scrum Framework Big Picture ................................................................................................ B-20

TABLES

Table B-1: Kanban – Scrum Characteristics Comparison ................................................................................... B-6 Table B-2: Extreme Programming Activities ........................................................................................................... B-9 Table B-3: Five Key Values of XP ................................................................................................................................ B-10 Table B-4: Five Primary Roles in DAD ..................................................................................................................... B-15 Table B-5: SAFe Program-Level Team Members ................................................................................................. B-18 Table C-1: Common Agile Metrics ................................................................................................................................ C-1 Table C-2: Earned Value Management Metrics ....................................................................................................... C-5

1. INTRODUCTION

1.1 Purpose and Scope

The purpose of this Instruction Manual is to provide Department of Homeland Security (DHS) Program and Project Managers (PM) with guidance to support the implementation of Agile Information Technology (IT) development as outlined by DHS MD/Instruction 102-01-004 Agile Development and Delivery for Information Technology.1 Although Agile practices are expanding into other areas, this Instruction Manual focuses on software development. It helps PMs build upon best practices and experience from industry, federal government, and recent DHS implementations of Agile methodologies. This guidance is intended to enhance understanding of why Agile is the preferred approach to federal IT development, and to provide a starting point for increasing DHS-wide application of and expertise in Agile methodologies. This Instruction Manual is intended to help PMs and other key stakeholders understand how Agile IT development satisfies the requirements of the Systems Engineering Life Cycle (SELC) (as established by DHS MD 102-01-103) to support individual IT project needs, while meeting the intent of the 25 Point Implementation Plan to Reform Federal Information Technology Management,2 Contracting Guidance to Support Modular Development,3 and other federal guidance on improving IT development and acquisition.

To mitigate some of the challenges associated with delivering usable IT capabilities in a timely manner, the Agile Development and Delivery Instruction identifies Agile as the preferred approach for all IT programs and projects, when appropriate. This conforms to the practice of delivering finalized working software to users in discrete increments within shortened time frames of six months or less for ongoing projects and six to 12 months for initial delivery of new projects. Hence, this guidance is consistent with the concept of modular development as outlined in the 25 Point Implementation Plan and the Digital Services Playbook, which place a relatively short “time box” around a project or project segment in which to plan, design, develop, test, and implement a capability.

As this is a Instruction Manual and not an encyclopedia, it avoids highly detailed instruction and instead presents a practical overview of Agile development methodologies and tools. It also gives the reader directions for applying Agile techniques without dictating a specific “DHS way” for Agile.

The state of the art for applying Agile to improve IT development and delivery continues to evolve, as do techniques and guidance for adapting Agile methodologies to the federal enterprise. This document provides an introduction to Agile concepts, techniques, and experiences intended to help

1 Department of Homeland Security, Agile Development and Delivery for Information Technology, Revision #0, draft, (Washington: Department of Homeland Security).

2 Vivek Kundra, 25 Point Implementation Plan to Reform Federal Information Technology Management (Washington: White House, December 2010), https://www.dhs.gov/sites/default/files/publications/digital-strategy/25-point-implementation-plan-to-reform-federal-it.pdf.

3 White House, Contracting Guidance to Support Modular Development (Washington: White House, June 2012), http://www.whitehouse.gov/sites/default/files/omb/procurement/guidance/modular-approaches-for-information-technology.pdf.

https://www.dhs.gov/sites/default/files/publications/digital-strategy/25-point-implementation-plan-to-reform-federal-it.pdf https://www.dhs.gov/sites/default/files/publications/digital-strategy/25-point-implementation-plan-to-reform-federal-it.pdf http://www.whitehouse.gov/sites/default/files/omb/procurement/guidance/modular-approaches-for-information-technology.pdf http://www.whitehouse.gov/sites/default/files/omb/procurement/guidance/modular-approaches-for-information-technology.pdf

DHS PMs identify and craft program and project management options for applying Agile to achieve greater IT development success. It is based on current best practices, but will continue to evolve as practices change. Appendices in the back of this Instruction Manual , as well as references throughout, provide a more detailed and focused background of proven and emerging Agile practices. They include several resources for learning more about each.

This Instruction Manual complements the DHS Systems Engineering Lifecycle (SELC) Instruction Guidebook (MD 102-01-103-01) by working within its high-level framework without superseding existing federal guidance. Accordingly, this Instruction Manual assists PMs in making informed decisions about applying Agile approaches and tools within the context of DHS acquisition management policies to improve planning efficiency, reduce overall risk, and enable rapid delivery of useful capability. The DHS SELC is the common systems engineering framework used to guide DHS programs and projects in the application of solid systems-engineering discipline. The SELC provides significant detail on systems engineering and its application and execution. Agile is one approach that encompasses the SELC’s flexible framework and can be leveraged as appropriate as part of a DHS acquisition approach. The SELC Tailoring Examples for Selected Types of DHS Acquisition Programs4 provides an example of how an Agile IT program could tailor its systems engineering approach (and how it differs from traditional practices) to more effectively encompass user requirements and produce a product in an Agile manner. Readers should refer to the DHS SELC Instruction Manual or one of its supplemental guides for any systems engineering topic not expressly covered in the DHS Agile Development Instruction Manual.

1.2 Why Agile?

Agile development emphasizes inspecting and adapting, rather than following a plan. Teams deliver functionality incrementally, by releasing small system increments or updates frequently, rather than relying on a single, massive deployment. The Agile approach enables programs to deliver prioritized capabilities to users more quickly. This approach also provides more flexibility than many traditional methods, reducing risk by encouraging changing requirements, maximizing learning, and providing the ability to exploit technology advances in a timely fashion. Agile methodologies achieve this flexibility through iterative, incremental development practices that rely on self-organizing, cross-functional teams of developers, stakeholders, and users. The consistent interaction and partnering of individuals with different perspectives encourages development that is highly flexible and lower risk due to frequent planning, development, and delivery checkpoints. The Agile approach to software development incorporates an inherent cultural change in the way professionals develop and deliver software products by integrating users, testers, and developers and enabling them to directly address challenges together. Properly applied, Agile techniques help teams to develop software more efficiently and effectively, providing better solutions to their customers and stakeholders.

4 Department of Homeland Security, SELC Tailoring Examples for Selected Types of DHS Acquisition Programs, version 1.0, draft, (Washington: Department of Homeland Security, March 2014).

Agile development offers the following benefits:

• Requirements and products move at a rapid pace to realistically accommodate technical advances

• Iterations and requirements are informed by discovery as challenges are resolved

• Solutions are produced in a series of smaller increments to reduce risk and meet evolving needs

• PMs select and apply the specific Agile methodologies that best suit the needs of the program, team, customer, and environment

DHS is working on a number of initiatives to promote Agile/modular development in accordance with the referenced Office of Management and Budget (OMB) direction. These include an Agile instruction, this Instruction Manual , and the SELC Guidance.5 An Agile Center of Excellence and Integrated Product Team are leading these efforts.

An Agile approach provides benefits to minimize risks and increases the probability of acceptable delivery compared to more traditional development processes. Agile development allows for increased flexibility across the life cycle of a project, though it notably does not allow PMs to begin projects without adequate initial project planning. It is important to acknowledge that Agile development projects require appropriate planning both up-front and throughout the project life cycle, so long as the planning does not significantly delay the start of the actual execution.

This Instruction Manual provides information on how to achieve success by implementing Agile techniques for software development at DHS.

1.3 Document Structure

This document is configured both as a basic guide and a reference. It is structured to provide a basic understanding of Agile up-front, with more advanced and detailed reference information organized in the appendices:

• Section 2 provides a brief overview of Agile approaches, along with a brief discussion of the range of Agile methodologies and tools, team roles, and project success factors

5 Department of Homeland Security, SELC Tailoring Examples for Selected Types of DHS Acquisition Programs, version 1.0, draft, (Washington: Department of Homeland Security, March 2014).

How to Get Started with Agile at DHS

This Instruction Manual cannot address everything you want to know about Agile. It does, however, point you to resources of use in your learning process:

• For readers new to Agile, Appendices A and B provide further reading references

• Appendix D identifies some Agile training resources

• Appendices E and F provide reference lists of Agile terms and acronyms

All prospective PMs of Agile projects are encouraged to seek advice from DHS PMs who have training in or experience with Agile. DHS best practices for Agile continue to evolve. This and other resources will be updated as DHS processes mature.

• Section 3 provides information on considerations and options for applying Agile within the context of the established DHS acquisition and systems engineering life cycle frameworks

• Section 4 provides guidance and recommendations on developing Agile projects at DHS, along with lessons learned from experienced PMs within Agile projects

• Section 5 outlines tips and practical lessons for implementing Agile development projects based on DHS experience with Agile to date

Readers who are more familiar/experienced in Agile may find the information beginning in Section 3 of particular value, as the latter sections focus on how to implement Agile specifically within DHS.

Appendices address Agile methodologies commonly used within DHS, tools that can be used to manage Agile projects, and how PMs can generate Agile metrics and reports to support their projects. A brief glossary of common Agile terms is provided in Appendix E. A checklist, providing a top-level set of actions to help PMs shape their Agile approach, is included as Appendix G.

The Agile Development Instruction Manual is a living document. Please submit your feedback, recommendations, and related questions to the Office of Program Accountbility and Risk Management.

2. AGILE: THE BASICS

2.1 Understanding the Agile Approach

Agile is more than a set of techniques, tools, and processes prescribed to improve IT development and address project management challenges. Rather, Agile is a philosophy - a way of thinking about IT projects that is rooted in a basic set of core principles and values.

Although many of the concepts and frameworks relevant to Agile software development have been recognized and discussed for some time, the Manifesto for Agile Software Development,6 published in 2001, is generally recognized as the authoritative collection of tenets that define what is known today as Agile.

The motivation to discover better ways of developing software is rooted in experience with the issues commonly associated with the traditional software development approach known as the “waterfall management model.” The waterfall model breaks the software development effort down into distinct phases (e.g., planning, requirements definition, design, development, testing, and implementation), with the rule that no phase can begin until the previous phase has been completed. The traditional waterfall project management model was designed to ensure compliance with applicable standards (e.g., regulatory requirements and demonstrations/reviews) by providing a review opportunity at each phase transition. It is typically applied to efforts where requirements are completely known up-front and are unlikely to change.

Figure 2-1: Waterfall Management Model

Relying on a waterfall model can unnecessarily hamper progress when applied to software development. In the case of systems where it is not possible to define all requirements completely in advance (which, in reality, is always), where some requirements (e.g., data throughput, numbers of users, and data handling rules) may evolve over the course of the development effort, or where the development team seeks to learn from previous practices and activities and incorporate changes into future development, the waterfall model lacks a simple, efficient mechanism for revisiting and revising requirements to meet current needs. Similarly, the waterfall model lacks an inherent mechanism for identifying and taking advantage of technology advances after the design

6 Kent Beck, et al., “Manifesto for Agile Software Development” (2001), http://Agilemanifesto.org/.

http://agilemanifesto.org/ phase has been completed. Historically, these shortcomings have placed PMs at risk of delivering products tied to outdated requirements or obsolete technology.

IT standards and technology advances over the past several decades have facilitated more reliable interfaces and information transfer between independent IT system components. These advances, along with a better understanding of IT project management, have fueled the adoption of industry practices that focus on frequent delivery of enhanced IT capability in a modular, iterative fashion.

Agile methodologies and project management techniques exploit the ability to deliver small, frequent IT capability improvements iteratively, focusing on continuous improvement based on increased understanding of requirements, lessons learned from previous iterations, and interaction between the customer and developers throughout the project life cycle.

The Manifesto for Agile Software Development is supplemented by 12 key principles, also posted on the Agile Manifesto website at http://Agilemanifesto.org (also see Appendix A). These principles emphasize frequent, iterative software deliveries and a team approach that integrates business (customer) representatives, developers, and project managers and relies on their frequent interaction. The integrated team executes regular assessments of their progress and adjusts accordingly to enable continuous improvement of both the end product and overall team performance. The iterative approach supports requirements refinement and provides opportunities to recognize and manage changes as information becomes available. Delivery of value remains the highest priority. These 12 principles guide all methodologies and approaches that have come to be known as Agile.

2.2 Agile Methodologies and Frameworks

There are numerous systems development methodologies and frameworks that incorporate characteristics of the Agile philosophy, and variations continue to evolve. There is currently no specific set of DHS-approved methodologies; DHS PMs are encouraged to determine which Agile techniques and tools may be best suited for application to their programs and projects. Many different Agile approaches have been employed to date within DHS.

The following list of some of the more popular Agile methodologies is not intended to be comprehensive. Furthermore, it does not imply any recommendation or requirement to select a methodology from this list. Indeed, as Agile practices continue to evolve, these methodologies may be updated or replaced by emerging techniques. Practitioners selecting specific Agile approaches and tools benefit from considering the characteristics of the project, the project team, the customer, and the project environment. The summaries presented here outline some of the key characteristics of these common methodologies. Section 2.3 (Figure 2-3) provides a hypothetical decision tree with answers to the types of questions regarding project characteristics that PMs need to consider while selecting which methodology is best for their project. There are numerous textbooks, courses, blogs, and other information sources widely available for further study of Agile methodologies and techniques. Appendix B provides a description of these methodologies, as well as a set of initial resources readers may wish to investigate.

http://agilemanifesto.org/

Although most Agile approaches are described as standalone methodologies, it is common practice for PMs and development teams to employ a combination of practices from different methodologies and tools based on what best fits their environment. Although it is important to understand the elements of different Agile methodologies in context, it is often best to select the individual aspects to use based on the specific needs of the program, project, and project team at hand.

Figure 2-2. The Agile Scrum Framework as a Time-Boxed, Iterative Methodology

Scrum – Scrum (Figure 2-2) is the most widely recognized Agile framework and is often used in conjunction with other methodologies.7 It emphasizes the use of self-organizing, cross-functional teams, with a product owner responsible for managing user stories (the software project’s requirements) that add value to the product or organization. Work is organized into sprints, a time-boxed period for delivery of functionality with defined deadlines and deliverables.

Requirements are collectively sorted into project-level and sprint-level backlogs, and overall project activity is monitored, communicated, and managed using frequent team processes including daily stand-ups, sprint planning, sprint reviews, and retrospectives (reviews aimed at incorporating feedback and learning into the next iteration of development and/or testing).

Lean Software Development - Lean is based on manufacturing principles that emphasize the delivery of value while eliminating waste. As with other Agile techniques, there is an emphasis on learning throughout the development process, updating project decisions to incorporate new information, short cycle times, rapid delivery, and a holistic view of product development. As with other approaches, Lean processes are often combined with Scrum and other techniques.

7 “8th Annual State of Agile Survey,” VersionOne.com (2014), http://www.versionone.com/pdf/2013-state-of- Agile-survey.pdf.

Kanban – Kanban is also rooted in the same principles as Lean and is often combined with other approaches. Kanban is a management practice that relies on a visual display of process information and workflows, translating activities into a collection of queues. Kanban manages work in progress by tracking the number of tasks in each work stream at any given time. The visual display of progress within and across these queues helps to identify issues rapidly and optimizes overall project processing. Many Agile teams use these displays (“Kanban boards”) as management and communication tools in conjunction with other Agile techniques.

Extreme Programming (XP) – XP is an approach based on using dedicated teams of high-performing individuals working intensively on software development. Key XP values are communication, simplicity, feedback, and courage (i.e., risk-taking). It emphasizes constant end-user involvement and technical best practices, including test-driven development, pair programming (jointly executed coding on a single task between two developers), and constant refactoring (restructuring of code). It is often used together with Scrum to specify code-level development and team processes.

While there are a number of Agile methodologies applicable to individual projects, applying Agile approaches within the context of a large enterprise with existing software development and architectural standards poses additional challenges. There several approaches to scaling Agile.

Two of the best-known process frameworks to address the problem of scaling Agile are Disciplined Agile Delivery (DAD) and the Scaled Agile Framework® (SAFe®).

• DAD is a process framework that incorporates many of the core people-first, learning-oriented, solution-focused Agile values, but focuses on applying these in a hybrid manner that recognizes the characteristics of the larger enterprise in which the software development activity takes place

• SAFe® offers an approach to help project managers and executives scale Agile techniques to larger programs and to align project, program, and portfolio efforts with enterprise architecture design

2.2.1 Selecting and Preparing to Use a Methodology

As evidenced by the list above, there is an abundance of named methodologies for applying Agile principles to software development. As the use of Agile has expanded in recent decades, the number of researchers, practitioners, and consultants in this area has also increased. Many of these individuals have developed and/or promoted specific variants, combinations, and adaptations of these and other methodologies. Those new to Agile may benefit more from focusing on the common underlying philosophy and effective practices, such as organizing the project into small work efforts, rather than on the specifics of competing methodologies.

In association with this proliferation of related methodologies, a number of individuals, groups, and firms have developed specific tools (typically, but not exclusively, software based) to support Agile development methods. Similarly, a growing range of training and certification courses have become available. See Section 4.4.1 for a discussion of widely available tools, including tools that have been successfully applied within DHS to date.

At this time, DHS neither specifically endorses nor prohibits the use of any of the known Agile IT software development methodologies or tools. PMs are encouraged to focus on developing a thorough understanding of the specific characteristics and needs of their IT projects and project teams, and to select or tailor the Agile methodologies and tools to apply to the set of challenges faced by each project. This Instruction Manual also contains several illustrative tips (see call-out boxes in Sections 4 and 5) provided by DHS PMs regarding the use of Agile within DHS. These stories and recommendations may prove valuable in making these methodology and tool selections.

2.3 Agile Methodologies and Practices: A Comparative Overview This section provides an overview of what type of questions PMs may ask to differentiate and select from the various Agile methodologies, as well as to gain a better understanding of the scaling and workflow management techniques available to DHS software developers.

2.3.1 Selecting the Right Agile Practices for the Project

One of the challenges facing PMs seeking to apply Agile is selecting the right Agile approach for their project. A PM does not try to find the right methodology for their project based on the predefined ones in this guide. Rather, a PM adopts the practices that make the most sense for their particular situation. The following is a set of questions intended as a resource to provide Agile practitioners, PMs, and executive leadership assistance in beginning to think about which Agile practices would be best suited for their software development projects. This set of questions is not a prescriptive resource, particularly as Agile continues to change and adapt. Rather, it is a way to begin thinking about the types of questions a PM needs to ask during the beginning stages of Agile project planning. These questions ultimately help lead to an informed decision in selecting the proper Agile practices for the project.

As noted throughout this Instruction Manual , it is rare that a single Agile methodology is implemented and carried out fully. Rather, PMs and Agile practitioners select the best practices from different methodologies, based on project characteristics such as the project goals, the development team’s environment, and the ability to report and deliver project outcomes.

Accordingly, the following questions do not have “right” or “wrong” answers, but rather identify certain practices that can be linked to specific methodologies.

Project Characteristics

• Does the project follow an iteration-based or flow-based cycle?

• How large is the project? Can it be broken into smaller, more manageable subprojects?

• Does the project have guidance for how it fits in within the greater Department-level portfolio or program? If not, does it need to be scaled to fit in with the larger program/portfolio in the future?

• How will transparency be provided to stakeholders (i.e., to appropriate governance, executives, program managers, other oversight bodies, and business users)?

Customer Involvement

• What is the level of business involvement during the development process?

• Is the customer directly involved as a member of the team, or are their requirements/needs represented by a team member (i.e., through the role of the Product Owner)?

• Is the business dedicated to the success of this project?

• Are customers required to be on site as part of the team?

Team Construction

• How often can the team members communicate with one another (daily, weekly, or otherwise)? Are they able to communicate with one another in an ad hoc manner (without any prior planning)?

• Will the team be collocated? Is communication face-to-face or virtual? If face-to-face, is there a team room?

• Are the team members cross-functional in their skill sets? Are any team members specialists who have no one else with that same skill set on the team?

• Do programmers use pair programming in their coding approach?

• If a team member is absent for a period of time, can work still move on uninhibited, or must it be delayed in production and/or testing of working code?

• What is the plan for cross-training on the team?

• What is the expected size of the team?

• How many teams are expected to work on this project?

The answers to these questions help PMs to determine which Agile practices best fit their project’s characteristics, and accordingly aid in determining which Agile methodology is the best fit. As seen in Figure 2-3, project characteristics, the level of customer involvement, team construction, and other external factors are likely to influence which processes and practices PMs select for their specific project needs.

Team members will interact through daily standup meetings, as well as through ad-hoc, face-to-face communication

2-4 week iteration periods (called Sprints)

Project team will be between 5-9 people, minimal monitoring/oversight

Scrum Disciplined Agile Delivery

The customer will not be on site throughout the project, but will be represented on the team by the Product Owner role

Extreme Programming (XP)

Practices

Sample Project Practices and Methodology Selection Process

Developers will be using pair programming, sharing ownership of code

Developers will be working in an open environment, with shared workspaces

Project Characteristics

Customer Involvement

Team Construction

Kanban

Report-generated project documentation, including program metrics will be accepted by the program executives

Project A

2-4 week iteration periods

Teams and activities will be openly monitored by project managers and executives throughout project

Project B

Documentation largely created through metric reports, but will conform to portfolio-level requirements

SAFe Framework

Characteristics

Team will use visual display boards throughout the development environment to visualize workflow

Team members will interact through daily standup meetings, as well as ad-hoc, face-to-face communication

Team size of 5-9 for project team with program team size of between 50-125

Customer represented through Product Owner role with Stakeholders also serving a role on the core project team

Project approval and staffing determinations carried out independent of development process

Project vision/goals and approval of project incorporated into project reporting from the outset, to minimize waste and optimize on resources

Lean Software Development

Methodology Selected:

Figure 2-3. Sample Project Practices and Methodology Selection Process

As these visualizations show, selecting the proper practices is not an easy decision to make. Many key questions are asked to create the initial approach. The answers to these questions help Agile project and program managers determine what approach is best to start with for their specific project given its goals, timeline, and team structure. The use of retrospectives allows for the practices to change over time to best fit the project. It is more important to begin work and use retrospectives than to over-analyze to find the perfect approaches for the particular project.

2.4 Agile Teams, Roles, Responsibilities, and Resources

This section outlines some of the possible key roles and responsibilities in an Agile effort. This roles and responsibilities list is not intended to be exhaustive. It includes those roles whose responsibilities differ significantly in support of Agile than in traditional software development.

The Agile Development Instruction (MD 102-01-004) provides a detailed list of the roles and responsibilities required to support Agile development at DHS.

2.4.1 Program Manager

As defined in the DHS SELC,8 a PM is the responsible person who, with significant discretionary authority, is uniquely empowered to plan the program scope of work, life cycle cost, schedule, and performance acceptability levels. The PM is responsible for establishing the project team, and is accountable for accomplishing program objectives or production requirements. PMs need to have a clear understanding of the organization structure they plan to establish in order to clearly delineate responsibility and accountability within their teams. The PM is also responsible for ensuring completion of required artifacts, presenting the business case and status of the project through all phases of review and approval, and managing the performance of the project.

In addition to these reporting, oversight, and governance responsibilities, a PM for an Agile program/project is responsible for fostering an environment that enables the Agile team to succeed. These responsibilities include ensuring proper Agile techniques are employed, obtaining appropriate training and tools, creating a collaborative environment that includes stakeholder involvement, removing impediments, and, in cases where several Agile teams are working on projects within a program, coordinating and integrating the work of these development teams.

Because Agile methodologies rely so heavily on sharing information across the project team, PMs of Agile programs have a strong focus on communications. Two key PM responsibilities are communications with and among the development teams, and transparent communications with the program stakeholders. Agile methodologies often incorporate specific roles focused on communications in various forums. This role may be filled by the PM or by individuals assisting the PM, depending on the scope and needs of the program and development team.

The roles of the Program Manager and Project Manager are both traditional leadership roles within the development environment. In Agile development, however, a shift in the mindset of these leadership roles is needed, as the PMs do not solely serve in a project control role, but also in a

8 Department of Homeland Security, SELC Instruction Manual , MD 102-01-103-01, Revision#00, Appendix C (Washington: Department of Homeland Security).

project support role. Understanding and carrying out this multifaceted role is key to the successful implementation of Agile development practices and approaches.

2.4.2 Project Manager

If a program is divided into multiple projects, a Project Manager is typically responsible for the day-to-day execution of each project. The responsibilities of Project Managers mirror those of the Program Manager, at a more tactical level, and the terms are used interchangeably in this Instruction Manual.

2.4.3 Product Owner

The Product Owner represents the Government or user community and is responsible for determining what features need to be in the product release. In some cases, the Product Owner relies on a Functional Owner or Value Team (a user or users with specific business expertise or subject matter knowledge) to provide input to determine what functionality-specific features need to be in the product release. The Product Owner is ultimately responsible and is the accountable acceptance authority for the features in a release regardless of the additional input received from the Functional Owner or Value Team.

The Product Owner is responsible for delivering mission value to the agency through the development of the solution. Ideally, in an Agile project environment, the Product Owner serves as the business interface between the end user and the development team, helping to gather and present requirements to the team, and providing insights into those requirements based on the end user’s perceived value of the product. Depending on the scope of the project or program, the Product Owner can designate a representative(s) to fulfill this role on a day-to-day basis, taking responsibility for collecting, approving, and prioritizing functional requirements. When using a representative, it is important that the Product Owner delegate the appropriate level of authority and responsibility to make decisions.

The Product Owner (or representative) provides key information on requirements to the development team by discussing, elaborating, and answering questions to ensure that the team fully understands the user stories. The Product Owner/representative ensures that the team products deliver value by fulfilling these requirements. The Product Owner/representative is empowered to make difficult product decisions, including prioritization of user stories in the backlog and which change decisions/options require further refinement before deployment. The Product Owner is responsible for ensuring that requirements prioritization and refinement decisions maximize mission value. Some Agile practices use a Business Value Team instead of a single Product Owner. A Business Value Team is a group of stakeholders who help the Product Owner make decisions about the value of features and functionality for the product. The team is empowered by supporting infrastructure and organizations, is accountable, and is willing to dedicate members to the program as needed.

In some cases, the Product Owner represents the business user community and a separate IT PM represents IT systems ownership; in other cases Product Owners may span both business and IT reporting lines. In all cases, the Product Owner’s priority is the delivery of business value.

2.4.4 Development Team

Ideally, Agile development is performed by small teams (approximately five to nine members) of committed, full-time individuals. This cross-functional team is accountable to itself, the PM, and the Product Owner for iteratively and incrementally delivering business value. These team members are responsible for development, testing of the code, configuration management, and other functions. They plan and re-plan work, inspect and adapt products, and deliver “done” products (systems or subsystems that fulfill user stories or requirements and pass operational tests) with each iteration. A key component of the development team’s responsibilities is to effectively coordinate and integrate individual or group outputs in order to produce these products, known as potentially shippable increments (PSI).

2.4.5 Test Team

In the Agile context, testers are integrated into the development team. All members of the development team are expected to be generalizing specialists and able to help the team in topics outside their specific areas of expertise. Operating within the development team, testers help to plan and design tests and use cases, develop and maintain acceptance criteria, estimate test execution resource requirements, develop automated test tools and environments if feasible, and participate in post-activity reviews, or retrospectives. In some cases, testers also participate in programming.

2.4.6 Agile Coach

The role of an Agile Coach is part embedded trainer, part consultant, and specifically, the team advisor. The coach works as an advisor to help the team adapt the Agile methodology to their environment, apply Agile and Lean thinking, work through challenges, and remove impediments.

Coaches fulfill a supportive rather than a directive role. This distinction is consistent with the Agile tenet that self-governing teams can be more efficient in their operations than those operating in a hierarchical fashion. Thus, the Agile Coach is focused on helping the team to communicate and operate in ways that allow the team to identify and make sound technical decisions, as well as make progress toward product goals. The coach enables, rather than performs, the decision-making.

Identifying and designating an Agile Coach can be a key challenge for the PM. Individuals with prior experience managing Agile programs and projects within DHS are a good source of advice and assistance on this topic. Some PMs and contractors have advised that PMs selecting an Agile Coach to assist with a DHS software development project might consider whether candidates have experience working Agile development within the DHS (or other federal agency) enterprise, as tailored approaches to compliance with federal processes and regulations are keys to success. If a project provides the resources for acquiring an Agile Coach, it is recommended that the PM incorporate one into the project from the outset. Ultimately, as this may be difficult for some projects, one of the most valuable resources available to PMs and Agile practitioners is the knowledge and experience of DHS peers who have managed Agile programs and projects. Many of these individuals can be found on the Agile Center of Excellence and IPT (contact the EBMO SELC/Agile Team at EBMOSELCTeam@HQ.DHS.GOV for information on participating).

mailto:EBMOSELCTeam@HQ.DHS.GOV

2.4.7 Additional Expertise

The overall project team often requires expertise in a variety of technical, subject matter (business area), and regulatory, contracting, and other topic areas. PMs are encouraged to consider the full range of skills and knowledge required, as well as critical points for application of such expertise, in developing the project team(s). In enterprise environments, extended teams may provide additional expertise on an as-needed basis. In the DHS context, this extended team might include documentation specialists, enterprise architects, operational testing specialists, information security and privacy specialists, experts in system accessibility requirements, quality assurance analysts, and compliance validation/verification personnel. Establishing and maintaining open communications and cooperative operations across the extended team is crucial to the Agile approach and improves the success of the program.

2.4.8 Oversight Bodies

The PM must coordinate with the various oversight bodies that govern IT development. These bodies vary depending on the level of investment. For major investments, DHS Executive Steering Committees (ESC) are often established to oversee all aspects of program planning and execution between major acquisition decision events. This authority extends to assisting programs to adopt Agile methodologies and acquisition strategies where appropriate. Many DHS components have their own ESCs consisting of component Chief Information Officer (CIO), Component Acquisition Executive (CAE), and appropriate business and IT representatives that provide oversight for non-major investments.

Specific recommendations on the integration of key functions within DHS Agile product teams are addressed in Sections 3 and 4 of this Instruction Manual.

2.5 Success Factors and Risks

The discussion of the Agile Manifesto in Appendix A provides information on the conditions necessary for successful application of a “true” Agile development approach. At DHS, PMs develop program plans and teams that can successfully meet mission needs under changing conditions. The discussion below highlights a few of the key success factors and risks for which a PM considers and develops an approach for before establishing an Agile team at DHS.

2.5.1 Stakeholder Engagement

A…