Making Agile Work for Government: Perceived Challenges to Agile Adoption


Erich Knausenberger and Raj Shah examine three perceived challenges to agile adoption in the government space and explore how the "blended approach" to agile adoption offers an effective response to each.

In Making Agile Work for Government: A Blended Approach, we introduced the concept of a “blended approach” to agile development in the government space. This approach incorporates the core principles of agile while also applying elements of other industry practices to minimize risk, increase program control, transparency, and repeatability, and (most importantly) enable visibility and accountability without forcing agencies to completely abandon their traditional performance-management methodologies as a precondition for success.

In this article, we will examine three perceived challenges to agile adoption in the government space (perceptions we have encountered most often among individuals with limited agile implementation experience, or who have experienced difficult government agile implementations in the past) and explore how the blended approach offers an effective response to each.

Perceived Challenge With Agile

Blended-Approach Response

Increased program risk (cost, schedule, and scope) because project requirements and design evolve and are refined throughout the effort

Document high-level user needs (desired end-state) up front as a scope “framework” for the delivery effort; iteratively increase level of detail within this established framework throughout the program.

Reduced program visibility and accountability for government managers unable to attend daily stand-up meetings or Scrum checkpoints

Establish regular status checkpoints, including daily and weekly reviews, which incorporate iteration progress (burn rates and budget performance), risks, and issues. Map this against the overall program delivery plan.

Incompatibility with traditional lifecycle-based program acquisition and control processes, such as the Department of Defense’s Defense Acquisition System (DOD5000), the Department of Health and Human Services (HHS) Enterprise Performance Lifecycle (EPLC), and the more widely used Software Development Lifecycle (SDLC)

Map lifecycle gate reviews and acquisition milestones to iteration checkpoints and treat these as a series of program-risk checkpoints rather than as a checklist of program completeness. Integrate required documentation into the iterative development process, with document delivery tied to mapped iteration checkpoints.

Table 1. Addressing perceived challenges to agile on government projects

Reducing and Mitigating Program Risk
In traditional government IT programs, risk management involves a structured, linear process in which project requirements and design must be completed early on, approved by product and business owners, and managed closely thereafter to minimize the chances for cost, schedule, and scope overruns. This expectation runs contrary to the agile view that requirements and design are continually refined throughout the project and that neither is fully “done” until the project is complete.

Because government agencies must work within closely constrained budgets and often according to publicly reported delivery timelines, this ambiguity in project requirements and design (and, by extension, project scope) can be deeply unsettling. Further, the continual refinement of scope over the course of an agile project leads to inevitable questions about scope creep, like “How can a manager ensure that the project delivers meaningful functionality that meets end-user needs and not get stuck in an endless cycle of design, development, and redevelopment?”

To address these concerns and visibly mitigate project risk, it helps to incorporate a structured delivery framework in which agile development can function properly. At the start of the project, the team should identify and validate a desired end-state for the effort and a series of high-level user needs that must be met for the project to be successful. Using these high-level needs as a delivery framework for agile development work, the team can significantly reduce scope, schedule, and cost risk. By breaking high-level scope into a series of overlapping iterations—each of which involves elements of scope discovery, design, development, testing, and delivery and support—the team can focus on rapid delivery of core functionality with iterative deployment of additional functionality over time.

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.