Brian Button

ANOTHER VIEW

Is agile software development too loosey-goosey for government?

Unforeseen changes can be a chance to craft more productive solutions

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. 


Related coverage:

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

Reader Comments

Thu, Sep 29, 2011

In my experience, the agile software development process has a focus on rapidly developing code. The key challenge is ensuring it is the right code that fits the work the users are attempting to perform with the assistance of IT. The way to ensure this fit is ensuring you start with the proper fundamental design that can then be rapidly reviewed and improved through the agile process. For complex software, this requires adequate requirements analysis and design concept development prior to writing a much code. If the user needs a gun and you start with a spear, it will be very difficult to iteratively improve a spear into a gun. The challenge is balancing speed of production with how well the software meets the users' needs. Initial upfront analysis and UI and architectural design is a critical step for many software projects that may otherwise miss the mark.

Thu, Sep 22, 2011 Software Development www.etli.com

Great post! Perhaps agile software development is too loosey-goosey for the government after all.

Tue, Sep 6, 2011

Agile programs I've seen in the past have produced very insecure systems. Seems that security functions get thrown off the raft first, with good intentions to place them back into a future cycle. Never seems to happen.

Tue, Sep 6, 2011

agile is merely a management process and methodology... it is no silver bullet especially to systems of systems and software intensive systems. some may see it as a way to evade CMMI related processes and avoid the documentation minutia. the real key to success is using the Activity Vector Analysis (AVA) when you initially put together the "team".

Tue, Sep 6, 2011

what hasn't been addressed is the GOvt's acquisition processes to allow for the acquisition of phases AND the acquisition of requirements development, design and implementation services from one vendor that does not circumvent the competition requirements of the FAR. Technology, processes and management goals are only 3/4s of the solution. How, when and what the Govt buys is equally important and usually the barrier to adoption of innovation.

Show All Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above