Drying up the Waterfall – The Agile Approach in Government

As the demand for Information Technology in government rapidly grows, the push to usher in faster, more dynamic, and flexible IT solutions has escalated.  Recognizing this changing landscape, GSA has championed the agile acquisition process as the most effective approach to the increasing demand for fluid, iterative, and response-oriented software development.  While the proponents of the change are numerous and optimistic, successful implementation still hinges on full buy-in from acquisition professionals and the fortitude to upend the previous waterfall acquisition process which has been the federal government’s model of choice for decades.

What is agile development?

Around the turn of the century, the IT development industry was suffering from a high failure rate.  The agile model began to change the direction of software development in 2001, when a group of IT professionals gathered to brainstorm ideas that could improve the success rate of software development projects.    In doing so, they published the “Agile Manifesto,” a description of values and principles intended to simplify IT integration.  Among others, the main tenets are:

  • individuals over processes and tools
  • working software over comprehensive documentation
  • customer collaboration over contract negotiation
  • responding to change over following a plan

The authors emphasized that the items on the right are still important, but not as important as the items on the left.  Overall, there is a recurring theme of response-oriented, flexible, iterative, and collaborative development.  This stands in contrast to the Government’s previous model, known as the waterfall.  In the waterfall approach, a software project is defined by pre-defined checkpoints: Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance.  Testing was not iterative and occurred at a defined point near the end of the process.

Why would the agile approach work for the Government?

An iterative, agile approach is more naturally mated to IT.  The existing waterfall model was never designed for use in information systems.  It was intended for vastly different industries such as construction, where after-the-fact modifications were prohibitively difficult if not impossible.  The waterfall was simply adopted for use in software from these other industries.  However, by its very nature, software needs and functions change over time, and alternate ideas to make a program better can often happen during development.  An agile approach conforms to these unforeseen twists and turns, whereas a waterfall approach might not recognize the issue until it is too late, causing abandonment of the project and taking billions of dollars with it.  In the government, these limitations became exposed over the years, even though the government largely stuck with it and did not pursue potential replacements.  However, with the increasing urgency to reduce waste and increase efficiency across the board, GSA has identified agile development as an urgent priority moving forward.  In response to this urgency, GSA has moved with uncharacteristic speed in issuing a RFI seeking vendors with agile capabilities.  Whether or not these vendors have previously worked with the federal government is not relevant.  In fact, GSA has prepared to on-ramp new vendors, giving them a chance to showcase their abilities through competitions such as 24-hour development challenges.  This approach empowers new firms with agile capabilities to directly compete against more established firms.

What are the main obstacles to the adoption of agile development?

When a sweeping change is mandated with great speed, it is bound to encounter resistance. Some of this resistance can simply be attributed to personality. There will always be those professionals, within the federal government or any other industry, with reactionary tendencies.  Such individuals are less likely to embrace rapid change, and must be convinced that this is not just another “flavor of the month” initiative.  Within the industry, it is considered reasonably likely that agile development can take root if 80% of the workforce endorses it, or at least is willing to try it.  The federal Government faces an initial challenge of getting to that 80/20 benchmark, as it is known to have a status quo, conservative, stay-the-course culture that may prove to be suspicious of the iterative approach.  GSA Administrator at the time, Dan Tangherlini, admitted as much during a speaking function in October 2014 when he stated, “We spent 20 years learning how to do the waterfall. We built agencies and consultancies around waterfalling and now everyone shows up and says, ‘okay, that’s out. Do it agile-y.’”  Tangherlini makes an important point by revealing that GSA’s goals of rapid transformation can and will conflict with the existing culture, which is deep rooted and will take time to dislodge.

Furthermore, agile development faces more serious systemic obstacles beyond the simple cultural resistance of the “old guard.”   There are entrenched processes in place that were formulated around the waterfall model.  These must be evaluated as they strain to accommodate an agile approach to IT development.    These processes include Exhibit 300, a document that agencies are required to use to lay out their capital asset plan for major systems, and Earned Value Management (EVM), a methodology catered to measuring implementation progress around waterfall development.

But perhaps the most soaring hurdle for successful agile implementation is the structure of government itself.  Agencies are traditionally group-consensus entities, often featuring different business silos, with different interests, within the agency.  These silos are notorious for having limited communications among each other, making it extremely difficult to establish a single point of accountability that can prioritize the direction of an IT project.  Finally, Contracting Officers (COs) have been rigorously trained to obtain detailed requirements up front; in direct conflict with the very point of agile development, which is to NOT define requirements up front.  Tim McCrosson, senior policy analyst within the Office of Management and Budget office of e-government and information technology, perhaps said it best when he noted that CO’s must re-compartmentalize IT procurement by re-casting their perception of what they are buying.  He believes agile development can overcome this hurdle “if we can get out of that mindset that we’re buying a product and get into the mindset of we’re buying a process.”


Agile software development appears to have a bright future in federal Government IT procurement, though not without challenges.  GSA must be prepared to encounter a larger degree of resistance and a slower transition than they may recognize.  However, if they stick with it, the more natural, malleable, and iterative means of developing technology solutions should outweigh the obstacles.  The potential beneficiaries of an agile approach include established vendors, new vendors, GSA, the federal Government itself, and most importantly, the American taxpayer.

Connect With Coley


*What are you Interested In?

You have Successfully Subscribed! Someone from Coley will be in contact with you shortly.

Pin It on Pinterest

Share This