Find agile government news, case studies, videos, training, and more at www.agilegovleaders.org.
Agile methods are intended to help facilitate continuous learning during the development of a product, ensuring the greatest value based on user feedback, prototyping, and testing. Product roadmaps change to reflect new learnings; user needs are re-prioritized with each new iteration. This has worked excellently for product development in the private sector, as evidenced by the popularity of agile methods among world class firms.
But there is a built-in struggle when bringing an agile approach to government projects. Value is still the goal, but it is hampered by the structure of traditional fixed scope government contracts. There is a 100% chance that the scope of a project will need to change as new learnings are discovered, yet government projects are usually constrained by default into rigid parameters of cost, scope, and time — making it difficult to shift course in order to bring maximum value to taxpayers.
The appeal of an agile process is that adjustments can be made quickly in response to new learnings, but this approach is hampered by the traditional change order process of a government project which involves many tiers of approvals and time delays.
As agile gains traction in government projects, there is a growing recognition that defining a completely fixed scope is both impossible and unwise because it leaves little room for iteration — and this fact should be considered during the upfront planning and estimating of a project. On the other hand, it’s understandably difficult for government to justify an investment that is not fully defined. Agencies want to know exactly what they will be paying for and citizens want to be assured that their money is being wisely spent.
The balancing act
For most agencies, the transition to agile is an incremental process that doesn’t happen overnight. There is often a struggle to balance the appeal of a fixed scope (to justify project funding) against the necessity of flexible prioritization (to ensure customer satisfaction).
The fact is that ultimately, no one knows what will be learned during the course of a project.
The most successful projects prioritize things that bring value. Governments can learn to do this, even within the confines of a fixed scope project (if they must). The essential element is learning, which adds value to the end result if it can be incorporated into product decisions.
Here are some solutions that aim to help smooth the transition to agile for governments that are still stuck with fixed scope contract environments.
Tip #1: Even if you have a fixed scope, allow an MVP to hold first priority.
To help aid the transition to agile thinking, allow an MVP (minimum viable product) to act as a priority within the fixed scope portion of a project, helping the product owner see how their decisions about other parts of the project will affect the final product. Conventional agile accepts the MVP as a critical aspect of defining priorities. By applying this concept to part of a government project, an MVP becomes a tool to promote continuous learning and lower risk, even in a fixed scope environment.
Tip #2: Establish regular user feedback loops and rapid prototypes.
Produce wireframes and get them in the hands of users early and often for feedback. Wireframes should be relatively low fidelity — meaning not completely implemented, fully designed, or even feature complete. User testing should be brief and implemented into an updated wireframe. Vetted wireframes will ultimately ensure developers work on a more effective initial implementation. This is an essential practice for guiding the project in a direction that provides the most value to users.
Tip #3: Understand change management and embrace new learnings.
Prioritization is a “point in time” decision based on what is learned. All items that are prioritized should be at the discretion of the product owner, but this person should have some awareness of the overall impact to the project — especially if there is a threat to the delivery of the MVP.
Typical agile wisdom says the product owner has absolute authority on product decisions — but weaving agile into fixed scope contracts may require a more flexible version of this approach. Decisions made by a product owner must be analyzed to avoid contractual risk with respect to existing expectations. This doesn’t necessarily prevent continuous learning but helps to inform a product owner of potential contractual changes.
Tip #4: Promote agile within your contracts if possible.
Although some degree of a fixed scope may be defined in a contract, how the scope is defined is up to the contract administrators. Scope can be defined as a set of goals or objectives. Objectives can be defined at a high level and written in a way that empowers the product owner to deliver the most value to users. This approach broadens the definition of the MVP and yields more freedom in the learning cycle — if changing needs are discovered, those can be incorporated within the overarching goals in order to deliver a valuable and useful product.
As agile methods continue to become more prevalent in the government context, each agency will have a different story for “getting there”. But ultimately, we all want the same thing as citizens — to know that our tax investments are effective and that our interests are being met. Even in the constrained government contract environment, this can happen if agencies are willing to listen to users, embrace new learnings, and adopt a more iterative approach.
Agile Government Leadership is a group of agile professionals bringing government experience and perspective from federal, local, state, and industry. You can visit our website for free resources, news, training, case studies, and more: www.agilegovleaders.org