Yesterday Waldo Jaquith wrote an insightful post about what federal agencies need to do before hiring an agile vendor. It warns:

You don’t want to do all of the hard work of procuring a top-notch scrum team only to send them face-first into a brick wall of bureaucracy. You’ll lose all of the momentum, lose the best members of the team, waste $40,000/week, and when the project finally starts it will be with a demoralized team.

Why It Matters

Excited for adopting new toys and tools or writing a new piece of software organizations will hire a vendor that does modern software development, but throw barriers in front of them as they do their work. This can lead to employee/volunteer burnout, conflict, and wasted time and money on a doomed project.

The Pre-Work

Before we decide to partner with an organization at Code for Boston we spend lots of time helping them understand our process. During this get to know you period we have multiple meetings and there is no promise of a project engagement. The goal is to lay out our expectations and how we work, understand our partner and how they work, and gauge the willingness of both parties to be flexible.

“Meet People Where They Are” Cuts Both Ways

A common refrain in Civic Tech is “meet people where they are”. The sentiment is noble, but sometimes one-sided. I have been a part of multiple engagements where the client expects the agile vendor (or volunteer organization) to completely bend to their desires.

The situation becomes equivalent to a person hiring a personal trainer but spending their time with them eating donuts and talking about fitness equipment instead of working out. The personal trainer leaves with a heavier wallet but does not feel great about the impact they’re having.

Crawl Before You Walk

Some people and organizations think they want to make a software application, and they may be right that is a good solution for their problem. However they might not be ready to be a part of the process of writing custom software. There are things to learn before you do this:

• GDS has a great Digital Awareness Training module for policy makers that help them understand what is involved in creating software.
• 18F has published a State Software Budgeting Handbook that covers many of the basics.