Is agile software development too loosey-goosey for government?

The National Defense Authorization Act for fiscal 2010 outlined clear guidelines for “a new acquisition process for information technology systems.” In fact, Section 804 of the act laid out specifics for this framework, such as: getting early and consistent involvement from the user; developing multiple rapid increments of capability; having early, successive prototyping to support an evolutionary approach; and using a modular, open-systems approach. 

Although the act does not specify it by name, the guidelines reflect the core characteristics of agile software development, a group of methodologies where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. The declaration in the DOD legislation is just one of many signs that agile software development has become a cornerstone for government IT projects and the way software will be written in the future.

Yet although agile development might be a term being heard frequently in the halls of the Pentagon, managing any project carries inherent risks. In their book “Waltzing with Bears: Managing Risk on Software Projects,” Tom DeMarco and Timothy Lister cite some of the most common challenges, including schedule flaws, requirements inflation, turnover, specification breakdown and underperformance. 

FBI at last ready to go live with Sentinel case management system

The good, the bad and the ugly of agile programming

Some of the most threatening of these are inaccurate schedules and complications caused by requirements changes or delays introduced by dependencies on other commands or directorates. Creating software is a highly delicate endeavor, and the idea of building an accurate and precise schedule at the beginning of a project that can stand up to the inevitable changes in requirements and environment is inherently flawed.  Life isn’t static — requirements and priorities change whether we want them to or not — and the business, political or physical environment in which a project needs to function will undoubtedly change as well.

Agile principles

Agile methodologies also allow a different response to changes than approaches that seek to limit or prevent modification of an initial schedule. In the agile world view, factors that force requirements to change are considered an opportunity to refocus a project’s progress toward a more refined set of goals, affected by and rooted in those same real world changes.

Projects governed by methodologies that don’t allow or account for such changes run the risk of being accomplished according to plan, delivering exactly what was asked for, on exactly the right day, and in the end providing an elegant solution to the wrong problem. Traditional government IT acquisition projects have run into this exact problem for years, given their multiyear plans and timelines — they’ve delivered well-crafted solutions to problems that were relevant months and even years ago.

Instead, using change as an advantage allows an IT manager to ensure that scarce funds are invested in requirements that will satisfy the user's evolving needs, rather than delivering stale or unwanted functionality. This is the agile software principle of valuing interactions with customers more highly than building to a predefined or unchanging specification.

Obviously, accepting change as part of a project plan means that the resulting capabilities may vary from what was initially scoped. In fact, one agile principle is frequent, incremental planning rather than sticking to an overall, detailed plan. It is this frequent attention to incremental adjustments in the plan that will allow organizations that have traditionally delivered systems after months or years of work to be able to adapt to their changing environments and deliver more often.

Planning on agile teams happens frequently, focuses the team on short-term goals (between a week and a month for deliverables), and allows for shifts in feature priorities based on actual needs. Newly created software features or features that have become more important are scheduled sooner and those that are less important are delayed and may slip out of scope. 

Agile planning

At the highest levels of planning, every software feature has an estimate that is used for budgeting, planning and project tracking. At the lowest, every increment of work focuses on planning and delivering highly valued features identified by the IT project manager or customer. 

In the agile universe, the team delivers at the conclusion of every increment a working system with shippable functionality that reflects the highest-priority features.

This is another guiding principle of agile software development: valuing working software over other work products, such as comprehensive documentation. It’s not that documentation is not important. But it should support the product that is being built and not lead the product being built. Through time and close collaboration, a working system emerges and evolves that solves the needs of the requesting organization as those needs have evolved. Entire working features are added in order of priority until the system is delivered.

In the end, agile methods are about much more than just development. They have a rich planning ecosystem, allowing projects to evolve and adapt as circumstances dictate. An evolving plan allows contractors and their teams to focus on what is important. To paraphrase Kent Beck, the originator of Extreme Programming, “Agile doesn’t have a risk management strategy; agile is a risk management strategy.”