Toggle Menu

Insights > Agile Training > Using Agile in the Government to Make Better Software

Using Agile in the Government to Make Better Software

It’s Time the Government Embraces Agile “All human plans [are] subject to ruthless revision by Nature, or Fate, or whatever one preferred to call the powers behind the Universe.” ― Arthur C. Clarke, 2010: Odyssey Two Maximizing the benefits of Agile can be challenging for agencies who must acquire software development products and services through third-party contractors. […]

By

January 02, 2020

It’s Time the Government Embraces Agile

“All human plans [are] subject to ruthless revision by Nature, or Fate, or whatever one preferred to call the powers behind the Universe.”
― Arthur C. Clarke, 2010: Odyssey Two

Maximizing the benefits of Agile can be challenging for agencies who must acquire software development products and services through third-party contractors. This common practice in government sets up unique and interesting challenges for both the vendor and the agency when they want to use Agile practices and deliver greater value with less cost.

To succeed with Agile, the same principles and practices used in the private sector are also vital to success in procurement business relationship.

Here are 5 practical ways to work with contractors within an Agile framework to achieve fantastic results in the government:

  1. Insist on short feedback loops

The most effective way guarantee short feedback cycles is to split the work into smaller pieces. Rather than adding everything you want in the solution to a single contract, divide up the capabilities into smaller slices of value.

For example, suppose you wanted a new website and a mobile app that contained information on each of the many departments and units within your organization for the public to access. Instead of cramming all the requirements into one contract that could take a significant amount of time to complete, break the work into chunks. The first chunk could just be for a functioning website with a home page and a link to a single department’s information. This provides focus on a finite set of requirements and provides the opportunity to modify the future contracts based on discoveries in the previous completed piece.

  1. Start with high-level requirements

Don’t lock yourself into a detailed set of requirements (i.e., user-story level) at the beginning. The requirements document you initially create to obtain funding, and perhaps use as part of the vendor contract, should be high-level, brief descriptions of the features you want. We don’t want to commit either side to minutia that we really can’t properly define until some coding is completed. Time spent developing those detailed requirements will likely be wasted time as change is inevitable. With every new creation, there will be unknowns, and we want to allow for discovery and change for the better.

  1. Set price based on a fixed timeline, allow for reasonable flexibility in scope along the way

Contracts are still necessary to protect both the agency and the vendor. When settling on a price for a relatively short-term project, think in number of sprints. Get a reasonable estimate on how many sprints the features will take to build, and base price on that time frame. Knowing that estimates are at best educated guesses, there must be flexibility in the scope. A good Product Owner will prioritize the user stories, ensuring that the vital ones are completed first, and the nice-to-haves are scheduled last. This gives the needed flexibility in an unpredictable world. The contractor will know the average run rate of their team(s), making this a simpler way to arrive at a fair price.

  1. Government agency and vendor alignment

Communication, cooperation, and collaboration between agency contacts and contractors is vital to success. Even though you work for different entities, you should function as a team working towards a common goal.

Develop a clear, concise, and motivating vision of the overarching purpose of your endeavor and share it often with the contractors to ensure you are all rowing in the right direction.

  1. Don’t make assumptions about the vendor

Don’t assume the vendor is “good at agile.” Don’t assume the vendor understands or interprets your requirements the way you want them to. Don’t assume that the vendor is where they say they are in completing the requested backlog items

Instead, trust and verify. Built-in feedback loops give you daily, and sprint by sprint visibility into what is really being built and the quality. Insist on a live sprint review at the end of each sprint where the contractor will demonstrate the increment of value they created in the previous sprint. This will be the true measure of progress. This will also give you on opportunity to see the work and make changes to the plan in upcoming sprints if necessary.

Heeding these five principles will help you get what you want. They will enable you to pivot quickly if needed, help you avoid long overruns that don’t provide value, and hopefully enable you to build new relationships and enjoy the journey of building something for the greater good.

In this class, you will learn about the Scaled Agile Framework (SAFe) and how to effectively align teams of teams to a common vision and solution successfully. This two-day training teaches the principles and practices of SAFe, in which the curriculum is curated to match the challenges and environment of a Government agency looking to transform and/or improve their agile implementation.

See our full list of upcoming courses.

You Might Also Like

Agile Training

If Agile is Dead, Who Killed It? Suspect #2: SAFe

There’s been a trend lately of IT thought-leader types claiming that the Agile movement is...

Coaching

Why is Agile Scaling So Hard?

Agile scaling is always a hot topic for students and organizations dealing with the complexities...

Agile Transformation

4 Reasons Why Agile Scaling Goes Wrong

Agile frameworks are predicated on the notion of forming small, cross-functional teams. A low number...