18F/18f.gsa.gov

---
title: "Getting stakeholder buy in for agile development"
date: 2017-12-14
authors:
- kaitlin
tags:
- agile
- guides
- culture change
- convincing stakeholders
excerpt: "Transitioning to agile development doesn’t need to be a big, sweeping,
organizational change. Here are some tips to make it more approachable and less scary by introducing it in
small chunks."
---

*Note: This is the second post in the series [Managing custom
software development when you’re not a software
engineer](https://18f.gsa.gov/2017/09/20/managing-custom-software-development-in-government-when-youre-not-a-software-engineer/)*.

There are lots of [civil servants in the federal government who want to
do things
differently](https://18f.gsa.gov/2017/12/12/renata-maziarz-model-civil-servant/).
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](https://18f.gsa.gov/2015/12/29/is-your-project-using-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](https://youtu.be/X26IGyZ-SUY?t=1m33s), but he acknowledges agile
development was central to the success of the [DATA Act
implementation](https://18f.gsa.gov/2016/06/14/prototype-early-prototype-often-lesson-from-the-data-act/)).

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](https://management.cio.gov/implementation/#Attachment-A) and the
[GAO](https://www.gao.gov/products/GAO-16-469)). The [agile
manifesto](http://agilemanifesto.org/) 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](http://agilemanifesto.org/principles.html) 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](https://18f.gsa.gov/2016/10/25/three-small-steps-you-can-take-to-reboot-agile-in-your-organization/).
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](https://18f.gsa.gov/2017/09/20/managing-custom-software-development-in-government-when-youre-not-a-software-engineer/)
on why you should care about agile in the first place!