This guide will help you understand how your agency team and 18F can work together successfully. You'll learn what to expect and how our two teams will form a fed-to-fed partnership that may be different from work you’ve done with private vendors. Many of these ideas build on the U.S. Digital Services Playbook.

The first thing you may notice when partnering with 18F is that your team will be heavily involved in the day-to-day work of the project. We’ve found these close partnerships that pair our technical expertise with your program knowledge are most likely to deliver projects that fulfill federal rules, stay within budget, and provide excellent value to the public. We’ve laid out some methodologies and tactics below that will guide the project.

Methodologies we’ll use together

• Letting users guide our work
• Working in an agile way
• Building in the open

Tactics we’ll use together

• Understanding your problem first
• Partnering with an empowered product owner

In this document, we’ll explain each idea and how it will influence our work together.

Download a PDF version of the Principles here

Methodologies

Letting users guide our work

For your project, the most important people are those who’ll use the product or service that we build together. They might be part of the public interacting with your agency for the first time, experienced outside stakeholders, or staff inside your organization. These people have goals to achieve and obstacles in their way. Together, we’ll ensure that the design, development, and implementation of your solution helps lower those obstacles and allows your users to be successful.

What does this mean for you?

We'll interview and observe users interacting with your service or product and use that information to help guide the team’s work. Later, our joint team will put real prototypes in the hands of users every couple weeks and interview them about whether the product is meeting their needs. This frequent testing with real users will help ensure that the product we build together is intuitive for them to use and solves the right problems. You know your program and mission best, and you’ll help identify and recruit users for the joint team to interview.

Working in an agile way

We develop software using agile and lean methodologies. These approaches are the norm in the private sector, and they differ considerably from basing work on requirement documents. Instead of determining all the necessary features up front, we’ll build the product in stages, testing along the way to ensure that we’re meeting user needs and responding quickly to any changes in requirements, goals, policy, or outside factors.

It can be stressful to start a project without being able to clearly list the final features. But we will start out with a very clear sense of your goals, and our techniques will ensure that we hew to those goals closely, building on successes along the way. Our techniques will also give your agency good visibility into the project’s evolution, timeframe, and budget.

What does this mean for you?

Every couple weeks, your team will work with the 18F team to generate a list of prioritized tasks. Then we’ll address several of these tasks and get feedback from users to help guide the next period of work.

At each stage, we’ll jointly define metrics that we’ll use to test whether our work is supporting your goals. This approach allows our teams to stay both on target and flexible. The tradeoff is that the confidence we’ll gain is limited to work in the near future, and we won’t be able to say exactly what features will be in your solution by a certain date. But by regularly revisiting our desired outcomes and prioritizing the needs of your users, you’ll know that we’re building the most important functionality at every phase of the project.

Building in the open

One of 18F’s core principles is to make our work available to the public whenever possible, magnifying the value of our joint efforts. We do this in two ways:

• Using open source code in product development
• Conducting project activities in publicly-viewable forums whenever possible

These methods are proven to help build stronger services, save government resources, and better fulfill our duty to serve the public. Learn more from the Federal Open Source Policy.

Of course, we’ll work together to ensure that any contracting, national security, personally identifiable, or other sensitive information is properly protected.

What does this mean for you?

• Security: Making source code available for public scrutiny can help improve the security of a product while allowing the team to maintain full control. (Again, we always do the necessary legwork to ensure the security of sensitive and confidential data.)
• Streamlined communications: Publishing research reports, documentation, and other artifacts about our project online makes it easier for our joint team to access it. When we work together, you won't need to access our VPN or be located in a specific place to keep up with the project.
• Transparency: Working openly helps us proactively communicate about our progress with your stakeholders.
• Collaboration and network effects: Working with open source software allows us to build off work done by others. Sometimes this means we're able to start with something already in progress, and sometimes it means we can improve on the work done elsewhere.
• Sustainability: The flexibility of open source software allows our teams to focus on building the best product rather than negotiating license agreements. In addition, relying on widely used tools and programming languages means you’ll be able to more easily hire qualified vendors or employees to support the product after 18F transitions off the project.

Tactics

Understanding your problem first

The first thing we’ll do together is gain a shared understanding of your problem so that we can translate it into information that a technical team can use to build or buy a solution.

What does this mean for you?

Most likely, our work together will start with a “Path Analysis.” A Path Analysis typically lasts eight to ten weeks, and we use that time to gain a deep understanding and shared vision for your problem. At the end of this phase, we’ll provide a roadmap forward that defines your problem in terms a technical team can use to hit the ground running.

Other partners might take the time to do this, too. But we carve out this initial stage, rather than lumping it into the whole project, so that at the end of the phase, you have excellent documentation to build or buy an effective solution with any partner — whether that’s 18F or a private vendor. Indeed, if we determine we aren’t the best partner to meet your needs, we can help you get set up with another office within the Technology Transformation Services or help you hire a private vendor.

Partnering with an empowered product owner

Achieving success depends on building a close working relationship between 18F and your team. To make that happen, we’ll work with an empowered product owner from your agency. An empowered product owner is someone who understands your organization, the problem we’re solving, and can advocate for the product we ultimately build together. They’ll be responsible for establishing and carrying the long-term vision of the project, implementing a strategy, and guiding its progress, as informed by user research. This person will work closely with the 18F team as a subject matter expert on your agency and help us jointly navigate the complexities of interoffice and stakeholder relationships.

A successful product owner has:

• Authority to make decisions: The product owner removes obstacles and helps the team work as quickly as they can. They make decisions independently and have sufficient authority to make changes large and small to the product without additional review from superiors.
• Time to work with us: The product owner is just as much a part of the team as designers, researchers, and developers. Product owners should lead the product team: crafting a product vision and strategy, prioritizing work, evangelizing to stakeholders and users, working with developers and designers, and measuring results.
• Subject matter expertise: Public service work is detail-oriented. It’s often focused in the niche areas of expertise our team doesn’t have. While we bring technical expertise, your product owners provide guidance and expertise about your program and users.
• Advocacy inside your agency: The product owner can identify stakeholders inside your agency and gain their support. Whether we have research results to present, a major milestone to celebrate, or questions for another office in your agency, the product owner is our connection to the relevant people.

What does this mean for you?

The product owner will lead the product team. While they may not already know best practices in product management, or agile or lean methodologies at the outset, our team will coach them to learn the necessary skills. We've found that an empowered product owner dramatically shortens the time to delivery, reduces overall risk, and creates solutions that align with the agency mission while serving user needs.

Questions

If you already have a primary contact at 18F, they can answer any questions you may have about these principles. If you don’t yet have a primary contact, please reach out to our Agency Partnerships team at inquiries18f@gsa.gov. We’ll be more than happy to discuss possibilities and concerns.