When Agile meets government Closing the culture gap

Increasingly, governments are looking to procure software built using the Agile methodology. This could not only demand changes to the procurement process, but also set up a potential culture clash between the rules-driven public sector and the more relaxed technology provider.

For an Agile procurement to be successful, the public sector business users and the Agile developers should work harmoniously. This means bridging a culture gap. From attire to work hours, from documentation to compensation, public sector workers and Agile developers typically have a different way of doing things. Learning to work together despite those differences requires some hard work on both sides.

The language gap

Agile literally has a language all its own. “How many story points is this epic?” “What is the team’s velocity?” Instead of project managers, there are product owners and scrum masters. If you’re a procurement veteran or a government business manager, your reaction to this is likely a big eye roll.

That was certainly Alistair Montgomery’s reaction. Montgomery is an IT manager for Transport for London (TfL). A long-time public official, years of developing IT projects with “waterfall” development left Montgomery far more comfortable in the world of fixed project plans and timelines.¹ When TfL first proposed using Agile development in the summer of 2015, he was deeply skeptical.

“I was set in my ways,” he says. “I thought [Agile development] was a gimmick filled with buzz terms and would never work. There were no Gantt charts. No plan. No set delivery. And when I heard about the ‘scrum masters,’ I said, ‘Come on, this is ludicrous.’”

Fortunately, Montgomery says, he was outvoted. “Within two weeks, I was a complete convert,” he recalls, laughing. What changed his mind? “It was fun,” he says. “There was no hierarchy—it was all peer to peer—and I could see progress quickly. That’s why people have been won around to this.”

Montgomery quickly learned that the new language actually reflects a new way of doing things, and Agile has been successfully adopted at the agency. But to partner successfully, public officials have to be ready to learn the language of Agile.

The rules gap

Of course, government procurement has a language of its own as well—the Federal Acquisition Regulation in the US federal government, Defense Federal Acquisition Regulation Supplement (DFARS) and Procedures, Guidance, and Information (PGI) in the US military, the Federal Acquisition Streamlining Act (FASA) for “small” acquisitions—and databases such as the Federal Procurement Data System, Federal Business Opportunities (FBO), Integrated Award Environment (IAE), and System for Award Management (SAM.gov). This “alphabet soup of acronyms” is the language of rules, regulation, and documentation—an alien world for many adherents to Agile who “just get it done.” Part of a procurement officer’s job is to use her expertise to meet rules in such a way that both the agency and the vendor can focus on the end result, rather than just the rules.

The trust gap

Traditional procurement contracts are designed to protect the government from scams—the underlying assumption being that every vendor might be a potential rip-off artist. Agile requires trust—and lots of it. Procurement contracts should facilitate Agile’s process. This means that lawyers and contract officers should craft contracts that prioritize the success of the collaboration, rather than crafting more punitive documents that create an impregnable fortress of words that ostensibly protects the client. In contrast, in the more collaborative Agile approach the close client interactions and regular demonstration of progress help build customer trust. In addition, the shorter time frames can shift power to the procurers.

For example, agencies that issue small, incremental contracts have the ability to switch vendors at any iteration. While not without some disruption for the agency, this may be preferable to being “married” to an unresponsive vendor for a long-term mega-project. Traditionally, agencies have tried to write penalty-laden contracts, but this often incentivizes vendors to deliver the bare minimum that meets the letter of the contract. A well-written Agile contract uses the power of competition to keep suppliers eager to deliver software that works. Meanwhile, vendors can set expectations in stages, nipping growing demands in the bud, educating the agency as to how much each feature or additional request might cost.

The contract gap

In traditional procurement, the contract covers everything—prices, delivery, and system performance. But in Agile procurement, the final product emerges through a joint effort during the process. The contract isn’t really the key to success, contract management is. In many cases, governments aren’t used to providing the sort of on-going input and support through contract administration, creating a gap.

A procurement officer can’t just award a contract and expect successful delivery. Regular engagement of the business owner and procurement officer throughout the process is essential. After all, Agile was originally created as a method for in-house software development in the private sector. This meant that the “business users” and the “IT developers” worked for the same company. Agile wasn’t envisioned as a contracting approach. Part of the Agile process is frequent—as often as every two weeks—demonstrations that share progress and challenges on the software. Intimate, hands-on involvement is critical to monitor progress and avoid unpleasant eleventh-hour surprises.

The risk gap

In a similar way, traditional government frameworks rely on contractual safeguards to minimize risk to taxpayers. Even today most public software buyers want a contract that spells out in minute detail precisely what the application will do, its total cost, and the delivery date. These protections are comforting to all involved—though they rarely translate into reality.

Procurement officers face a serious dilemma. Even if a “contracting shop” is on board with the Agile philosophy, many simply lack the experience to mitigate risk in an Agile environment. Moving from the theory to practice can be tricky. Contracting officers (COs) need viable options.

COs have been trained to hold contractors accountable for nonperformance through “hooks” in the contract. Strict definitions clarify what counts as nonperformance in terms of time, cost, and scope. Agile can’t operate well with so many constraints—to some extent, you have to have trust in your partner.

Trust is a risk. The CO would take the hit if a project went sideways. So, while COs can work with a team, they still often reflexively shrink away from the trust that their position now requires. One of the key roles the CO can play is to make sure that the contract is being monitored. A “trust and verify” approach can protect taxpayers and lead to working software. But it makes new demands and requires a new skill set for COs.

Recognizing this learning curve, the United States Digital Service has published the TechFAR to actively encourage less strict interpretations of contracting rules, to ensure that COs have the flexibility and skills they need.² COs may feel suspicious of talking with contractors about problems before writing requests for proposals. They don’t want to seem to favor any specific bid. However, informal conversations with experts can help COs understand the possible solutions and write more sophisticated contract proposals. There are several tools available to help COs navigate unfamiliar Agile terrain.

Working with a vendor to produce great software using the Agile methodology requires a true working partnership. Technical development doesn’t happen in isolation, but in close and frequent connection with business users and subject matter experts. Bridging the culture gap between government and Agile tech providers is key to fostering success.