Managing federal projects

Managing Federal Projects in Agile: Moving Away from the Waterfall

I

n July of last year, the GAO issued a report chronicling the advantages and the challenges of applying Agile in government. Simply put: Ongoing scrutiny of long-running and expensive IT projects propelled a move to change. And now, with the current sequestration, federal budgets are squeezed further and projects are more at risk.

The GAO report includes direct instruction to avoid cost overruns and schedule delays: “To reduce the risk of such problems, the Office of Management and Budget (OMB) recommends modular software

delivery consistent with an approach known as Agile, which calls for producing software in small, short increments. Recently, several agencies have applied Agile practices to their software projects.”

So the question is not, “Why Agile?” It’s “How Agile?” How do government agencies adopt a new way to develop and manage programs and move away from tradition-bound practices? And how do Agile practices work in the reality of government organizations? This article provides practical guidance on applying Agile in government, addressing the sheer size, scale

BY Christine Bottagaro & Ronica Roth

and scope of projects in the federal sector.

Walk Away from the Waterfall and into Agile Waterfall has traditionally involved big upfront planning that hinges on an exacting requirements discipline to deliver, well, exacting plans. In contrast, with Agile, you move away from an up-front, formal requirements-gathering phase, as this slows the process of getting to that short increment of minimal viable features.

In fact, Agile requirements development and approvals are themselves delivered

So the question is not, “Why Agile?” It’s “How Agile?”

How do government agencies adopt a new way to develop and manage programs and move away from traditionbound practices?

MODERN GOVERNMENT · May - June 2013

27

iteratively and incrementally.

This evolutionary approach allows teams to gather stakeholder feedback sooner – and thus deliver faster. The requirements and story elicitation process is embedded in the Agile process itself.

In Agile, most requirements are captured in what are called user stories.

While that distinction might be seen as merely tactical, the move to user stories is actually a pivotal point in transitioning to Agile from a waterfall-based environment.

Deceivingly simple, user stories encourage Agile teams to behave differently. Wellcrafted user stories present the context that leads to better design, more valuable features, and faster results; they are key to team delivery, velocity and estimation.

These stories are then delivered in short – typically two-week –timeframes called iterations, or sprints.

Written from the perspective of the end user or customer, user stories are managed in the product to-do list, or backlog. This backlog is stack-ranked by what can provide the highest value soonest, and this backlog is worked in order. Details are fleshed out just-in-time, with an emphasis on the user stories slated for the next iteration. Stories further down the list can remain vague until they bubble to the top.

By waiting to refine them, teams wait until they have more information.

As much of Agile practice

is driven by collaboration among team members and across teams, conversation drives user story definition and acceptance criteria.

With these largely informal communications, providing documentation and traceability is another matter. Larger organizations, or those with multiple, distributed teams, find using a centralized Agile lifecycle management tool essential for tracking and historical capture.

Piloting Agile – Where Do We Start?

New teams, or teams working with customers who are new to Agile, might want to start their Agile journey or their project with an “Iteration Zero.”

They use a short timebox to set the stage for success, understanding project vision, reviewing requirements with stakeholders, and identifying a roadmap of the most valuable features. They use Iteration Zero to set up their environment and ideally deliver at least a “hello world” feature.

Most Agile teams will simply dive into delivery at this point. However, an interim step in the journey from plan-driven to valuedriven is to conduct an upfront high-level analysis of the full project, as well as a more in-depth analysis of an initial release or milestone objective. This analysis can provide good context, although it might ultimately prove wasteful when the

team adjusts the long-term plan in favor of new learnings.

As the team begins delivering, and the customer begins to trust the team, the weight of these upfront analysis and planning activities are gradually reduced. Cadence is established, focus is clear, and customers see output earlier, allowing for inspection and adaptation to the final release. Planning activities settle into a cadence of midrange Agile Release Planning, wherein teams predict which stories will be delivered in which iterations, looking 3 - 6 iterations out. These plans are refined via more-detailed iteration planning, at the beginning of each 2-week timebox.

Meeting Federal Documentation and Reporting Requirements with Agile So how does this apply to government projects and programs? Explicit documentation demands and regulations are brought into user stories through the acceptance criteria for those stories. When implementing a user story, the team completes tasks that include reporting requirements of any kind, including those specified in Exhibit 300. As the team works on the story, the specific acceptance criteria dictate whether the story is complete or not. The “definition of done” for that story has all reporting and documentation requirements.

Fixed timeline reporting deadlines are built into the corresponding iteration, including any specifics. If the report due date falls outside of an iteration, results from the latest iteration can be shared, or align the iterations with the reporting cycles.

Alternatively, engaging the customer throughout the process, sharing achievements and progress, will gradually reduce the volume and frequency of the requested reports.

Agile and Government Contracting: Productive Co-existence Agile delivery methods don’t actually change the fundamental nature of contracting. The basic firm fixed price (FFP) and time and materials (T&M) structures, as well as the many hybrid permutations in between, still exist. Just as when using traditional delivery methods, with a FFP contract a certain amount of up-front analysis and design can reduce risk.

Regardless of your delivery method or contracting structure, real success is about building a trusting cooperative relationship with the customer. Applying Agile helps this process. Valuing customer collaboration over contract negotiation, Agile methods engage customers earlier in the process, removing uncertainty over priorities, trade-off decisions, and how success is defined. The visibility and value-based, data-driven progress checkpoints of an

With Agile, you move away from an upfront, formal requirementsgathering phase, as this slows the process of getting to that short increment of minimal viable features.

Done well, Agile allows teams to deliver more program value with less time and effort.

Agile approach make contract management and change control natural and cooperative.

To be clear, Agile does not remove contractual compliance.

Contracts that explicitly require detailed up-front analysis and documentation must be honored.

However, there is often more flexibility in the form and level of detail in these documents. An Agile team serves its customer by satisfying these requirements in a lightweight, high-value manner, with an emphasis on getting past the documents and moving the program into development as quickly as possible. This is because an Agile team understands that the best analysis and the most thorough risk mitigation comes from testing, validating and iterating on a real product.

Going Agile in Government – Pushing the Rock Up the Hill Moving to Agile in government can be hard, seeming akin to Sisyphus-like punishment.

Simple in concept, it is decidedly difficult in application. Perhaps unsurprisingly, the biggest challenge is altering mindsets and changing the underlying organizational culture. Agile can be seen as disruptive or anarchic, when in reality it produces a more consistent delivery discipline and encourages true engagement and thoughtful behaviors.

Some groups try to ease the shift by adopting Agile in phases. However, this approach introduces significant risk in the resulting hybrid, or mixed, methodology. Hybrid methods reduce the value of both

waterfall and Agile practices, adding risk to the delivery and overall programs. Typical government projects have uncertainty, complexity and unknowable requirements.

Clearly an incremental approach with frequent feedback is necessary to define, adjust and apply learnings throughout the project. A more reasoned approach is to adopt Agile wholly, but in a small group. Start with a pilot project and commit to Agile for all team members and stakeholders. Coaching, resources and a purpose-built Agile lifecycle management tool are key success factors.

Choosing a good pilot project requires paying attention to two aspects: Is the work a good candidate for Agile, and, can you set up the environment for success? For the first, choose a project that is especially likely to benefit from Agile: One where there is uncertainty around either the requirements or the solution, but also where there is relatively low complexity -- either technical or human complexity. In terms of environment, choose a project in which you can ensure the following: ❚❚ A small, cross-functional team that is dedicated to the work of the project ❚❚ A person who can fill the role of Product Owner by being embedded with and dedicated to the team and by gaining consensus from stakeholders on goals and features ❚❚ Co-location can reduce risk; a distributed team must have good communication tools

and strong facilitation skills among team leads Finally, you can pilot Agile without the express support of the customer, but you will achieve far greater results if customer supports the approach.

Often that first demo of working software and that first opportunity to provide feedback wins the customer over. Seek to sell the benefits of an iterative, learning-based approach.

Agile is a tremendously effective process methodology for many different environments, allowing for change and continuous input throughout the program or project. Done well, Agile allows teams to deliver more program value with less time and effort. Success requires re-education, training and a dedication to the practice, resulting in on-time, on-budget projects with less risk and higher acceptance.

In today’s environment of budget challenges, effective Agile projects can make all the difference. From last year’s A Common Approach to Federal Enterprise Architecture, “Success in accomplishing an Agency’s mission and optimizing resources requires a coherent and consistent understanding of program and service performance, and agile planning and development processes.

This coherent view and agility becomes more important in resource-constrained operating environments.” Or, as management consultant W. Edwards Deming wrote, “It is not necessary to change. Survival is not mandatory.” [MG]

MODERN GOVERNMENT · May - June 2013

29