Back to ❮ 18F Blog

A core concept of agile is that teams are cross-functional: the team collectively possesses all of the skills necessary to get the job done. We embrace that at 18F, and take it a little farther, and not just on agile teams.

Modular contracting is an acquisition strategy that 18F uses with many of our partners and our internal programs. So, why do we love modular contracting and how does it make procurement better?

At 18F, we often advocate for modular contracting — the practice of breaking up large, custom software procurements into a small constellation of smaller contracts. In doing so, we’ve learned that we’re more effective when promoting that message to people who are familiar with the fundamentals of modern software development practices.

In the previous post, we wrote about how product management works in Path Analysis and Experiment & Iterate phases. In this post, we’ll discuss how 18F product managers support our partner agencies who are procuring the services of industry contractors to help achieve their mission.

As agencies try to adopt agile development practices and modular contracting methods, there are several anti-patterns that we have noticed through the course of our work. We address how these can hinder success and alternatives to consider.

In 2015, 18F had an idea for a better way for federal agencies to hire private vendors to build products and services using agile development techniques. We wanted to see what would happen if we used an existing government process (called a blanket purchase agreement) and tailored it to the needs of agencies looking to update their digital services.

Here are five procurement hacks — both in the context of our Agile Blanket Purchase Agreement (BPA) and in general — that we’ve made in the past few years to make the procurement process a bit more joyful and effective.

The process of developing and issuing RFPs is often viewed as a one off - a special activity that occurs infrequently and in isolation. What if we applied the principles of iteration and continuous improvement to the way that RFPs are developed?

Adopting this “smaller is better” mindset as a way to overhaul a large, complex legacy system can feel counterintuitive. But the notion of smallness — of distilling complex, interdependent tasks into achievable units of work — is fundamental to building modern software in both the private and public sector.

In product development, we often use prototypes to understand user needs and reduce risk. Prototypes are a great way to test out ideas or approaches before you actually commit to building anything, but governments are not always set up to develop and use prototypes efficiently before building digital services.

The way government is writing contracts is wasting time, handcuffing industry, and preventing programs from meeting mission mandates. There’s a better way through an Agile Contract Format.

Monolithic procurement — large, complex, multi-year contracts, which are common in government IT procurement — can appear compelling to agencies that use them. The Technology Transformation Services (TTS) is a strong advocate for an alternative approach known as modular contracting (aka modular procurement).

The Technology Transformation Services (TTS) has been working with the Forest Service in an effort to move their permitting process online. We’ve previously written about how doing this work in the open can benefit other agencies with permit systems. In this post, we’ll focus on why it’s important to have a product owner, what that looks like from the Forest Service’s perspective, and why a product owner is critical to successful projects.

Alaska’s Department of Health & Social Services is working with the Technology Transformation Services’ Office of Acquisition on a new approach to product and acquisition management to develop a modern, integrated eligibility system for their Division of Public Assistance. We’re experimenting with a transparent approach so that anyone can see, and provide public feedback on, our progress.

The Technology Transformation Services has been working with the Forest Service in an effort to move their permitting process online. In this post, we’ll focus on how taking a step back to check your assumptions can reduce the risk that your project will go off course.

From our experience with the Agile Blanket Purchase Agreement (BPA), we’ve found that in order to build effective cross-functional teams and successful IT projects, we need alignment on several principles

The Technology Transformation Service (TTS) has been working with the Forest Service since August 2016 on what will eventually be an agency-wide system to process permit applications. TTS is primarily helping the Forest Service hire private vendors for this work, rather than building it ourselves, and one way we’re improving that process is through “discovery research.”

One of the advantages to working across government is that we often have opportunities to share insights from other projects, repurpose code, and connect otherwise disjointed efforts. This happens in direct work with our partners, but also on our blog and in our GitHub repository. Our code, guides, and other work are all free for other government agencies and the public to use for their benefit (and we love when people do).

To folks new to government, one of the most surprising differences between our work and work in the private sector are the barriers in accessing commercially available software, and commercially available Software as a Service (SaaS) in particular. There are many good reasons for these barriers but digital teams need great tools to get work done and compliance requires tradeoffs associated with time to initial delivery and accommodation of constraints that are different from the private sector.

Our recent work with state government agencies in California and Mississippi provides some powerful examples of how 18F’s commitment to working and learning in the open can provide enormous benefits — even to states that are not yet working directly with 18F.

The Technology Transformation Service recently held an industry day to talk to the private sector community about our vision, our projects, and how GSA and vendors can work together to bring modern digital services to the federal government. For that event, California’s Stuart Drown recorded a short video talking about 18F’s work with California on their Child Welfare System.

Built on the lessons learned during the pilot phase of the Digital Acquisitions Accelerator, the accompanying playbook examines the current acquisition landscape and provides an approach to procuring custom software solutions. Our goal is to make the government a smarter and more informed buyer of digital products and services.

The 18F Micro-purchase team recently introduced the ability to bid on an auction via API. This feature is part of our long-standing commitment to experiment and iterate towards the easiest bidding process for vendors. Like everything in the platform, we treated this feature as an experiment to learn how it would affect bidding behavior and the final price of auctions. Here’s what we learned.

This is the second in a series of three blog posts that provide a step-by-step guide to how we led the inception workshop.

As we work through this pilot phase of the Digital Acquisition Accelerator, we’ll be sharing our work and the lessons we learn. We hope this will help other interested teams follow along and also give the public on opportunity to give us feedback on our pilot. Here are three techniques that our team practiced with the FBI and Treasury teams during the recent kickoff of the pilot.

Two months ago, the 18F acquisitions team ran a public micro-purchase auction to find a vendor to develop a small new feature for 18F's cloud.gov, and for the first time after several successful micro-purchases for other products, the contracted vendor didn’t deliver the code on time. This was very interesting to us we’re early in the life of the micro-purchase platform, and we believe that failure is a great way to learn. In the spirit of experimentation and sharing our lessons, here’s how we went about analyzing this, and here’s what we learned.

The Office of Federal Procurement Policy (OFPP) released a memorandum today that encourages agencies across the federal government to pursue innovative approaches to acquiring goods and services. Given the growing importance of digital acquisitions, OFPP is also launching a Digital Acquisitions Pilot along with the memo.

Today, we're pleased to officially say that Pool Three of the Agile BPA is ready to launch. Although we announced the awardees earlier this year, there were multiple protests related to the Agile BPA. Last night, we learned that the final protest has been resolved.

If you or your agency have thought about working with 18F but are unsure of how we work with our partners, we have a new set of guidelines to help you out. The 18F Delivery Partnership Playbook is specifically targeted at federal offices interested in working with 18F to build digital services.

In August, we announced the Full-stack Development Pool vendors for the Agile Delivery Services Marketplace. As we continue to work on the alpha version of this marketplace, we're beginning to plan out additional micro-markets as well.

As the first Agile BPA awards are now being issued, we asked three members of the team about the process and the lessons they’ve learned so far.

Calling all agile vendors...get ready! By the end of this month, GSA will be releasing a Request for Quote (RFQ) for the alpha version of the Agile Delivery Services Blanket Purchase Agreement

Clients of 18F Consulting frequently ask for help defining labor categories for agile contracts. We’ve published these definitions in a public GitHub repo so other acquisition professionals can benefit from them, too. Read on for more details.

The federal government and industry community have been talking about the need for software acquisitions to keep pace with technology cycles — typically 1-3 years. In today’s dynamic environment, however, not even that is fast enough.

The history of open source software is a record of steadily turning tremendously expensive custom-built solutions into freely available infrastructure that you can simply take for granted. What once were astoundingly sophisticated, expensive human endeavors have become open source tools you can drop into place in your project on a whim.

Today we're announcing our first product launch: FBOpen, a set of open-source tools to help small businesses search for opportunities to work with the U.S. government.