Expert Tips on Using Agile in Government Projects

Agile is a work process that teams use to efficiently develop software and manage a range of other projects. While private industry has used Agile for more than two decades, government agencies are now increasingly using the process.

Agile focuses on an incremental, iterative approach to developing software or working on a project. Compared to traditional project management, it involves far more ongoing collaboration with end users. 

Agile developed in large part from the discussions of a group of software developers during the late 1990s and early 2000s. Frustrated with the inefficiencies and failures in software development, these professionals met and created what they called the “Agile Manifesto,” a set of written principles and goals outlining how to best develop software. 

You can learn more about the Agile Manifesto in the “Comprehensive Guide to the Agile Manifesto.” To learn more about Agile project management in general, visit “Everything You Need to Know About Agile Project Management.” And, to get more information about government project management in general, check out the article “Expert Tips on Performing Effective Project Management in Government”.

As mentioned above, people often use Agile for software development. But, the process can facilitate many other kinds of projects, as well.

“It’s a misconception that you can only use Agile for software,” says Yad Senapathy, Founder and CEO of the Dallas-based Project Management Training Institute. “Agile serves many other industries and projects.”

Implementing Agile within government can be challenging. Government agencies are resistant to change; Agile is radically different than more traditional project management methods. It takes work to help people understand how Agile can benefit their agencies.

Here are the major challenges of implementing Agile in government:

• Rules and Regulations: Government agencies have to follow many more rules and regulations than private industry does. Such policies can have a significant effect not only on how public agencies operate, but also on their ability to change processes.
   
  
  
  
  “Private industry has much more freedom to change; it’s not as constrained,” says Chris “Deuce” Alexander, Director of Agile Delivery for the Expansia Group, a New Hampshire-based consulting firm that specializes in Agile and works as a contractor for the U.S. Defense Department. “At the end of the day, [government workers] are beholden to laws and regulations. They do not have the ability to accommodate change that the private sector does.”
  
  Senapathy of the Project Management Training Institute adds, “Once you set a goal, Agile is supposed to empower your teams.” But, with the maze of [government] rules and regulations… to navigate, teams may find themselves limited in their ability to perform.”
• A Resistant Work Culture: Work cultures in government agencies are often resistant to change. While that resistance is partially a function of public sector rules and regulations, it is also a function of habit. When employees have been following certain procedures for a long time, they can’t imagine changing them.
   
  
  
  
  In the public sector, “there’s often a sense that, ‘We’re different; we’re the government,’” says Nicole Mayerhauser, Chief Operating Officer at Emerald One, a strategic planning and consulting firm.
• Slow Decision Making: When there is such a resistance to change, agency leaders are often slow to make decisions, even when they are actually considering change.
  
  “In government, people take a long time to make decisions,” says Senapathy. “Such glacial pacing hampers” the very swiftness that defines Agile.
• Agency Leaders Who Are Not Agile Supporters: Agency leaders are often unfamiliar with or unsupportive of Agile. In the case of the latter, those leaders are frequently skeptical because they are unwilling to give up control of a project in the way that Agile requires.
  
  “You cannot drive change in an organization from the middle of that organization,” says Senapathy. “Change travels from the top to the bottom.” Agile hasn’t expanded into government as much as it otherwise might have because government agencies tend to train middle managers and below — rather than top management — in Agile.
• Government Leaders and Staff Who Don’t Understand the Time Commitment: The leader of an Agile team on a project is called the product owner. Too often, in government, employees believe that they can be the product owner of a team while also continuing to perform many other agency duties that have nothing to do with the project. But, being the product owner of an Agile team is not a part-time job, experts say.
  
  It’s difficult for team members to do their work if they can’t get quick attention from the product owner, says McConnell of NextUp Solutions. Government leaders often, in his words, “don’t really understand the skills and time necessary to do product ownership well.”
  
  “The Agile portion of their job is something they do on the side while they have a bunch of other responsibilities.” He says that both the product owner and Scrum master roles on Agile teams “should never be part time.”
  
  A Scrum master is the coach for an Agile team, ranking directly below the team leader. The Scrum master organizes meetings and resolves ongoing daily issues.
• A Government Staffing Structure That Discourages Self-Forming Teams: Agile encourages workers from an organization’s different departments to come together to work on a problem.
  
  “Agile, in its purest form, is based on the idea of self-forming teams,” says Mayerhauser. “It’s people coming together to solve problem X. They are self-selecting their team and then staying together over time and getting better.” But, it is much more difficult for government employees to work across departments, experts say, because of both government rules and overall culture.
• Shorter-Term Employees Who Are Less Committed to Working On Change:
  
  Expansia Group’s Alexander has worked on Agile projects for the Air Force as well as for other U.S. Department of Defense groups.
  
  He says that in many government agencies — especially the military — employees know that they will serve in a particular job position for only a limited period of time (two, three, or four years). Given the transitory nature of their work, these employees resist leading the changes that Agile requires. Alexander sums up the frequent attitude of such employees this way: “‘I’m not here to change the world. I’m just here for a few years. I’m not going to assume personal risks. I’m not going to lead change.’”
• Government: The Sector with Less Agile Experience: Because of the aforementioned hurdles to using Agile in government, government employees often have little or no experience in Agile.
  
  Alexander says that government employees assigned to be product owners “have often never been product owners.” That circumstance would be rare in private industry, he says.
• The Hurdles to Understanding the Agile Language: Agile has a language and terminology all its own, and it can be difficult to understand. In turn, that difficulty can discourage employees from embracing the ideas behind Agile.
  
  To learn more about Agile terminology, visit “The Ultimate Agile Dictionary.”

This chart gives more information about how to overcome the biggest challenges of using Agile in government.

Experts recommend some basic steps to implement and scale Agile in larger government organizations, including setting expectations, providing long-term goals, and building on smaller, early successes.

Here are six steps to scale Agile in government organizations:

1. Set Realistic Expectations: Agile can improve the quality of projects, but it isn’t a magic wand. Managing Agile in government organizations can be a challenge. And, it’s more difficult with large projects in large organizations than it is with small projects in small organizations. You must set expectations at the outset about how your teams will work in Agile and what you hope to accomplish.
2. Consider Long-Term Roadmaps to Set Your Vision: If you’re embarking on a small, short-term project, you might not need to establish broad long-term goals. However, for many organizations, even small projects are part of a larger goal that involves many more projects. So, in many cases, it’s helpful to set and understand the long-term goals for an organization.
   
   This might mean creating multi-year maps that help employees navigate the road ahead. Such a map shouldn’t be so specific that it hampers the Agile process. — it should chart a course to help you establish an organizational vision.
3. Ensure That Employees Understand What Agile Is and Isn’t: Most government employees have worked in traditional project management, and have had little experience with Agile. They need to understand that it’s a method for advancing the work in the best way, not just a method for finishing tasks.
   
   “Don’t think of Agile as a checklist,” says Alexander. “Employees may think, ‘What do we need to do to prove that we’re Agile? If we can just do one, two, three, then we’re good, right?’ It’s not a checklist, and it’s not a set of tools. You’re doing Agile by being Agile.”
4. Start with Small Projects, and Deliver Value in Increments: Agile can most easily show its value with small and quick victories. Don’t get overwhelmed by trying to understand all aspects of every Agile methodology — just figure out a project that needs to get done and get a small chunk of it done.
   
   “To prove success early on, start with some pilot projects. Then, use that success as momentum to get others interested in wanting to employ the same method,” says Mayerhauser.
   
   She suggests that leaders figure out the most critical goals for an end user, “prioritize those, and then, within a very short period of time, answer the following question: ‘What are we going to prove in order to show we can get value?’” Teams that are successful, she says, “just start carving out very small pieces to show value quickly. As they show that, they are leveraging that success to build momentum — which also builds revenue.”
   
   “Don’t focus on framework or tools,” says Alexander. “Just focus on these questions: ‘What is the most valuable thing we can deliver?’ and, ‘How can we deliver that incrementally, iteratively, and as quickly as possible?’”
5. Consider Using an Overall Contractor for Large Projects: Your organization may start with some small projects to show success. Then, it may tackle other small and medium-sized projects that are part of broad organizational goals. Sometimes, you may consider hiring an Agile general contractor to oversee all of that work. Doing all of this can help ensure that you coordinate the work and move it forward most effectively.
   
   When using outside help, make sure that your organization’s leaders stay involved and work closely with your contractor, as they must understand and drive the work.
6. Consider an Agile Management Office: Many organizations have a program management office (PMO) or project management office to oversee their programs and projects. Often, those offices oversee projects that people work on through more traditional methods, like Waterfall, but they can and do oversee Agile work, as well. Some organizations are even creating what experts call an “Agile management office” to specifically oversee extensive Agile work.
   
   The goal of an Agile management office (AMO) is similar to that of a PMO: to ensure that teams complete high-quality, cost-efficient projects. Employees within an AMO understand Agile thoroughly, as well as how to manage the work and measure successes in accordance with Agile.

18F, an office within the federal General Services Administration, works with federal agencies to help them improve how they develop and buy technology. Click here to learn more about 18F and how it partners with government agencies to improve the end user’s experience. The office also offers a de-risking guide to implementing technology projects.

Experts offer a range of tips for managing Agile in government: Educate your staff to overcome resistance to change; communicate well with your employees and end users; and complete small chunks of work to show value.

Here are more detailed tips for managing Agile in a government organization:

• Start with Agile Guidance and an Agile Adoption Strategy: Make sure you follow guidance recommendations from other government Agile experts. And, determine your strategy for adopting Agile and moving it forward.
• Give Workers Training, Coaching, and Mentoring: Of course, you’ll want to provide comprehensive training and coaching to your employees. Leaders should begin this process by teaching their employees Agile terms and concepts.
  
  For example, you should help your teams to understand “user stories” rather than “requirements.” And, you should teach them how to write user stories. In addition, continue to coach and mentor them as they work on Agile projects.
  
  To learn more about Agile software development, visit “Understanding the Agile Software Development Lifecycle and Process Workflow.”
• Help Your Staff and Organization Overcome Resistance to Change: Organizations can overcome cultural resistance to change using education, training, and small steps toward Agile victories. “An organization should encourage its employees to embrace change, rather than fear it. In fact, leaders should create an environment where change is welcome,” says Senapathy. “Change is not something to dread. It can disrupt in a positive way.”
• Encourage Employees to Experiment in Agile: Your organization should encourage employees to experiment as they begin to do Agile work. That experimentation might lead to some failures, but even those misfires still provide value.
  
  Shifting your culture from strict governance to overall support will allow your employees to think in unconventional ways and collaborate. Over time, such a strategy can lead to better work and outcomes.
• Communicate Well: Continual communication is vital for success in Agile. Communicating well means maintaining consistent and clear contact with both your Agile teams and your end users.
  
  “Make sure you’re creating and cultivating an environment of transparency and trust,” says Mayerhauser. Maintaining transparency, trust, and communication — including with end users — allows you to say, “‘Here’s what we’re doing and why.’”
  
  Doing these things allows you to “lay out from the beginning why you want to move to Agile and what the benefits are,” Mayerhauser says.
• Always Get Feedback from End Users and Stakeholders: Your Agile process must involve customers, end users, and stakeholders from the beginning. Then, you must create frequent opportunities for these groups to assess your progress on your project. That means having them test software you’re developing or assess other changes in a process or product.
  
  Agile teams may include representatives of your end users. Make sure that, throughout your process, these representatives include a wide range of those end users, says Mayerhauser.
  
  While your team is working on a productivity tool, “the preparation of the technology itself might be progressing perfectly. In the meantime, though, the 600 people who are using the tool may not have received sufficient early-stage preparation for what to expect from the new product,” she says. “So often, Agile project management still misses that opportunity.”
• Always Work to Improve Your Agile Adoption: Your organization must continually work to improve its adoption of Agile principles — and you must track that improvement. Moreover, this effort should apply to both specific projects and the entire organization.
• Overcome Barriers in a Project and in Your Organization at Large: Your organization needs to be honest about identifying barriers that can get in the way of strong Agile management. Then, you need to make the changes that allow your organization to get past those barriers. Once you do so, then your organization can perform quality Agile work.
• Empower Small Teams: Build and empower teams that aren’t too large, and that include people from different functions within your organization. Teams of roughly seven to 18 people can decide what to produce and how to deliver it. 
• Coordinate Dependencies Across Teams: Sometimes, one Agile team needs to finish a part of its work before another team can advance its work. Situations like these require overall coordination so that work isn’t delayed and that teams are functioning well. For example, leaders need to consider these issues when determining the order of sprints, which are the fixed period of time — usually one to four weeks — during which you complete work on a specific portion of the project. Leaders also must ensure that all teams are communicating well to deal with such issues.
• Produce a Minimum Viable Product: In Agile, a minimum viable product (MVP) refers to a new version of software or product that has just enough new features to allow you to analyze how end-users react to the product (you can see what they like and don’t like). The “minimum” means that you don’t want to move too far into the development of the product before you let end users try it out (which could mean you’re wasting time). The “viable” means that the changes in the product can’t be so small that end users are unable to judge whether the changes are worthwhile.
• Gain Trust by Demonstrating Value: This step relates a bit to MVP. Since Agile allows you to make incremental progress in improving a product or service, end-users will gain trust in the Agile process if you can demonstrate value with each change you make, even if the change is small. Doing so shows that you’re listening to end-users when they recommend a change, and gives them confidence that the entire process will create a better product.
• Track Progress with Real Metrics: With help from end users, decide on metrics that will provide objective measurements of progress on a project. Agile burn-up charts can serve as one simple metric to track how much work has been completed. You’ll want to decide on other metrics of progress to track, and then track that progress daily and in a way that grants all team members visibility.
  
  “In the private sector, outcomes can be easier to measure,” says McConnell. “In the public sector, we aren’t selling a product, so what does value actually mean? Keeping a focus on our metrics…helps us to know whether we are getting value out of our time.”
  
  As your team decides on those metrics, it’s important that it includes real progress, not just activity.
  
  “With the bureaucracy of government, government agencies often are trying to measure themselves with activity versus outcomes,” says Mayerhauser.
• Provide Robust Governance: Large Agile projects often involve multiple teams working on different issues. It is vital that an organization sets up a strong structure and good leadership to govern and coordinate that work — doing so will allow teams to produce good work and advance projects without wasting time or money.
• Don’t Forget about How the Overall Product Should Work: Agile work happens in sprints that may advance a small part of a product. And, many teams may be working on different parts of an overall product at the same time. It’s important that all teams continue to think about how the product — a piece of software, for instance — will function when those different components come together. This may mean that your organization sets up specific testing during the process to ensure that the pieces work well together and to quickly detect any issues.
• Include Security Requirements: Include any security requirements for software in your list of work to be done, called the backlog. People sometimes forget to include those requirements as part of their backlog, which can mean your team forgets to consider their time and costs as part of the work.
• Think Modular with Contracts: Government agencies are more accustomed to contracts for traditional project management, which require a specific product or process to be completed by a specific date and pay based on that. Agile work is very different: The product and process may constantly change as the teams continue their work. This means contracts must be written differently. One option is to break a project into smaller chunks and write contracts based only on those separate chunks. Find out more about contracts for Agile work in the discussion below concerning how Agile changes procurement.

Here’s a useful checklist on using Agile in government organizations.  

The U.S. Digital Service also offers a Digital Service Playbook that provides recommendations and details on successful Agile practices in private industry and government. In addition, the Federal Acquisition Institute has hosted a webinar that features federal government agency leaders who have successfully used Agile in their agencies.

Agile can benefit government agencies in many ways. First, it allows employees to move projects forward more efficiently and create and develop products that are more useful. Additionally, they can perform the work in a more time and cost-efficient way.

Here are some of the benefits of using Agile in government organizations:

• Reduce Overall Risk: The Agile process requires teams to make progress on a product quickly and then test that progress. In this way, teams can identify problems and failures early in the process. Troubleshooting early on reduces the chance of unnecessary long-term work.
  
  McConnell highlights the differences between traditional and Agile methods in this way: “Even though you’re supposed to do the risky stuff first when using traditional project methods, you usually begin with all the easy stuff. By contrast, Agile approaches are so open and transparent that we can’t hide… So, we do start with the risky stuff.” That way, teams can make quick adjustments if something doesn’t work.
• Provide Value to Customers More Quickly: Done correctly, Agile encourages short-term sprints that develop and complete a small component of a product. Doing these sprints allows you not only to identify problems sooner, but also to deliver real value to the end user more quickly.
  
  “If you’re really following good Agile practice and building quality up front by rapidly iterating and delivering… you’re going to get faster feedback,” says Alexander. “In addition, you’re going to be able to track and accomplish the most important things and deliver the most value.”
  
  Compare that Agile scenario with traditional methods, in which there are a long list of requirements, says Alexander. He adds, “Then, there you are [there] three years later saying, ‘Here you go.’ You’re delivering something that operators are seeing for the first time, and they’re not super happy with it.”
  
  “The absolute biggest benefit of using Agile in government is being able to deliver technology faster and in a way that meets your business partners’ needs,” says Mayerhauser. With traditional methods, she says, it can “take years to develop a plan that, once delivered [as product], may very well be obsolete.”
• Provide a Better Understanding of What Customers Actually Need and Want through the Iterative Process: McConnell says that 80 percent of the uses of new software might come from 20 percent of the software’s features. “But, we don’t know which 20 percent of the features deliver that 80 percent of uses until we build the thing and ask our actual users, ‘Are we done yet?’ Once we find out we’re done, then we can stop, as opposed to continuing to spend more and more.”
• Offer Greater Transparency Concerning Project Progress: With many traditional Waterfall projects, “we’re going to sign a contract and be in a cave for a year,” with little or no sense of real progress, says McConnell. The client may require status updates and reports, “but it all boils down to, ‘Take my word for it — everything is fine.’
  
  “In the Agile approach, that cave basically goes away. Every two weeks, we’re delivering. And, because we can use progress as an indicator, we don’t need to spend time and money on status updates… they don’t actually deliver value,” McConnell emphasizes.
  
  Mayerhauser adds that when end users are more involved in a project, as Agile encourages, “they’re getting to see what is really involved in building software or delivering a product. It’s no longer a black box. And, they recognize that they have accountability.” That accountability exists to provide feedback and improve the product, she says.
• Gain Trust from End Users and Business Partners: Sprints that deliver progress on a product in a short period of time help teams build trust with customers and the end users of the product.
  
  “With Agile, through proven delivery of product, you build that trust over and over again,” says Mayerhauser. “It’s a perpetual wheel, like a virtuous cycle.”
• Improve Team Morale: Working in an Agile methodology empowers employees and teams. “Because of this empowerment, teams are likely to have greater morale,” says Senapathy. “They’re likely to be much more motivated. And, this increased motivation translates into a higher-quality product.” 
• Offer Greater Visibility into Contractor Performance: While working on an Agile project, you can show incremental progress at the end of each Agile sprint. Because you’re able to check the success or failure of work in such a short period of time, it is much easier for you to assess vendor performance. 
• Reduce Costs: Agile work can add value more quickly and can save a team from working for months, only to determine a product doesn’t work as originally intended. Such improvements in efficiency can reduce project costs considerably.

For a traditional project, a government agency must create a vendor contract that includes detailed specifications and fixed prices. For an Agile project, this type of contract doesn’t work. Instead, agency leaders must structure a contract that allows for the collaboration and evolution that Agile demands.

Here are some examples of how a government contract for an Agile project must differ from a government contract for a traditional project:

• Have Fewer Specifications and More Collaboration: A traditional contract is heavy with detailed specifications of what you must accomplish by the end of a project. By contrast, when beginning work on an Agile project, the team doesn’t have an exact concept of the end result; that concept evolves as the team works on the project. That flexibility is one of the benefits of Agile.
  
  “The whole premise of the Agile method is that we don’t know what the end solution will be,” says McConnell.
  
  A government agency should create a contract that facilitates the Agile process. With that goal in mind, the contract should emphasize the significance of collaboration, and should focus closely on how the product performs at each stage.
• You Aren’t Buying a Product; You Are Becoming a Partner: A contract for Agile work does not define the exact work to be completed. Instead, the contract communicates the expectations for the relationship between the agency and the vendor. The agency is entering a partnership under which, together, the partners will design and complete the product. In such an agreement, the wording of the contract doesn’t determine the success of the project; how the agency manages the contract — and the relationship — does.
• The Vendor Is Not in Charge; the Government Agency Is: A contract for a traditional project defines the requirements of the vendor; then, the vendor team works on the project almost entirely on its own. On an Agile project, a government agency’s leaders must be highly involved from the outset. That means these leaders must have a clear vision of what they want in a product at every juncture of a project’s evolution.
• There Are No Lump-Sum and Fixed-Price Contracts; Use Incremental and Other Pricing: If your agency is working on an Agile project, you won’t be able to set a fixed price or lump sum for the work at the beginning of the project. Instead, you’ll need a contract that structures payment in other ways. You may want to use incremental pricing (sometimes called modular contracting), which involves charging a fee for each increment of work that you complete successfully. Or, you may want to structure your payments based on the time you work on a project. (This pricing method can work as long as your client agrees with you on how you’re spending that time.)
  
  A government agency might consider using a contract that includes “story points or some other metric that is still quantitative, but starts to move the team in a different direction,” says Mayerhauser. Or, she says, an agency might create a contract that focuses on the use of defined Agile Scrum teams for a defined period. For instance, you might write a contract that articulates, “‘We’re going to get paid for whatever we can do in one year’s time,’” she says.

The U.S. Digital Service created the TechFAR Hub to improve government contracting in technology services. The agency offers a TechFAR Handbook that includes helpful guidance.

From simple task management and project planning to complex resource and portfolio management, Smartsheet helps you improve collaboration and increase work velocity -- empowering you to get more done. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.