Agile Fundamentals Overview

Agile is a set of software development principles that emerged in 2001 after 17 industry leaders created the Agile Manifesto to design and share better ways to develop software. Agile is the leading software development methodology in the commercial world with growing adoption across the government.

What is Agile?

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.

Why Agile?
Standish Group Size

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.

Benefits of Agile
Responsive to change Agile enables the program to react to changes in operations, technologies, budgets, threats, and other factors via small frequent releases.
Higher user satisfaction Each release and sprint focuses on the highest priority requirements as determined by the user, providing users with frequent and consistent capability deliveries that address their needs.
Faster delivery of capabilities Capabilities are regularly delivered in months, not the 5-10 years it takes for many large IT programs today to deliver via a waterfall methodology.
Improved quality software Daily and automated integration testing, small scoped releases, and routine demonstrations identify and address defects earlier in the development process with less rework.
Increased visibility into progress Users, oversight authorities, and other stakeholders see regular progress in actual working software vice theoretical paper-based accounting estimates.
Reduced risk Smaller scoped efforts are easier to design, plan, estimate, and execute and more resilent to changes.  Additionally, smaller scoped projects have a lower “sunk cost” if they fail fast, fail early.
Improved productivity In Agile more energy is focused on iteratively developing capabilities than planning and reporting documentation.
Programs Well-Suited for Agile

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:


Software Intensive
  • Capabilities can be incrementally designed and delivered
  • The operational environment can absorb frequent software deployments and upgrades
  • Lifespan of the project or software is expected to be short or require constant upgrades
  • Ability to leverage enterprise architectures or existing platforms
Accessible Stakeholders
  • Users, testers, and other key stakeholders can engage throughout the acquisition lifecycle
  • Users are able to share insights of the operational environment and provide rapid feedback on interim developments
  • Users are empowered representatives that have the ability to prioritize requirements and provide feedback during user acceptance testing
Uncertain Solution Space
  • Rapidly changing threats, operations, and technologies
  • Requirements are fluid, dynamic, and continuously reprioritized
Follow-on Increments
  • Often a first increment may deliver infrastructure capabilities or build the basic platform via traditional development methods (e.g., waterfall)
  • Subsequent capabilities can be iteratively and independently developed and delivered to upgrade an existing capability or build a small app on an existing platform
Agile Barriers and Enablers in the Federal Acquisition Environment

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.


Barriers Enablers
Acquisition Processes
  • Long timelines for requirements, contracting, testing, reviews
  • Extensive documentation and reviews
  • Fully defined requirements upfront
  • Changes to contracts are costly and time consuming
  • Use capstone resources (e.g., PEO or portfolio-level) for contracts, strategies, and personnel for small, quick releases
  • Manage requirements via a continuously reprioritized backlog
  • Acquire developer services vs products
  • Program oversight is significant
  • Risk intolerant culture
  • Resistance to tailor processes, documents, and reviews at all levels
  • Implement small, empowered teams
  • Embrace change – fail early and fail fast; continuously improve
  • “Always be shipping” – delivering software is the #1 priority and performance metric
User Involvement
  • Active user participation and user demonstrations throughout the development process
  • High bandwidth communications; preferably with co-located teams
  • Prioritized requirements based on continuous operational and technical discussions
Program Structure
  • Up-front fixed scope with locked requirements
  • Overly detailed and unrealistic requirement for an upfront cost estimate
  • Managed against established baselines; earned value management (EVM) changes are discouraged
  • Small, frequent releases based on a continuously reprioritized requirements backlog
  • Acquisition processes that are proactively tailored and approved by oversight executives
  • Managed as a portfolio of capabilities versus independent programs
  • Align strategies, processes, and reviews in an integrated acquisition model and strategy
  • Leverage enterprise architecture for business and technical integration
  • Conduct coordination at the portfolio or capability-level to leverage process/review efficiencies
Experience and Training
  • Limited government and industry experience with Agile
  • Lack of leadership understanding and support for Agile
  • Lack of defined processes to enable Agile efficiency
  • Invest in training and value experience in government and industry
  • Use coaches to guide program managers and redefine key processes
  • Obtain approvals from stakeholders at the process-level ((vice individual program-level) to enable efficiency in the review process

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.

Embracing the Agile Culture

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 Teams

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.

imagePotential 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

Role Responsibilities
Program Manager Manages the requirements, funding, and acquisition processes while also overseeing the planning of each release and high-level program increment.
Product Owner Manages the requirements, tradeoffs, and collaboration between the acquisition and user communities.
Scrum Master Facilitates the developers as they execute their processes, shielding the team from distractions. Enforces the development team rules and keeps the team focused on tasks. Often manages the sprint backlog.
Developers Develops the software, to include software developers, database administrators and architects, testers, and other technical experts.
End Users Convey operational concepts and requirements/needs, participate in continuous testing activities, and provide feedback on developed capabilities.
Enterprise Architect Creates architectures and designs in an iterative manner to ensure that designs evolve in a controlled way over the course of releases.
Independent Tester(s) Validates the capabilities produced against the end users’ top-priority needs, the design specifications, and standards.
Systems Engineer Manages releases, overseeing system implementations, O&M, and transition, and integrates all the engineering sub disciplines and specialty groups into a team effort to create a structured development process.
Contracting Officer Manages the solicitation, award, and execution of Agile development contracts, and facilitates communication between government and contractor staff.
Contracting Officer’s Representative (COR) Acts as a representative to the Contracting Officer. The COR does not have authority to make changes to the contract or authorize new work; however, the COR is critical in ensuring the vendor executes the technical work in compliance with the contract.
Cost Estimator Tracks and manages the overall program budgets; provides low-fidelity cost estimates at the program-level for high-level increments, followed by detailed cost estimates prior to the development of each release.

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:

Multiple Agile Teams

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.

imageMultiple 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.

imageMultiple Release Team Example

See also:


Submit a Comment

Share This