Understanding why agencies should use agile and avoiding common mistakes

Many government procurement officials are nervous about contracts to purchase agile software and IT solutions, perhaps for good reason. It’s hard to feel comfortable buying something when you aren’t sure what the final deliverables will be.

However, according to Office of Management and Budget PortfolioStat briefings, most federal agencies report that more than half of their IT development efforts use agile today. The benefits of agile development are powerful; an effective agile approach brings innovation as development takes place, moves more quickly than other approaches, and rarely produces a solution that an agency finally rejects and discards.

Thus, learning how best to procure services from vendors who use an agile approach is important. It is critical now and will only continue to grow increasingly important in the coming years, so how do we make sure that federal agencies and departments are properly procuring agile services? And going one step further, can they use agile methods as they procure?

Using agile methods to acquire IT services

At the same time as agencies are being asked to buy services from agile vendors, leaders are asking whether agile principles can be used within agencies.

Questions often start with the procurement office, because the procurement office is expected to know how agile works as a result of buying agile IT development services from agile vendors. Unfortunately, though, agile methods used to develop software do not all translate directly into methods that can be used to purchase goods and services. There are, however, several parallels and some beneficial lessons to be learned.

What does “agile” mean with respect to procurement?

The practice of agile procurement is too new to have an agreed-upon definition. However, there are several components that all truly agile acquisitions have in common.

Agile procurements will:

• Ensure that procurement efforts are aligned to the purchasing agency’s mission.
• Be sufficient to achieve mission success.
• Break large procurement efforts into smaller tasks that can be accomplished incrementally.
• Procure quickly, but accommodate changes to the needs of program officials and their users as an acquisition progresses incrementally.
• Often, though not always, involve a demonstration of actual vendor capability and approach to the potential solution — a “free sample,” “challenge” or “pilot program” — from several competing vendors, rather than relying only upon written vendor proposals or assertions made in oral presentations.
• Make it possible to add and remove vendors in support of a program so the agency can change direction quickly, if needed.
• Encourage users to collaborate and try results of each increment in a real-world setting in order to collect feedback that will help inform the future of a project.
• Accept (and even welcome) customer requests for change. Change requests mean that people are paying attention, care about what happens, and plan to use the solution that is being procured.
• Measure success based upon outcome achieved and user adoption rates.

Agile acquisition hurdles in the federal context and how to address them

Hurdle #1: A focus on the lowest unit prices doesn’t always produce the lowest cost.

Federal procurement often focuses on achieving the lowest cost per item or service. This focus fails to recognize individual items that are rejected or discarded after purchase. For example, an agency that purchases 10 different software applications, but then discards four because they don’t meet user needs, should not consider their procurements a success — regardless of the price for each of the 10 individual applications. If the traditional vendor charges a price of $1X for each of the 10 software systems for a total of $10X, but an agile developer charges a unit price of $1.5X (50 percent higher) for each of the six applications deemed acceptable for a total of $9X, the agency will see a lower cost with the agile developer because many of the traditionally procured items are discarded.

Hurdle #2: There are good reasons for contracting staff to remain independent from program staff — but they can still collaborate.

The separation of responsibility in government between procurement and program staff ensures that a single person cannot determine the need for an item, which reduces the risk of corruption. However, a key benefit of the agile approach is achieved when the collaboration between those doing the work (procurement staff), their customers (program staff), and from the ability of agile team members to step into one another’s roles to make sure work is done efficiently. Thus, agencies must find ways for contracting and program staff to work together before, during and even after contract award. Programming staff after is important, because the agile model calls for an openness to change throughout a period of contract performance.

Hurdle #3: Measuring success in procurement will always be challenging — the agile approach will not change that.

As with agile IT, user acceptance is an important supplement to traditional measures of value and procurement success. Cost must be considered carefully, but ultimately the core measures of procurement success tend to be:

• Procuring the needed items and services required to carry out the agency’s mission;
• Achieving an outcome that advances the agency’s mission.

User acceptance/adoption of the procured item or service is an important metric of procurement success that may be under-utilized now, but that fits well with an agile procurement model.

Success factors and mistakes to avoid

Key Agile acquisition success factors include:

• Identifying user groups and real users to participate in developing use cases, reviewing designs and providing feedback on the product as it is developed incrementally.
• Dividing development (or procurement) into increments that each have real value, can be used by customers and build upon one another.
• For a large program, engaging several vendors to provide agile teams so that an agency can continue or increase use of effective vendor teams but decrease or discontinue use of ineffective teams.
• Specifying the types of work that are needed so that vendors can assign the best-suited team members.

The most significant mistakes include:

• Procuring awards based entirely on low price. This will eliminate a vendor’s motivation to accommodate evolving agency and customer needs and learning — thus discarding the most significant benefits of the Agile model.
• Failing to identify a clear end date, completion criteria and the government product owner. Each of these is critical to controlling cost and establishing mutual understanding.
• Agency staff failing to adequately participate in the agile process (especially as a product owner). If key government individuals do not have time to participate, the schedule (or potentially the entire process) may be compromised.
• Hesitancy to design and release partial functionality to real users. Failing to release incrementally prevents real feedback and incremental adoption.
• Accepting a design that does not provide valuable working features at each sprint. (This allows an agency to terminate an agreement mid-way, but still have a valuable product).

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.