Acquisition Matters

Buying agile without jumping through hoops

Agile Development Stock Image

Since the exposure of HealthCare.gov's difficulties, media and technology commentators have touted agile software development as one clear solution for what ails the way agencies buy IT. But there's no consensus on how to buy it, and today's government is understandably cautious about the calculated risk-taking that innovations like agile require.

The agile approach generally refers to iterative software development and continuous rapid delivery of working modules, based on constant collaboration between users and contractor and internal IT staff. Prototypes are tested and refined as they are delivered.

All about acquisition

Acquisition Matters is a new monthly feature, on FCW.com and in FCW magazine, by ASI Government CEO Kymm McCabe. For more guidance on adopting agile, see ASI Government's recent advisory, "Enabling Acquisition Success for Agile Development."

The good news is that agile development is cheaper than conventional approaches. It takes less upfront investment, and it squeezes out bugs and soaks up lessons through delivering and testing usable pieces of software along the way. Traditional development saves testing until the end, when fixing a complex, almost-completed application is harder, takes longer and costs more.

Other distinctive aspects of agile:

  • It demands adaptability, openness to change, and acceptance of trial, error and changing course. Neither the Federal Acquisition Regulation (FAR) nor its modifications specifically address agile, so it also calls for acquisition professionals to exercise creativity, alliance building and critical thinking.
  • It is not a product. Agile development is a service that builds a solution and is acquired using a broad statement of need rather than traditional detailed, lengthy requirements. When organizations embrace agile development, they agree to be agnostic about the shape of the final solution as long as it meets the need and is delivered within budget and on schedule.
  • It fails without teamwork and trust. Program and contracting professionals must agree on an end-state vision but avoid defining the features or functionality of the solution that's delivered to achieve it. That definition occurs throughout the development process as the product team and contractors build and test each new prototype and apply what they've learned to the next.

Agile requires buyers to allow change, adaptation and innovation during development in exchange for software uniquely suited to solving their problems at the end. Consequently, the agency must trust its buying team, and it, in turn, must trust the contractor team. Achieving that level of mutual reliance is no small feat in government, where today any change in course can be considered failure, waste, fraud or abuse.

Fortunately, experience has taught us a few things that can help limit the risk of the agile approach and make it well worth trying. FAR Part 39 already recommends using a modular acquisition strategy for IT so that capability is delivered throughout versus at the end of the development cycle.

Although there are no rules for choosing a contract type for agile development, some work better than others:

  • Fixed-price contracts for the whole solution are less than ideal because they necessitate modifications and change orders to address each unforeseen challenge, which inhibits trial and learning. Using fixed pricing for sprints or releases can work, but only after the government/contractor team has agreed on a development schedule and how to operate within it.
  • Cost-type contracts offer schedule and cost flexibility and the ability to provide performance incentives -- all of which are ideal for incremental delivery of segments of working software. Cost contracts require more skill and attention, however, to ensure that companies control their costs.
  • Time-and-materials and labor-hour contracts have come under fire in recent times, but they're well-suited to agile projects. They require using FAR Subpart 16.6 to make the case upfront that no other contract type will suit the project, but they allow an agency to buy a not-to-exceed amount of services to achieve a product vision.
  • Performance-based acquisition techniques also can help by allowing purchasers to focus on achieving a functional outcome rather than on complex requirements and strict adherence to a project plan. Agencies can have vendors propose performance work statements against a performance-based statement of objectives, thereby permitting them to apply their experience and ingenuity and incorporate lessons learned throughout the production cycle.

Ongoing involvement by all members of a carefully constructed integrated product team (IPT) is perhaps the key determinant of successful agile development acquisition. At a minimum, team members should include:

  • A product owner who represents the government organization that needs the software, and who has executive-level decision-making authority and daily availability for the project.
  • A CIO's representative who is able to enumerate the legacy software, security and IT policy constraints on the project and think through technical and infrastructure challenges to delivering software in small increments.
  • Users who describe the desired outcome and help test prototypes.
  • A contracting officer's representative who provides technical direction and input and performance monitoring.
  • Contracting professionals who plan and enact the acquisition strategy, administer the contract, and participate in software release, testing and acceptance.
  • A contractor development team whose motivation and success are intertwined with those of the agency team members.

As acquisition planning begins, team members and their supervisors should sign an IPT charter to guarantee the team will be continuously available to work on the project through completion. Losing or swapping out members of the original team can prove deadly to the agile approach because it requires much more trust and collaboration than conventional contracting.

Not every agency or contracting organization is ready to undertake agile development. It requires certain cultural attributes and full commitment from the entire enterprise. Successful agile development teams:

  • Share information. Teams must have free access to current software code and other information about the IT environment. If an agency is hierarchical, stovepiped and information-hoarding, it has serious work to do before going agile.
  • Use a team-based approach. Collaborative cross-functional teams fully supported by agency and program leaders are the sine qua non of agile development. If the agency does not respect team commitments, managers do not support them or team members cannot get the authority to make decisions, the environment is not ripe for agile.
  • Contract efficiently. Agile development requires an effective contracting organization. If third parties often second-guess, challenge or reverse buyers' plans, processes and contracts, leaders will not be able to act quickly or decisively enough to support an agile approach.

For more guidance on adopting agile:

See the recent ASI Government advisory, "Enabling Acquisition Success for Agile Development."

Agile development, like other innovative IT strategies such as cloud computing and shared services, requires taking calculated risks. In the current low-trust, oversight-laden, protest-prone federal environment, it can be difficult for contracting professionals to feel comfortable being creative and taking the necessary risks.

Congress, oversight agencies, political appointees, the media and the rest of us must develop an appetite for allowing federal buyers and program managers to take smart, limited risks if we truly want technology projects that deliver -- or over-deliver -- and come in on schedule and within budget.

2014 Rising Star Awards

Help us find the next generation of leaders in federal IT.

Reader comments

Sun, Jul 6, 2014 Shahid Shah United States

Great article, Kymm. The only thing I might add is that shared services in general (from a policy perspective that eGov is promoting) and SOA / micro services in particular (from a technical perspective) both would be great additions to next-generation acquisition strategy. Being agile also means using existing components, modules, capabilities, etc. before creating custom code. And, any custom code that is created should be catalog'd and shared as reusable components to prevent future costs. Again, great article -- hope you'll write more about it in the future.

Mon, Jun 30, 2014 Frank McNally

Hi Tim - why would you say that fixed price is the only way to go when buying agile? I think it can be made to work, but is not likely to be the ideal method of payment. What if you use a FP contract and the desired functionality of your product vision is achieved with 65% of your budget consumed? Wouldn't a T&M or cost type contract make it easier to "call it quits" when functionality is achieved vice fixed price? Otherwise I completely agree - you are not buying a product, you are essentially buying effort in support of functionality. This effort follows the vendor's interpretation of the agile process, so gov't focus becomes on the outcome. If we can achieve our desired outcome with less than the budgeted amount, we should be incentivized to do so. -Frank

Mon, Jun 30, 2014

Good article. However, no matter what s/w development methodology you use, you must document to produce artifacts for auditing purposes. Often, agile developers believe that they do no have to document anything, including their code. Big mistake, especially when you consider the information assurance environment!

Sun, Jun 29, 2014 Cliff Berg Reston VA

Extremely insightful article. Indeed, a slow-to-respond or overworked contracting organization can destroy agile projects, by causing gaps between work period, or by trying to force the wrong vehicle onto a project. Agile relies on quick turnaround. An IPT is truly essential, as Kymm points out. One of the challenges is obtaining "executive-level decision-making authority and daily availability" - people with exec level decisionmaking often do not have easy availability; thus, the PO must often be willing to delegate - otherwise, the PO will become a bottleneck in the agile process. I don't agree with Tim that fixed price is the best way to go: T&M is. But if one uses fixed price, Kymm is right that one must focus on high level goals and not try to define detailed requirements up front. Defining detailed requirements up front is another practices that kills agile projects, because requirements elicitation is part of the agile process itself. Performance based contracts can be difficult to use for agile because performance often depends on the participation of the government - and trying vendor compensation to performance in that situation is not fair and is likely to lead to a lawsuit - destroying the trust that is needed for agile. In the end, it is best to focus on defining the work process via the contract, and letting everything else follow its own path. Work should be thought of as work stream - instead of discrete projects. ROI should be around work streams - not particular projects or releases. Portfolios should be balanced based on maximizing the performance of a set of work streams.

Fri, Jun 27, 2014 Tim

Kim, Good read, but push more. Fixed price is the only way to go but you have to completely change your mindset. You aren't buying a product (or system), you are buying a process. You are buying sprints and acceptance tests. Once you make that leap I think you'll agree that fixing the price is the only way to go.

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