10 Steps to Making Your Agency Agile

Bill Haight is former chief information officer of Salt Lake City, and Robert L. Read is co-founder of 18F. This article is the second of a two-part series provided by Agile Government Leadership designed to help agencies understand and implement agile practices.

It seems that every IT organization in the world is talking about agile. Organizations need to be more agile, use agile project management, adopt agile methodologies -- but what does agile really mean? And why is it important to government?

As a CIO and department director for local government, I asked these questions some months ago as I searched for ways to provide better quality services for our business partners in other city departments and for the citizens we serve. Here’s what I have found.

Agile, particularly when talking about systems design and implementation, is a whole new way of looking at how governments will implement services and the technology behind them. It starts and ends with the needs of users -- the citizens we’re serving. It gets developers, managers and customers working together in the same room, focusing on iterative improvement rather than long requirements lists.

And because of this, agile projects deliver incredibly useful and relevant products and systems -- results that are markedly different from the typical government development effort.

But therein lies the rub. The terminology sounds a little bizarre to the government IT veteran. Phrases like “user stories,” “scrums,” “backlog,” “burndown lists” and “minimum viable product” can sound like a completely foreign language. How does a department even begin to understand and implement these concepts? The answer: practice. You can read about agile to start getting your head around it, but in the end, you and your teams simply need to dive in and try it out.

Having navigated my way through implementing agile in my department, I developed 10 basic steps a department leader can use to start bridging the gap between “How do I start?” and “We did it!” These tips are written specifically for someone leading a department within government, from the smallest cities and counties to large federal agencies.

1. Pick a simple project to begin with

Just as your first programming assignment was a “Hello World” project, your first agile project should be a project that’s not too large. Pick something that has a high probability of success, is easily defined and can be broken down into digestible pieces. You’ll need to be able to identify the minimum viable product or the barest essential functions needed for your business partners or customers to start using the system. Is it really necessary to have a 90-day aging report at go-live?

Maybe so or maybe not. Whatever project you choose needs to be broken down into clear categories -- the essentials for operation, and the features and functions that can be added as development or implementation progresses.

2. Pick your champions

This is even more critical than the project you’ve selected. Agile will be a new way of thinking and working for most government IT teams. You need two champions. They don’t have to be particularly experienced, but they must be enthusiastic about agile.

One champion is your product owner, who understands the driving need of the end-user and can explain it to the team. The product owner must be good at prioritizing based on user input. The other champion is your scrum master. The scrum master needs no special skill but must track and nucleate consensus for the entire project team to keep them on track, on target and focused. The scrum master need not be the development lead.

3. Pick your project team

 As with any project, success is dependent on the project team. An agile team functions differently on a day-to-day basis than a traditional project team. They, too, need to be capable and willing to approach the process differently. The right team will need representation from IT, the appropriate user community and your champions. They need to be flexible and receptive to agile as a way of doing business and invested in changing the norm for IT.

4. Give them the training and tools

Too often in IT, we decide on a specific direction and immediately jump into the tools and technology. In the case of your first agile project, the only tool you will need is a whiteboard with sticky notes. Perhaps surprisingly, most teams prefer sticky notes to software until they are geographically distributed.

A few days of training are needed for your champions and project team to understand agile methodologies and techniques. Everyone needs to have a shared terminology and somewhat shared expectations. You might even consider bringing in someone from the outside to work with the team to train that person as they go.

Some organizations have found a simple one-day workshop to be effective. The Social Security Administration, for example, in an effort to build better software to process disability claims for the American people, dove into agile in a single day and found the new approach very successful.

5. Create a minimum viable product

The goal of agile is to de-risk a product by getting it into the hands of the end-users quickly in order to learn from them, even knowing the product will be incomplete at first. The minimum viable product is the barest essential functionality needed to provide value to your end-users.

As the department head, it is probably not your job to understand the end-users well enough to know exactly what the MVP is. Rather, it is your job to enable and insist that the product owner get the customer in the same room with the whole team to identify and prioritize user stories. In the language of agile methods, this is the “creation of a prioritized backlog of user stories.”

As you start periodic sprints, the backlog and the product will morph as more user stories are created. Features and functionality will be added with each sprint -- or each cycle of development, implementation, demo and feedback. In the end, you’ll have a product that better fits the needs of the user because they’ve played a significant role in the growth of the product. They have what they need faster -- and with better results -- because they’ve been much more involved in the development/feedback cycle.

6. Go!

This is the hard part. Time to take that leap of faith and turn the team loose. They have the project, they have the training, and they know what they need to provide to be successful. Time to cut them loose and let them begin the first of many short sprints. Each sprint makes measurable progress validated by actual end-users.

You’re not off the hook entirely as you need to follow up with your champions. You have to make sure the sprint rhythm is being followed and that each sprint ends with a demo to actual end-users, or their representatives if necessary. Ideally, you should attend each demo. If you do not see measurable progress every sprint, you should talk to your champions about the problem.

You can compromise on any aspect of process, so long as you always strive to maintain the principles stated in the agile manifesto to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

7. Follow up

Think of this as if you’ve just birthed a new baby. Your project will need care and nurturing for a while and will inevitably stumble a time or two or three. But given time, attention and support, it will learn to crawl, walk, run and fly. Meet with your champions regularly. Be ready to buoy them up when things aren't going as smoothly as they'd like. Share in their excitement when they triumph, no matter how small the victory. Listen to what they’re telling you about the challenges they’re facing and be ready for step 8.

Above all, demand that they are following an agreed-upon agile process strictly. Having a sprint demo for actual end-users of actual working software, however simple, is perhaps the most important discipline that you must require.

8. Tweak your policies, processes and procedures

Almost assuredly, your department will have existing policies, processes, or procedures creating unnecessary obstacles for the team being as agile as possible. This is where you, as a department director, can most influence the success of the project. As a servant-leader, be ready to look at those obstacles with the same openness to change that you have asked of your team.

Adjustments may be needed around procurement rules, security procedures, or some other factor that no one thought of at the onset. Be ready to adapt and change the playing field to accommodate an agile environment. A creatively compromising attitude is valuable here.

9. Retrospective: Report on your accomplishment

This is even more important as you move down the agile path than it ever was in a traditional project management environment, for two reasons.

First, your department will likely have naysayers and doubters that need visibility into the agile process. Secondly, agile projects tend to be learning projects that discover solutions not originally envisioned when the problem was presented.

The game and the very goal may have changed. Your department’s normal way of doing business may be disrupted, probably in a positive way. Consider using a “Rose, Bud, Thorn” or “What worked well, what worked poorly and what we will change” exercise as part of a retrospective to identify lessons learned. Apply these lessons to every future agile project and your whole department.

10. Celebrate!

This is likely the most important thing of all. As you accumulate successes and the teams start to recognize the benefits of agile, acceptance of the new way of working will increase. Your entire department will buy into agile processes. If you can share this success, your teams will communicate better, hold to a higher level of accountability and deliver a superior product to your business partners. When your teams look good, so do you.

(Image via Karashaev/Shutterstock.com)