Note: This is the second post in the series Managing custom software development when you’re not a software engineer.

There are lots of civil servants in the federal government who want to do things differently. But often in government, doing things differently is equated with risk, and risk is something to be minimized as much as possible. So, it can be hard to figure out how to get started and how to bring your fellow civil servants on the journey with you in your quest for better outcomes.

The problem is, there’s some serious confirmation bias at work here. Just because we’ve always done things one way, does not mean that doing them differently is more risky, but humans do have a tendency to see it that way. For all we know, the way we’re doing things now is high risk, but we just don’t acknowledge it.

If you’re looking to change the way your team designs and develops software projects take a look at the tips below.

The initial hook

There are a lot of teams out there saying they practice agile software development, when in reality they’ve just broken up their waterfall roadmap into two-week sprints (often called agilefall). This can lead to executives in government thinking “well, we tried agile and it didn’t help at all.” What they really tried is the exact same waterfall approach they’ve always been using with a slightly different vernacular surrounding it. This means really changing your team into an agile operation can be an uphill battle, because you have to overcome some of these initial biases (just listen to Tim Gribben, the CFO of the Small Business Administration, talk about how he’s not a fan of agile, but he acknowledges agile development was central to the success of the DATA Act implementation).

If you think you’re likely to face resistance from your leadership about trying an agile development approach, you can start out by asking your leadership questions like:

  • How confident are we that we’ve captured all of the requirements up front?
  • Do we anticipate any of the requirements may change after our initial planning phase? If so, how will we accommodate that with our team and/or contract?
  • Are there some areas with lots of variables and moving parts (like legacy technology systems) where we can’t accurately judge the risk up front?
  • Is it risky to pin all of our hopes and dependencies for this large project on one vendor?
  • Should we schedule regular demos of the software with the vendor (instead of taking their word for it in status meetings) so that if things aren’t on track, we’ll know sooner?

If they start to seem concerned, great! Your stakeholders might see the benefits of agile development even if they’re skeptical of the term agile. If so, try using different terminology, such as “pilot program” or “incremental development” (as encouraged by OMB and the GAO). The agile manifesto is only four basic ideas. It’s more important to bring those ideas into your project than to label your team as agile. Try reading through the slightly longer list of 12 principles behind the agile manifesto for more terminology that speaks to you and may appeal to your stakeholders. Don’t get too hung up on pitching the agile process and focus more on the ideas.

And finally, don’t try to pitch them on transitioning to agile for the entire length of the project. Try to break off a small piece of the overall project or an initial prototype and negotiate 6-8 weeks to experiment with agile development. It’s a much smaller commitment, but it gives you some time to make your case with results, instead of hypotheticals.

Include your stakeholders from the beginning

If you’re able to negotiate a window for experimentation, it’s critical that you include your stakeholders throughout that period. Invite them to your sprint reviews and demo what you and your team have done that sprint. Even if they aren’t enthusiastic about what they see, it gets them used to that feeling of being able to frequently evaluate tangible progress. And if they make suggestions or ask for features, make a show of capturing their request in the backlog to demonstrate the feedback loop between the customer and the product.

Find a champion or early adopter

If you can, find a user that your project serves and get their commitment to be on the sprinting team for your experimental period. Have them come to demos, give you feedback, and tell you what else they’d like to see. This will help you prioritize the most important features first. It also means you’ve created an ambassador to your stakeholder community that can help you advocate for agile development later.

Prototype with the software you have, not the software you want

Just because you’re building a quick, six-week prototype using agile development, it doesn’t mean you need a contractor or software developer on board yet. In fact, the lessons you learn from building something basic can be very valuable when you go to procurement by helping you think through questions you maybe haven’t thought through before. People build prototypes out of everything, from pieces of paper, to office productivity tools (G Suite, Office360, etc.), to content management systems (WordPress, OMB Max, Sharepoint, etc.) to more sophisticated data visualization tools (Tableau, Socrata, etc.).

These are just examples and not endorsements of course, but look around at what you have access to at your agency. Just because it doesn’t meet all or even most of your needs, doesn’t mean you can’t use it to build something basic. Prototypes are meant to be temporary. Their real value is helping you think through questions relating to your product with minimal investment.

Demonstrate your progress

The best thing you can do to convince your stakeholders is to show them the results. Even if they haven’t been regularly attending your sprint reviews, make sure to schedule something definite with them at the end of your experimental period. Show them the progress that you’ve made and make sure to demo what you’ve done instead of only explaining it in a slide deck. Also recap the challenges that you’ve uncovered and ways your requirements may need to change based on your new findings.

Transitioning to agile development doesn’t need to be a big, sweeping, organizational change. You can make it more approachable and less scary by introducing it in small chunks. If you want to continue with it, keep an eye out for the next post in this series on how to fit agile into existing bureaucratic structures (such as CPIC, audits, and program management). Or, check out the first post on why you should care about agile in the first place!