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. […]
“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.
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.
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.
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.
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.
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.
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...
Agile scaling is always a hot topic for students and organizations dealing with the complexities...
4 Reasons Why Agile Scaling Goes Wrong
Agile frameworks are predicated on the notion of forming small, cross-functional teams. A low number...