A $90 Billion Annual Opportunity for the Scrum and Agile Community
The U.S. Government has a significant software development problem. And they know it.
A document released this week by the U.S. Government Accountability Office (GAO) states that the federal government spends more than 90 billion dollars on IT projects, yet “all too frequently, agency IT programs have incurred cost overruns and schedule slippages while contributing little to mission-related outcomes.”
The GAO, which, among other things, is responsible for assisting the U.S. Congress in assessing federal agencies’ management of their IT systems is trying to improve outcomes. And they’re embracing Agile to do just that.
The new document, officially called an Exposure Draft (which means it is open for public comment), is titled ‘AGILE ASSESSMENT GUIDE: Best Practices for Agile Adoption and Implementation’.
Denise Jarvie is a consultant now working with Scrum Inc. She was one of the Scrum and Agile experts that helped develop the GAO’s guide. In the past, she says, “contractors were being asked to move towards Agility, but government officials didn't fully understand what Agile is. ” This document, she adds, “was written, in part, to improve the understanding of Agile from the federal government’s point of view so that they can encourage real best practices and understand agility. To provide support from the very beginning.”
The guide lists federal auditors as its primary (but not only) audience. This may help break the government’s reliance on a pure waterfall or a waterfall-Agile hybrid system that can be a nightmare for contracting partners.
Take, for example, the traditional belief that project requirements must be fully defined upfront. Something Denise is asked about “every time I go into a government contractor site.” In the past, she explains, the government requires the use of “an artifact called a Requirements Traceability Matrix. I think that this guide loosens that and gives Scrum Teams or other Agile teams more leeway on talking to the customer about the requirements, and redefining and reassessing requirements to reduce risk and have a better product for the customer. Agile development requirements can be traced through Agile artifacts, such as the Product Backlog.”
The Good in The GAO's Guide
Scrum Inc. Principal Consultant Avi Schneier was more than pleased to see the guide includes a large number of case studies detailing the positive outcomes Scrum and Agile have already created when used in government projects.
But where this guide shines, Avi says, is how it explains “what Agile is and what Agile is not.”
Specifically, he points to Appendix VI: Debunking Agile Myths, which addresses ten specific myths ranging from Using any Agile framework will automatically result in program success, to Agile only works for small programs with a single team or only in co-located environments.
Debunking such myths is important, Avi says, because “there are so many bad Agile implementations out there that these myths become what people think.“
On the tactical level, both Avi and Denise agree with the guide’s description of concepts like self-organized and cross-functional teams may indeed increase the ability of Scrum and Agile to take hold in these projects.
“Not only does it focus on cross-functional teams,” Denise explains, “but cross-functional teams that collaborate with technical people on the government side in a much more embedded and collaborative way.” She adds, “That’s one of the biggest problems I see when I go into contractor facilities. Scrum relies on more input and feedback from the customer and many contractor teams don’t currently have that.”
Changes That Need to Be Made
The GAO is currently accepting public comments on this Exposure Draft. While both Denise and Avi see it as a step in the right direction, some changes do need to be made for this guide to achieve its goal.
Perhaps the most important, the two agree, is the need to include a description of Scrum@Scale in the document. As Denise notes, many of the big 5 defense contractors are already successfully implementing Scrum@Scale.
Scrum Inc. will be asking for this description to be included in the final guide:
Scrum@Scale naturally extends the Scrum framework across an organization allowing multiple groups of teams to coordinate in ways that help them deliver value faster. It provides a scaffolding in the form of 12 components within 2 cycles. Taken all together, they enable the engineering of customer-focused solutions and efficiency-focused processes and systems to grow organically out of the unique conditions of your organization. With Scrum@Scale you will find a way to customize your implementation to bring Agility to areas beyond IT, like management, manufacturing, procurement, marketing, human resources, and sales.
We ask the Scrum community to join us in this effort.
There are other improvements that Denise believes can and should be made. “This guide is highly focused on IT and software,” she explains, “I think that it could be expanded to include hardware or software embedded on hardware, and other complex systems.”
Public comment on the GAO’s ‘AGILE ASSESSMENT GUIDE: Best Practices for Agile Adoption and Implementation’ can be made here: https://tell.gao.gov/agileguide.