Four primary characteristics should guide Agile adoption in Government:

1. Structuring programs and processes around small, frequent capability releases
2. Valuing working software over comprehensive documentation
3. Responding to changes in operations, technology, and budgets during development
4. Active user involvement throughout development to ensure high operational value

The foundation of Agile is a culture of small, dynamic, empowered teams actively collaborating with stakeholders throughout product development. Agile development requires team members to follow disciplined processes that require training, guidance, and openness to change. While Agile does impose rigor, the method does not consist of simply following a set of prescribed processes, but instead allows dynamic, tailored, and rapidly evolving approaches that suit each organization’s IT environment. Various Agile methods (e.g., Scrum, Extreme Programming (XP), Kanban, Test Driven Development (TDD), Disciplined Agile Delivery) have emerged, each with unique processes, terms, and techniques. These methods focus on the development team and associated stakeholders. Agile acquisition extends Agile development practices beyond the contractor development team to the government acquirer, users, and other stakeholders. It requires that both agencies and contractors change many acquisition roles, processes, and culture, thereby fostering a close government-industry partnership. This, in turn, demands investments in time, training, and continuous improvement to pay long-term dividends.

Source: Standish Group CHAOS Report 2015

In the federal government, the acquisition of complex government-oriented IT systems are high risk, plagued with cost and schedule overruns, and often do not deliver capabilities to meet user requirements.  Federal agencies struggle to deliver new IT capabilities to retire aging legacy systems. Given the pace of change in operations, technologies, threats, and budgets, agencies require an environment where capabilities can be iteratively delivered and responsive to changing priorities. The defense acquisition system for example was designed for large weapon systems that can take a decade or longer to define requirements, analyze alternatives, select a vendor(s), design, develop, test, produce, and deploy.  IT generally operates in a more rapid environment than hardware systems where the state-of-art doubles every 18-months according to Moore’s Law.  Countless studies including leading research from the Standish Group has demonstrated that smaller programs succeed in delivering required capabilities on cost/schedule at much higher rates than larger programs. Smaller programs are much lower risk to execute as they are easier to scope, estimate, design, develop, and test.  They require less time during each phase, minimizing the opportunities for disruption. Smaller programs enable faster learning and smaller investments allowing for subsequent efforts to incrementally deliver capabilities that delight users.

While both practical experience and research findings strongly indicate the value of Agile for many IT acquisition programs, this approach is not appropriate in all cases. Programs well suited for Agile adoption include those that are:

Despite the success that Agile development has achieved in the private sector, commercial implementation of Agile does not directly translate to Agile adoption in the federal sector. The barriers to program structure, requirements, and contracting often stem from these key differences. The government must adhere to a set of rigorous policies, statutes, and regulations that do not apply to the same degree in the commercial sector. Following the rules that govern federal acquisition often involves a bureaucratic, laborious, and slow process that greatly influences how effectively Federal Agencies can implement Agile. The commercial sector has a different stakeholder management process than the government. Private firms are accountable to an internal and layered management structure that usually goes no higher than a corporate board of directors; the few possible external stakeholders (e.g., labor unions) rarely cause frequent and major disruptions. The government bureaucracy has layers upon layers of stakeholders with a high degree of influence that can create frequent and significant disruptions. Everything from a change in the political administration to budget sequestration can exert significant external influence on a program. The bureaucratic layers of government make it difficult to empower Agile teams to the same extent as in the private sector. The commercial sector has considerable latitude to make adjustments throughout the course of the development because companies closely link accountability, authority, and responsibilities to push decision making to the lowest levels. The government’s tiered management chain of command makes it difficult for the Agile team to be empowered to make timely decisions.

These enablers align with the recommended set of principles in the GAO report Effective Practices and Federal Challenges in Applying Agile Methods. They center on the Agile Manifesto themes of small, frequent capability releases, a dynamic requirements process that allows for the continuous prioritization of requirements, active involvement from the user community throughout the development process, and commitment to delivering working software based on a time-boxed schedule. Some efforts may succeed in implementing only a subset of these themes and delivering effective software solutions; however, one could argue that this would not constitute a pure Agile development.

Agencies could benefit from defining and standardizing Agile-based practices to ensure an agency-wide common understanding of what constitutes an Agile-based program or project.

Today, many efforts are inaccurately labeled as Agile, leading to misunderstanding and misrepresentation of Agile principles. After defining the principles, agencies needs to provide detailed guidance to the acquisition community that describes how to execute the Agile acquisition processes within their acquisition regulations and laws.

Agile practices, processes, and culture often run counter to those in the long-established defense acquisition enterprise. The Agile model represents a change in the way agencies conduct business. Programs must rethink how they are staffed, organized, and managed, as well as whether the business processes, governance reviews, and funding models involved in each acquisition are structured to support Agile delivery patterns.

To succeed, the Agile model depends on strong commitments at all levels of the acquisition process. Agile requires dedicated government involvement throughout the entire process in order to plan and integrate multiple releases, oversee development cycles, manage evolving requirements, facilitate collaboration, and obtain committed, active, and consistent user engagement. The government must establish a strong team to manage and complement the Agile development contractor. The optimal structure to foster a collaborative environment features physical co-location of the acquisition support team, which consists of the program staff, contractor, and supporting functional areas. In cases where close physical proximity of the team is not practical or feasible, programs can use collaboration tools for daily meetings, pair-programming, and frequent discussions with stakeholders.

One Air Force major IT program has the program office, contractor and end-users all located within a 7-mile radius. This close physical proximity has enabled the program’s adoption of an integrated Agile approach.

A culture of trust that spans the decision authority, developers, testing organization, acquirers, program management, and users is critical to Agile delivery. Close, dedicated Agile acquisition teams facilitate this model, but it must be further reinforced at the top. Leadership can signal that trust by empowering team members with decision-making authority based on clearly communicating a high-level strategy, requirements, and vision for the acquisition.

An analogy to the military term “Commander’s Intent” can clarify this concept. Commander’s Intent is a concise expression of the purpose of an operation – a description of the desired end state and the way that goal facilitates transition to future operations. It allows adaptation, so that a mission can continue even when the operation does not go as planned. For Agile, the overall plan represents the intent. If the plan does not work as expected, the team alters the plan while continuing to focus on the intent. This requires the team to build relationships that promote trust, collaboration, transparency, and shared responsibility.

The GAO report Effective Practices and Federal Challenges in Applying Agile Methods recommends four organizational commitment and collaboration practices for Agile implementations:

• Ensure all components involved in projects are committed to the organization’s Agile approach
• Identify an Agile champion within senior management
• Ensure all teams include coaches or staff with Agile experience
• Empower small, cross-functional teams

Implementing these practices will help facilitate the cultural changes necessary to make Agile effective.

As noted in the GAO report, several challenges relate to significant differences in how projects are managed in an Agile environment. Previous government attempts with Agile have produced mixed to poor results because the government tried to implement portions of Agile without changing some of the underlying development environments, tools, processes, and culture, which remained oriented toward traditional development strategies. Rather than simply follow a recipe of Agile methods and steps, programs should try to adopt the Agile philosophy and mindset to instill program agility. Establishing an organizational change discipline and clear vision can help to communicate the organizations strategy of adopting the Agile philosophy. The functional communities supporting acquisition today often operate in silos with only weak ties to the program office. Agile practices require a complementary business environment to provide the structure, discipline, and support for Agile development practices. For Agile to succeed, the environment must facilitate close collaboration across multiple disciplines to support rapid development cycles. A successful Agile framework depends on active support from multiple stakeholder communities, including users, developers, systems engineers, and testing and certification staff, as well as DoD leadership and oversight. Program managers must engage these key stakeholders to garner their endorsement and feedback and to build an Agile culture that can be sustained throughout the lifecycle of DoD IT programs.

Agile development requires that both the contractor development team and the government program office adopt a new set of roles and responsibilities. The figure below shows a potential Agile team construct. At the heart of an Agile development effort is the release team responsible for execution. The release team includes a core team composed of the project manager, product owner, tester, and systems engineer, and a development team led by a scrum master (scrum master and Product Owner are roles specific to the Scrum methodology, team roles may vary if using other Agile methods). The broader extended team includes primary stakeholders and representatives of functional support activities, to include the acquisition leadership, contracting, test, certification and accreditation (C&A), the user community, external systems, and organizations contributing financial support.

Potential Agile Team Construct

While the roles may vary based on the Agile methodologies and level of integration, four roles recur in almost all Agile activities.

• The Product Owner is the authoritative user community representative who manages the backlog(s) and requirements prioritization, communicates operational concepts to the development team, and provides continual feedback to the development team on their products. See analyze requirements for additional details on this role. The Product Owner is frequently a government employee from the user organization that owns the requirements, but some programs have a contractor fill this role and then work with government users.
• The scrum master facilitates the processes, enforces the team’s rules, removes barriers, and keeps the team focused on tasks. The scrum master is usually a contractor who is a member of the development team.
• The release team is composed of <10 government and contractor members who work closely together on the release.
• The development team is typically composed of contractor staff: software developers, including software and security engineers, data specialists, testers, quality assurance, and configuration managers.

Ideally these participants are co-located in the same physical space. When co-location is not achievable, they should meet regularly via phone or in person, and maximize use of collaboration tools.

While Agile practices depend upon highly skilled and disciplined team members, a cross-functional team of mentors and experts working alongside junior-level team members can also succeed. Program offices realize the best results when the team has at least one staff member with Agile or related expertise who provides on-the-job training to the other staff and is committed to leading teams through successful adoption of Agile practices.

Members of effective program teams understand their roles and responsibilities within an Agile program and have confidence in their ability to perform them. The applicable Agile guidelines for obtaining the necessary talent include:

• Recruit personnel with Agile, Lean, and related expertise to join the program team. Program managers should look across programs in the next higher level organization (e.g., PEO level) and should advocate sharing of those critical skill assets.
• Bring in experts in Agile, Lean, and related methodologies to serve as Agile coaches and to conduct on-the-job-training for the program office staff. These experts can make invaluable contributions by guiding the program office to identify and improve roles, processes, and techniques, while addressing any adoption issues. Agile coaches help bring all program participants together under a common set of practices and guidelines.

Management of Agile development requires a shift from the traditional model of directing projects from the top down to one of trusting and empowering teams to make decisions and to collaborate on solutions. Programs must operate in a trusting and cooperative manner across the government, contractors, and development teams. This may require the government to refine or redefine existing roles and consider new roles specific to Agile. The table below identifies recommended roles and responsibilities for members of an Agile team.

Recommended Roles and Responsibilities

Key Questions to Validate Agile Teams/Roles:

• Are the major stakeholder roles and responsibilities clearly defined?
• Is there a clear owner of the requirements backlog?
• Is there a clear government integrator (e.g., program manager and/or systems engineer) who coordinates and integrates programmatics (e.g., schedules, metrics) and deliverables (e.g., code)?
• Is there a clear owner of the program (or broader enterprise) architecture?
• Is there a clear, early commitment from user representatives and the broader user base?
• Are users co-located with, or within close proximity to the program office and/or contractor?
• How frequently do users meet (face-to-face, phone, VTC) with the PMO and developers?
• Is the Product Owner empowered to speak on behalf of the user community?
• Does the effort actively engage a collaborative, cross-functional community of stakeholders?
• Is the team size small enough to effectively adopt Agile principles?
• Are the number of teams manageable per the size, risk, complexity, and integration required?
• Is there a system-of-systems, scrum-of-scrums, or related cross-team integration role?
• Have approval authorities been delegated to a low enough level to enable rapid decisions?
• Do teams comprise both government representatives and developers?
• Do the team members have sufficient Agile experience, training, and/or coaches?
• Do external stakeholders understand and support their roles in an Agile environment?

See also:

• Roles on Disciplined Agile Delivery Teams by Scott Ambler
• Roles on Agile Teams, Ambysoft
• Agile Retrospectives: Making Good Teams Great, Esther Derby, Diana Larsen
• 42 Tasks for a Scrum Master, Agile Trail
• Scaling Agile

Agile development often involves multiple teams working on a single program. For example, one team could be assigned a release to develop in parallel with one or more other teams developing other releases. This requires active coordination of efforts across the teams to ensure they are developing towards a common solution. Adding development teams enables faster delivery of more software, yet comes with increased risk to coordinate, integrate, and manage these developments and teams. There are various approaches to structure a multi-team environment.

The next figure shows multiple development teams (all contractors) each working on its own release. The scrum masters of each team would meet regularly (e.g., weekly) with government personnel. This approach may limit the government’s, particularly the Product Owner’s, involvement with the development teams, but enables the development team to focus on its tasks with minimal interruption.

Multiple Development Teams Example

The figure below highlights multiple release teams of government and contractor personnel, with government and contractor representatives from each team regularly collaborating via a scrum-of-scrums. These representatives can be the PM and scrum master. A single Product Owner could support all the release teams and scrum-of-scrums efforts. Team members can regularly collaborate with those in similar roles on other teams on progress, designs, dependencies, issues, and resources. This approach focuses on an integrated government-contractor release team, but could be more resource intensive.

Multiple Release Team Example

See also:

• Scaling Agile