Making USASpending.gov Agile and Open Source

Lead Scientist and UX Researcher April Osajima is talking to tourists at the U.S. Capitol Visitor Center.

She needs their opinions on a website that, once live, will do something unprecedented— enable anyone with an Internet connection to gain visibility into federal spending, starting with annual totals and zooming in to see dollar amounts for each sector, each program, each city, each contract.

Booz Allen Hamilton, teaming with Kearney & Company, is building it for the U.S. Department of Treasury as part of its effort to implement the 2014 Digital Accountability and Transparency Act (DATA Act), designed to give Americans a clearer understanding of how their tax dollars are spent.

As breakfast turns to lunch, April spends a few hours opening up her laptop for a friendly slice of outside-the-Beltway citizenry in compliance with federal guidelines governing research procedures. All she has to show people at this point is a mockup of the homepage, USAspending.gov, but it’s enough to elicit reactions that will change the course of the site’s design.

Her trips to the Capitol are just one part of our trailblazing approach to the DATA Act’s implementation. We’re calling it Open Disruption, and with open-source code, continuous delivery, and an Agile design methodology, it’s almost as radical as the total spending transparency that the DATA Act aims to achieve. 

Traditionally, .gov site-builds have adhered to a sequential design process known as the waterfall method. It dictates that, before a single line of code is written, developers and stakeholders must co-author and sign a beefy set of requirements that describes the exact form the final product will take, and the exact process by which it will come together. It’s then built, exactly as specified.

If, somewhere along the way, a better path to accomplishing the project’s goals suggests itself, too bad. The requirements, once approved, cannot be altered.

The Agile methodology we’re using to implement the DATA Act looks different from beginning to end.

First, instead of defining a set of rigid requirements upfront, the Booz Allen team worked with Treasury and representatives from more than 25 federal agencies to establish the core functionalities the final product needed to have, according to Booz Allen Project Manager Drew Leety.

“The focus is more on making sure the site offers the functionality it’s supposed to and less on the process that drives how we get there,” Drew says.

Accustomed to having all of their questions answered up front, some stakeholders were nervous about this approach. The second step in the Agile process eased their concerns.

“We brought user acceptance testing in at month two,” says Drew.

This means that, at a point when a waterfall team would still be gathering requirements, we unveiled a bare-bones prototype that our agency partners could sit down and use. Skeptics became believers when they saw that their top priorities were already being realized.

“We picked certain features that we knew they would want and got those ready,” Drew says

Next came Agile’s third and primary stage: continuous delivery brought about by two-week sprint cycles. While April and our other user experience (UX) researchers gathered agency feedback on the prototype, our developers spent 14 days readying a second release with additional capabilities.

Then, while prototype 2 was put through the ringer, we incorporated lessons from the first round of tests into a 3rd-stage version, and so on.

“It’s almost like real-time requirements and developing going on together,” says Drew.