COURSES CURRENTLY AVAILABLE LIVE ONLINE FOR ONLY $995

Toggle Menu

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

Using Agile in the Government to Make Better Software… and Make Software Better

“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 […]

By

January 02, 2020

“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:

  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. 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.

If you work for or with a government agency, you may benefit from participating in Excella Training’s upcoming SAFe for Government course in Washington, DC, from February 19 – 20th.

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.

You Might Also Like

Agile Training

The Surprising Advantages of Training Remotely… Who Knew?

The COVID-19 crisis has challenged all of us in many unexpected ways. For our team...

Agile Training

There Are Trainers, And Then There Are CSTs

As Agile frameworks like Scrum have exploded into the mainstream of technology work, so has...

Agile Training

Optimize the Whole: Lessons From a Past Tester

Sub-optimization happens when we apply an improvement measure or process to one component of a...