Making Agile Work for Government: Perceived Challenges to Agile Adoption

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.

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.

Working within the constraints of the high-level delivery framework, the team can execute project work according to agile principles, focusing on the delivery of complete, tested, small features that carry inherently lower and more diversified risk than traditional waterfall or “iterative waterfall” development approaches. Attempting to plan, document, design, build, test, and deliver an entire product—or sprints of work, as in iterative waterfall development—can take years to complete and may deliver poorly aligned or unused functionality. The “agile within a framework” approach, however, allows for a more rapid delivery of meaningful program functionality and tighter, story-by-story and iteration-by-iteration control of delivery risk without the fear that the effort will devolve into an open-ended engagement that lacks clear objectives and measurements for success.

Maintaining Program Control, Visibility, and Accountability
In the current “do more with less” environment, government managers often find themselves responsible for multiple, simultaneous delivery efforts in addition to internal responsibilities that leave them little time to play the closely engaged, day-to-day role expected on agile development efforts. Government managers often are unable to participate in daily stand-up meetings and Scrum sessions. They are sometimes not even on the same project site as the majority of their development teams.

Because of this dilemma, government managers may be justifiably concerned that fast-paced, documentation-light agile efforts offer them reduced—rather than enhanced—visibility into the progress, risks, and issues of the projects for which they will be held accountable. Additionally, non-technical government managers may feel that they risk being misled by contractors who are able to constantly redefine the targets for success, making accountability even more difficult.

In this context, project teams that have incorporated more structured management and reporting tools—including clearly documented performance measures—into the project management approach can significantly improve visibility and control at the cost of only slightly increased management overhead (a matter of a few additional hours spent on performance analysis and status reporting over the life of a medium-sized effort). Project work can continue according to agile best practices, with status, risks, and issues being tracked via daily stand-up meetings and captured via the mechanism that best suits the needs of the team. These mechanisms can encompass everything from team whiteboards to electronic status-tracking dashboards.

To supplement their structured management and reporting tools, the project development lead, project manager contractor, or other designated management representative can capture key statistics on project burn rates, cost performance, risks and issues, and other pertinent performance measures mapped against the overall project delivery plan. From there, the designated management representative can summarize the statistics and provide the information to the government lead at regularly scheduled status checkpoints throughout the entire effort.

Through these checkpoints and the informal daily and weekly status checks (performed at whatever frequency the government lead prefers), the government lead can track project performance to his or her level of comfort. Where higher levels of control are required, this periodic reporting enables the government lead to perform a type of earned-value management against the project that, due to the granular, story-oriented nature of agile development efforts, actually enables a higher level of visibility, control, and accountability than would be possible on a traditional project.

Matching Agile to Traditional Program Control Processes
Through years of experience, many government agencies have developed extensive and well-documented engineering and development lifecycles that, for traditional (sequential, waterfall-style) projects, provide a series of “completeness checklists” against which project progress can be monitored and controlled from inception through delivery and eventual retirement. Beyond the familiarity aspect, these engineering lifecycles are closely tied to existing government acquisitions and finance mechanisms (e.g., Federal Acquisition Regulation (FAR) or the Department of Defense’s “DOD5000” Defense Acquisition System). As such, project compliance with lifecycle milestone reviews and milestone-associated documentation is more often than not a mandatory condition for successful delivery.

It can be challenging when agencies try to map agile projects to the traditional engineering lifecycle. Where the traditional lifecycle anticipates a series of sequential steps (plan, design, build, test, etc.) that must be completed before the project can move on to the next phase, agile delivery is neither sequential nor linear. Instead, agile development focuses on delivering the key elements of project functionality in overlapping, iterative cycles that incorporate multiple different lifecycle elements (requirements gathering, design, development, testing, deployment, etc.) over shorter periods of time. Ultimately, an agile project will deliver the same functionality as a traditional project, but the way in which it delivers that functionality is very different.

To make agile development work when it’s expected that the team needs to comply with traditional program control processes, the team needs to use a hybrid approach to delivery and review for its project. At the beginning, the team can conduct a high-level planning and scope-definition effort (such as a planning workshop or a series of subject matter expert (SME)-led planning meetings) to build the overall delivery framework, then it can map subsequent lifecycle gate reviews or acquisition system milestones to checkpoints that coincide with the completion of core project functionality elements and iteration checkpoints, as shown in Figure 1.

Figure 1. Mapping agile to traditional project lifecycle gates

In this hybrid approach, the mapped gate reviews are a series of program-risk-control checkpoints that enable government leadership to validate key elements of delivered functionality and redirect project efforts, rather than simply serving as a series of checklists for program completeness.

Where traditional agile development tends to emphasize the rapid delivery of system functionality over documentation, the hybrid approach must be adapted to function in the government space. As part of the initial lifecycle mapping process, the project must also map and plan for the development of the necessary documents and supporting artifacts that are  required for each lifecycle gate and acquisition milestone review. Under the hybrid approach, the project team iteratively develops and improves key documents and supporting artifacts alongside actual system functionality, with each element (documentation and development) directly informing the other. This approach can make the overall effort more complex, but it offers a unique opportunity to reduce delivery risk and increase product quality through development and validation of relevant documentation as project work progresses.

The hybrid approach invariably requires careful management of expectations and advance approval for modification or tailoring out of documents that traditionally accompany milestone reviews, an effort that must be built into the contractor’s proposal response and contract-negotiation process. However, by carefully mapping and tailoring the agile development effort to a given agency’s traditional development lifecycle, the new agile initiative can largely mitigate and bridge the institutional “acceptance gap” that it might otherwise face if it were to attempt delivery using only the agile approach.

Read all of the articles on Making Agile Work for Government:

Making Agile Work for Government: A Blended Approach
Making Agile Work for Government: Perceived Challenges to Agile Adoption
Making Agile Work for Government: Addressing the Challenges of Agile Adoption