How a Two-Day Sprint Moved an Agency Twenty Years Forward

At 18F Consulting, we experiment with ways to empower agencies to build cost-efficient, excellent digital solutions. Recently we partnered with the Department of Labor’s Wage and Hour Division (WHD) to run a two day “Design/Dev Agile Sprint.”

Background: Investigators in Wage and Hour Division

The Department of Labor’s Wage and Hour Division is responsible for enforcing a wide variety of federal labor laws, including those requiring the minimum wage, overtime, child labor protections, and family and medical leave laws. Over 1,000 investigators, working out of local offices nationwide, and often literally in the field, investigate employers to determine compliance with these laws. To gather the information they need, they travel to a wide variety of businesses, including farms, restaurants, hotels, retail shops, construction sites, hospitals, and many others.

While conducting investigations, Labor employees often turn to the Field Operations Handbook (what they call the FOH) for guidance. The handbook is an operations manual that provides interpretations of the law, procedures for conducting investigations, and general administrative guidance. It reflects policies established through changes in legislation, regulations, significant court decisions, and the decisions and opinions of the WHD Administrator. The handbook is a critical tool for WHD staff.

How might we help DOL’s Wage Hour Division move forward with a quick win that would demonstrate what modernization can mean in a meaningful, iterative way?

The current landscape: Publishing in the 21st century

The handbook consists of four five-inch-thick binders containing printed and photocopied pages. These binders are replicated and distributed across numerous regional and local offices. The handbook also exists as online PDFs, where each chapter or subsection is published as its own PDF. With these two options, investigators don’t have an easy way to quickly access and search for much-needed information that helps them complete investigations, particularly when they’re working out in the field.

The challenge: How to move this project forward?

The division’s modernization team wanted to bring the handbook into the 21st century by placing it online and providing robust search capabilities. This was not a radical idea.

Departments across the federal government often operate under three constraints that can make these projects a challenge:

• Lack of internal design and development staff dedicated to prototype or solve problems.
• An often arduous vendor solicitation process to hire the right team to help with such projects. (WHD is experimenting with using a modular, agile contract strategy.)
• Internal teams which may lack the time, tech literacy, or processes in place to support change. How do you support change you don’t quite understand?

18F Consulting is already working with the division’s modernization team on a much larger effort—the incremental modernization of an aging management and investigation system. While that was underway, we wondered, “How might we help the division move forward with a quick win that would demonstrate what modernization can mean in a meaningful, iterative way?” With the guidance of Tom Giancola, a WHD investigator, and other WHD stakeholders, we chose to build a proof of concept for modernizing the handbook.

At 18F Consulting, “Prove by doing” is our motto.

The proof of concept sprint: From design to prototype in days, not months

In this two day sprint, about eight of us gathered to:

• Prove that the division could produce a user-centered, technically feasible solution in days, not months.
• Model and invite WHD team participation in human-centered design and agile development practices.
• Produce a living, breathing pilot or minimum viable product (MVP) that the division could test with some of their investigators as they continue to build out this solution.

Who participated?

• One designer and two developers from the 18F Consulting team
• One product owner from the WHD modernization team
• Three WHD Investigators who frequently use this handbook
• Three to five representatives from the division’s communications, policy, and document management teams. They helped us understand different use cases in the process and the current state of document creation, editing, and publication.

Tuesday morning: Kick off!

We facilitated a two-hour kick-off meeting (sometimes called an Inception). It got the group aligned around the problem and to agree on a plan moving forward.

During this Inception we:

• Identified the different types of users and prioritized which ones we’d focus on for our initial proof of concept.
• Listed the goals and non-goals of the project (non-goals are great for parking valuable points that are out of scope for the current iteration).
• Brainstormed ideas for initial features and prioritized them based on user value and build-feasibility.
• Ensured there were no timelines or stakeholder needs that would cause problems in the near future.
• Explored possible risks to the success of this project. We collaboratively grouped them by themes and discussed ways to reduce the risk moving forward.

Tuesday afternoon: Start to build

The designer, developers, product owner, and investigators (our primary users) hunkered down in a work room to make the first-ever, living, modern digital version of the Field Operations Handbook (FOH)!

We created an ad hoc project board to track: Backlog, Current, In Testing/Review, Finished. We used sticky notes to write user stories and the wall of our workspace to place the sticky note in the correct column as it progressed. This helped the group understand our priorities for the two days we had and to know at any time the work in progress.

We used this common user story format:

As a ___\_, I want _____\_, so that _________.

Examples of our user stories:

• As a Wage Hour Investigator, I want a place to view the FOH online so that I can access it. (ensure a staging environment with working link)
• As an investigator, I want to search the FOH, so I can find answers to my questions. (make Elasticsearch work, provide good search results page)
• As an investigator, I want to browse the FOH by chapter, so I can discover information by topic and adjacency. (provide a good information architecture)
• As an investigator, I want inline links to other references so that I can make the best use of this body of knowledge. (we automatically converted certain text standards into their corresponding links for hundreds of pages of documents)
• As an investigator, I want the FOH to be easy to read because past methods have been hard to read. (provide good version 1 typography and design of this online resource)

Tom, the product owner had already used optical character recognition (OCR) software to convert 100s of PDFs into Word document documents. Microsoft styles and headings were applied to the content to begin to structure the data. (Aside: this is a perfect example of using the tools you know best to move a project forward!) With that in hand, our developer validated the technical feasibility of converting those Word documents to HTML pages that could be searched using Elasticsearch.

By the end of Tuesday we had:

• As a group understood the needs and challenges of the handbook as a larger project and scoped out what could be accomplished in a couple days
• Demonstrated user story writing and how to use a simple agile or Kanban board
• Within four hours, had a rough application that could search 100s of pages of documents as live HTML text. The division staff in the room thought that would take months!

Wednesday: Build and design. Get feedback. Repeat.

Build

Coming into the sprint, we understood that one of the major constraints is that the handbook is created and maintained using Microsoft Word. Minimizing the effect on workflow was therefore a key part of any proposed technical solution. Fortunately, there are several open-source, publicly available tools that allow for automated conversion from Word files (.docx) into web-friendly files (.html), including pandoc. So, first, we wrote a script that uses pandoc to automatically convert the Word files to HTML files.

Then, to get the HTML files to be more usable, we wrote a second script that extracts the content from the HTML file, does some high-level parsing, creates a Table of Contents, establishes JSON objects for each part of the Chapter (along with associated metadata), loads the JSON objects into an Elasticsearch service, and rewrites each HTML file to include links to other government sources and internal links. Finally, the files and search results were served using NGINX as the application server (later, this was rewritten to work with Apache).

“…we made so much progress in a short period of time! It’s searchable and you can actually read it.” —Amy, Senior Advisor, Immigration and Farm Labor Branch

Design

One of the great things about a cross-functional team in the same room for a sprint is you can use faster design tools. Instead of creating pixel perfect “mockups” of how navigation might work, or how a page might visually feel, we did quick pen sketches on paper, a rough color scheme in Illustrator and then went right into design and developer pairing. We discussed problems and opportunities on the spot and were empowered to move forward with our ideas.

Feedback

Actual investigators made this sprint a success. Working with them over the two days, we determined the best interface copy that would be clear and actionable to their peers. Seconds after code was pushed to the staging site, we observed how they used search and understood the search results pages. Feedback was immediately incorporated.

What’s next?

For many of us in the design and software development profession, building a working prototype is not a big deal. For the dedicated civil servants in the federal government, it can be. Over these two days we demonstrated that with the right support and the right people in the room, ideas can be tested, iterated upon, and realized without months of requirements gathering, large waterfall contractual agreements, and other impediments.

This prototype, built over a two-day sprint, is still an internal proof of concept for the people responsible for improving the FOH. For important legal reasons, they are dedicated to ensuring the confidential, internal-facing guidelines are developed in a secure, yet accessible way. Our prototype used the public-facing portion of their guidelines to reduce that risk. In the next few months, they will pilot this with a few regions while they work on securing a development environment that can house the more useful internal-facing documents (helping government do that better is another story for another day). Meanwhile, for all future discussions, they have a working prototype, created with internal stakeholders in the room who helped build it!

18F and GSA are committed to being proactive federal partners and providing operational excellence wherever we can. By working hand-in-hand with the WHD team, we’ve been able to show them what’s possible, and have given them the basic knowledge to ask the right questions to help them develop solutions in a cost-effective, user-centered way.

If your agency has a project you’d like us to look at, please contact 18F Consulting via email.

This post was originally published on the 18F blog by Jesse Taggert, an 18f team member.