Our focus is helping the US Government use agile values and principles effectively. So we are often asked, “Is implementing agile for the US Government any different from doing it somewhere else?”
Yes, it is. (We realize we are breaking a cardinal consulting rule by not using the agreed upon response of “it depends,” but we’ve explored that option and it turns out it helps no one.)
While not definitive, here are the items we and our government clients have jointly discovered (see what we did there?) that are distinct enough to call for special handling.
Please recognize that when we refer to "government" below, we refer to both government employees and we contractors who support them. The government counts on contractors for help, and both groups are responsible for addressing these issues.
Government Agile Mega-Issues
1. Agile-friendly procurement process and language
2. Customer involvement, focus, and exploration
3. Thinking small and modular
Government Agile Special Considerations
4. Mixed government / contractor teams
5. Fake Scrum
6. Governance and IT life cycle policies
7. Compliance (e.g., Security, Section 508) and oversight (GAO, Congress, OMB, OIG)
8. Building and empowering the government workforce
9. Budgeting, color of money, and cost estimates
10. Long-term planning
11. Results-driven Business Modernization Office (BMO)
A detailed treatment of each item is likely to take a series of articles (and maybe a book). We will explore these in a series of upcoming blog articles. In the meantime, here are a few to get us started.
1. Agile-friendly procurement process and language
Many times the government takes the pixie dust approach to agile procurements. Liberally sprinkling the word “agile” in acquisition documents is meaningless when much of the text focuses on delivering things real agile practitioners would find cringeworthy. Weekly status reports, quality assurance plans, detailed requirements documents, and resource-loaded project schedules are all well-intentioned detractors from a focus on building a working product.
We need to help people understand agile isn’t just a new set of terminology. Using the values and principles means we do things differently. In reading procurements using the word ‘agile’, it is painfully clear we need to do a better job educating those that write these materials.
Fortunately, times are starting to change. 18F, the US Digital Services (USDS), the US Department of Homeland Security (DHS) Procurement Innovation Lab (PIL) and others are starting to “bend the procurement wheel” into something more effective. We’ll dive into how they are helping in a future article.
2. Customer involvement, focus, and exploration
Who is your customer? Do they want what you are building?
Pretty basic questions, right? I sat down with a senior officer in the US Navy yesterday who routinely asks these questions of his staff and colleagues. He is often dismayed that they don’t know the answers. Unfortunately, his situation is not an isolated case.
Because much of the world uses Scrum as an agile framework, we might say that we need better training for product owners. And that’s true. Scrum empowers product owners to serve as critical champions for customers. But a customer focus isn’t only the responsibility of the product owner. It is a requirement for everyone involved in the product life cycle.
The role of product owners, product managers, and I dare say ‘customers’ in the government is still in its infancy. In the private sector, if you don’t listen to your customer you go out of business. Not so in the government. We who support the government need to give these roles and concepts significantly more love.
3. Thinking small and modular in Scrum@Scale for Government
The US government thinks big. We spend trillions each year. Congressmen joke that “a billion here, a billion there, and sooner or later you’re talking about real money.” And we build big documents, too. We can take 2 years to build a requirements document and just as long to evaluate how to re-engineer business processes. We don’t “do” small. But we need to.
Why? Because a key part of agility is admitting that we don’t know the answers. We are human. And humans make assumptions. Critical assumptions. And mistakes. Lots of mistakes. So, we need to design ways to test assumptions and make mistakes inexpensively. Before we commit a bunch of money to a large initiative. Every time you hear about a $100M+ government failure, you know this wasn’t done effectively.
While thinking small is related to procurement, its tentacles are broader. Before procurement comes governance. The government uses internal ‘governance’ processes to approve and monitor large initiatives. To reduce big failures, they have passed rules to require that projects deliver something at least once every 6 months. So, there is some movement towards “smaller.”
But most people involved in governance don’t know how to break work down in ways that provoke agility. They don’t yet understand how to recognize key assumptions, let alone validate them inexpensively. They believe we, especially contractors, “shouldn’t make mistakes” and if we do, the government shouldn’t pay for them. (Sure, it makes sense… in theory.) And when you believe that, you don’t plan to make mistakes inexpensively.
So on many projects, including two I’m currently involved with, “breaking things down” means releasing a piece of software to a subset of customers after 18 – 24 months of building and testing. So the “6 month thing” is more of a guideline than a rule. And anyway, if you overlay enough of these long release cycles, it looks like you are delivering something every 6 months after an initial ramp-up period.
US Government Accountability Office (GAO) reports citing $100M+ software failures should be a thing of the past. They aren’t. To get there, we need to teach the government how to break work into chunks that support effective, inexpensive learning. And “doing small” must become an essential part of how the government frames, evaluates, and approves projects.
Коментарі