5 Cultural Shifts Agile Brings to Agencies

Melinda Burgess is a staff writer at Agile Government Leadership. This article is the second of a two-part series provided by Agile Government Leadership designed to help agencies understand and implement agile practices. Read the first one here.

It’s not hard to find a myriad of articles and opinions on how agile processes can lead government IT into a brave new era of efficiency and transparency. What’s hard, especially for agencies new to the concept, is figuring out the nuts and bolts of implementing lean and agile methodologies into departments mired in superfluous systems and clunky contracts.

The two worlds seem almost irreconcilable. What happens to documentation when your team is busy writing user stories? How do contracts need to change in order to work with the iterative, evolving nature of agile projects? How does agile decrease risk if scope and budget are not clearly defined at the outset? And is agile really as great for agencies as the evangelists claim it to be?

Real-world questions like these drove the discussion for a recent roundtable webinar jointly hosted by Agile Government Leadership, a community network providing support and resources for those aiming to bring agile into government agencies, and GMIS International, the largest professional association of public sector IT leaders in the United States. A panel of public sector leaders with on-the-job agile experience shared their stories, insights and practical advice, concluding that agencies really can shift their approach toward agile if they’re willing to embrace some fundamental changes in government IT culture.

1. Agile is a team sport.

Bill Haight, former chief information officer of Salt Lake City, Utah, who led his department through the adoption of agile methods over the past year, says he spends a lot of time building teams who like each other and work well together. Instead of giving undue importance to requirements and tools alone, the focus shifts to the team itself -- making sure developers, managers and stakeholders are all working towards an end goal together.

This approach can help mitigate the risk that the original ideas need some tweaking (as they often do) in order to achieve maximum usefulness to the public.

“A good team can take a bad idea and fix it,” Haight explains, “and a bad team can take a good idea and screw it up.”

Robert Read, co-founder of the General Services Agency’s lean digital services agency 18F, has led multiple departments through agile workshops and witnessed first-hand the benefits of valuing good teams over “good contracts.” In response to a question about what type of contract (fixed price, time-and-materials, or cost reimbursable) works best for agile development support, Read points to another way in which a team-centric mindset can benefit agencies.

“More important than making specific procurement decisions is to have multiple teams,” Read says. “The real power to an agency occurs when they have multiple teams, so if they don’t like the rate or cooperation in one team, they can shift work to another team.”

He points out that when governments zero in on “fixed price” or some other defining factor to decrease risk, they are only ensuring that certain requirements (such as cost) will be adhered to, but not ​that the agency will end up with a superior and useful product that helps them deliver excellent services.

The value in having multiple vendor teams extends even further, especially for federal agencies deploying large-scale projects. “Business as usual” for governments is to hire one company for a long-term project, which they are then stuck with, possibly for years, because of the contract.

“If things go wrong,” Read says, “all you can do is shake your finger at people, which creates hostility instead of a great working environment.”

2. Relevance is the gold standard.

Too often, agencies set their sights so narrowly on the tools or technology they think they need, they fail to realize the end product doesn’t make life noticeably better for citizens -- leading to wasted resources and unhelpful systems that never get used.

Steve Collins, IT manager of Richland County, South Carolina, says he was struck by the statistic he heard in a presentation that 45 percent of the features built into projects nationwide never get used at all. Realizing that huge requirements documents and waterfall development were part of the culprit behind wasteful systems, Collins went straight to his management and got buy-in to turn Richland County’s IT department into an agile shop.

His aim was simple -- increase productivity by 45 percent by NOT building the irrelevant features. His teams, who constantly meet with product owners to give perfect visibility into the process, have been delivering successful and useful agile projects for the past seven years.

“I have seen agencies spend hundreds of millions of dollars on systems that were never turned on,” Read notes. “This is something the American taxpayers should not have to bear. Agile does not guarantee success, but it does guarantee relevance.”

When teams work from a prioritized backlog that clearly states the most important features that are needed -- and those priorities are being defined by the customers -- it’s very unlikely developers will spend 45 percent of their time building something useless. When agencies make relevance the gold standard, every sprint effectively makes life better for citizens.

3. Communication trumps documentation.

Gone are the days of writing exhaustive documents to define every aspect of a tech project before it’s started -- that approach has proven disastrous for software and digital services. Instead, communication with the customer becomes the driving force behind the project’s development.

Haight explains requirements should evolve naturally as the programmers meet weekly with the users. It’s during the stand-up meetings and product demos that effective changes are made, not by writing up a long requirements list at the outset.

Read agrees: “Magic happens when you get the developers in the room with the customer. Because [the users] can see and interact with [the project] on an iterative basis, communication goes through the roof and allows you to track happiness instead of requirements.”

Similarly, documenting work progression is less necessary when daily meetings keep all the players up-to-date on what everyone is doing. Burndown charts, user stories, and backlogs are the practical tools of agile that stand in place of extensive documentation, and can be referred to during retrospectives or audits if questions arise.

Tim Nolan, senior applications manager at Collin County, Texas, introduced his department to agile about five years ago and found that getting people to change the way they think about developer/client relations was one of the keys to agile success.

“There is a lot of documentation written that is never being read,” Nolan points out. “User stories serve much better . . . The challenge is really with the culture change.”

4. Deadlines don’t mean what you think.

If agile projects are iterative and evolving, with less focus on scope and schedule, how can teams manage deadlines in a balanced manner?

Agile champions say the deadline is important, but should not be made top priority at the expense of testing and training, which are the key ingredients for a successful project.

“That deadline is just a release,” Read explains. “It’s an event that happens, but your code should be as close to releasable as possible at all times. You’re always doing testing; your release is just publicizing it. It doesn’t guarantee that you’ll get everything done that everyone wants, but it does prevent the really terrible problem of just missing deadlines by years.”

Haight adds that since 84 percent of projects don’t meet “on-time, in-budget” criteria, perhaps the question agencies should be asking is, “Are we delivering the right features? Is this what the public needs?”

If teams produce increasingly better iterations of a product based on customer feedback, the deadline becomes a point in time when something of value is delivered, even if there is still room for improvement. A deadline for an agile team is a good servant but a bad master.

5. Government contracts need a makeover.

So how do all these cultural shifts affect procurement?

Contracts, almost by definition, are meant to contain requirements -- an assurance you will get what you pay for. Is there a way to adjust the wording of government contracts that will allow for the team spirit, iterative development and transparent communication that agile brings to projects? Yes, but it’s a big stretch for agencies that have been trained to reduce risk by writing into the contract every possible detail of cost, time and materials.

In this age of rapidly changing technology, it’s not realistic to define every requirement at the outset. Rather, agencies can move to an agile-oriented contract that insists on rapid response, work being done and delivered every two weeks, and constant communication based on a shared understanding developers and clients will decide together what is needed.

“It takes courage,” Read says, “because you have to make a shift away from the idea of contract negotiation and have faith and trust that if you have a conversation with people who are appropriately skilled, you’re going to be happy with what they produce in that particular time.”

Embracing these changes is often an uphill battle for government. Old habits die hard. But when one team starts experiencing the benefits, it’s not uncommon for agile to “catch on” in other departments. The cultural shift is contagious -- from the smallest city departments to the largest federal agencies, a growing number of people are making and sustaining positive changes in government using agile.

(Image via dencg/Shutterstock.com)