How to make Agile work in the public sector
“A ‘perfect Agile’ project has a fully dedicated Product Owner and Scrum Master.”
“An Agile project does not have testing outside a sprint.”
“Every sprint should result in a release to production.”
“The Product Owner is the only one who can adjust the backlog priorities.”
Have you heard these statements made like they were lines in the sand on your projects? It is almost laughable because Agile was purposely designed to be lightweight and not exclusive. It says it right within the manifesto: “while there is value in the items on the right, we value the items on the left more.” So, you can have good documentation on an Agile project. You can have contract negotiations, and you can use processes, tools, and plans to get the work approved and done.
Which is good news because the public sector is built on and has constraints around some of these things! Suppose if we told our state legislature, or the federal agency funding our project, “we didn’t negotiate a change request because we used Agile.” That would not fly with those who approve your projects and provide oversight for publicly funded projects to ensure you are using taxpayer money wisely!
Challenges applying Agile on public sector projects
We have completed at least 15 projects in the public sector using Agile. Here are some of the challenges we have seen in the application of Agile:
Being unable to iterate from planning all the way to maintenance. Most of our clients have applied a “hybrid” approach to use iterative cycles for development but use waterfall to move from approved planning stage to implementation, then implementation to maintenance & operations.
For new development, there’s rarely time or will to release to customers until more than halfway through development, if not at the end of development.
It is difficult to get a Product Owner or Scrum Master who can commit 100% of their time to the project/this role on the project. Many wear multiple hats. Sometimes the project manager or business analyst is the Scrum Master. Sometimes the Product Owner is a high-level executive with other work to manage.
It is difficult to fight against the bureaucracy of processes and top-down management when your Agile team is on an equal playing field and creating their own processes that help them deliver.
Requirements management is either burdensome due to archaic tracking systems, or nonexistent as no one has time for documentation.
Decision making is slower and less likely to challenge the status quo.
What have you experienced? Share with us on our LinkedIn page.
How the public sector can make small adjustments to make Agile successful in their organization
Some challenges you simply must accept. You are likely unable to reduce the layers required for decisions or ask for an executive to commit 100% of his or her time to your project. But you can make it easier for decisions to be made by asking and providing all of the information needed, and you can help your Product Owner focus on the highest priorities for them to be involved in.
Some challenges you can turn into opportunities. If you do not have a Scrum Master that can lead every stand up, it could force the team to self-organize, keep each other accountable, and communicate better. Turn requirements tracking challenges into an opportunity by creating a more lightweight, easily updated list of capabilities to focus the team and organization on the highest priority outcomes of the project. Write use cases or user stories to track who needs to do what and when, and track changes to them as development and implementation proceeds.
Some challenges may take more work. If your Agile project is a small part of a large organization, you may face an uphill climb changing the organization to adapt to Agile. We recommend Agile coaching for your executives to create a more adaptable culture, and at the very least, understand the importance of their support of Agile principles the project team is adopting. Releasing to customers earlier and more often requires some encouragement and perhaps data-driven approaches. You can explain to your customer service department that unless we ensure we are creating what our customers need and expect, they will be overrun with calls for help and the new system will be more of a burden than a support.
Best practices for using the Agile methodology in the public sector
Agile teaches us that people, working software, and responding to change are more important when it comes down to a decision or a constraint on resources, time, or budget. If you are able, we highly recommend hiring an Agile coach or hiring a team with experience in Agile. Even with those resources, there may be disagreements about how to apply Agile principles, so we encourage you to create ground rules for your team. Here’s some things for your team to consider:
How does everyone know when previous requirements or user stories have been changed or updated? How do we “retire” old features/needs so a new person coming to the team does not think old requirements are still applicable?
When will testing occur – within the sprint or after handoff from the development team to the test team?
How and when will completed work be shared with management and the customers?
Making decisions on these questions will set your team on the right path to succeed together and increase their buy-in to the processes adopted.
Individuals and interactions over processes and tools
Speaking of processes, you do still need them. The key is not to let them get in the way of interactions between individuals. In a remote world, there needs to be a quick way people can interact with each other, any time during work hours. Remove all blockers to anyone on the team interacting, getting answers, or waiting on others to complete their work. Do not give up daily stand ups, especially if everyone is working remotely. These are critical for everyone to know what others are working on, what issues need to be discussed, and to stay updated on the status.
Working software over comprehensive documentation
Delivering the product is the greatest advantage to executives who approve Agile projects, so pay attention to this value. To ensure focus remains on delivering working software on a regular basis, you must keep things moving. At the beginning of each iteration, be sure the client/customer and the team understand the scope of the iteration, what is and is not being completed during the iteration. Have a good change control process that everyone understands and uses, to capture anything missed. This keeps the focus on completing the current iteration.
How you will document changes, and final as-built product, should be discussed up front, either when the project begins, or at the beginning of each iteration. You may want to have everyone on the team own a part of documentation or reviewing documentation. Keep it easy to update and review, reduce or eliminate cycles of editing while developing working software, and stick with it. You will be glad you have something to give to your customers and those maintaining your system after delivery.
Customer collaboration over contract negotiation
Some vendors and clients are better at this than others. “Partnership” is one of the most overused words in consulting speak – but do they back it up with action? Hire a vendor who will put the success of the project and the product ahead of their financial gain and will not nickel and dime their client. Be the client who admits they forgot some things, had some requirements changes that were not anticipated but make a major impact on the end product. Collaborate, build trust and work through it together. Sometimes a major change request and adjustments to the contract/budget are needed. Hopefully, more often than not, you can work through adjustments without escalating it to the lawyers.
Earn trust and commitment from everyone on your team to contribute to success. This is especially important for your Product Owner. Ensure you have their attention and that they understand the need for the project delivery. The Product Owner should own the prioritization of work and be willing to face other business owners when challenged. If your Product Owner simply cannot stay focused on your project and is constantly getting pulled in different directions, escalate it as a risk and try to find someone else who has more time/commitment.
Responding to change over following a plan
Most public sector projects require a great deal of planning, reviewed and approved in multiple cycles by many people. There is a lot of investment up front in those plans. Not following all the thought and time that went into creating rock-solid plans can seem like a waste. It is not a waste. First, remember that the greater value is on responding to change. Agile does not prescribe to throwing all plans out the window. Second, your plans were conversation starters – they got everyone to the table and thinking about project results.
Be nimble and be ready for the change that will inevitably come. Know how to bring in changes and keep moving forward, and if you must, update your plans. Plan for change – include early and often inspection by your customers into your project plans, along with time and necessary budget to implement changes suggested by customers. If you can, hire a change practitioner to help with the people side of the change. Treinen has certified change management professionals that can help.
“Iterate” as you apply Agile
It may sound trite, but do not give up trying to apply Agile methodologies to your project. Agile works – it reduces costs and time when used well. It may take several tries, and changes, before you get it. We joked on one of our Agile projects that the only constant was change. Be sure you regularly hear from the team and make adjustments that will benefit them and their frequent delivery of work. That is how you know you have applied Agile successfully for your public sector project.