Buying agile without jumping through hoops

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.

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.

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.