Agile product management relies on flexibility and working at pace, so how exactly can we apply this methodology in regulated environments such as the public sector?
With Agile products, it’s inevitable that specific requirements will shift in response to user feedback as well as an improved understanding of the specific problem at hand. This can lead to challenging conversations with sponsors and key decision-makers as this can be perceived as an increase in scope (in other words, the dreaded “scope creep”).
This is why it is so important to take the time to set a clear vision for your product, get buy-in on this from the start, and use this vision to define milestones. You can then review and adapt the specifics iteratively while continuing to drive towards these milestones, enabling you to flex according to changing requirements while also giving your sponsors confidence that this isn’t scope creep.
Anyone who has worked in a regulated environment will know that difficulties often arise when budget approval is given to deliver an exact scope in a specific time frame. However, due to the nature of Agile delivery, or dependencies on different teams, requirements change and subsequently, delivery timelines get pushed out. You won’t have an exact view of what you may build over the year but if you can get your stakeholders to understand that you will only build what adds the most value based on user feedback/user needs etc., these conversations will become much more fruitful.
Ultimately, there needs to be space to flex and respond to shifting requirements in Agile product delivery as there needs to be sufficient space to gather user insights and iterate on the product. If we’re too rigid in our planning, we risk delivering products which do not respond to our users’ needs and which will ultimately result in low adoption and/or low user satisfaction.
Successful Agile product delivery requires significant focus and a cautious approach to risk management. The best-functioning Agile teams will have a robust process for managing risks, issues, assumptions and dependencies in some form. This allows Agile teams to deliver at pace while ensuring that risks and issues have clear mitigations and that stakeholders have the transparency they need to make key decisions. Stakeholders need to trust they will be brought in early when issues arise that need their resolution and will be provided with all the information they need in order to make the right decision in a timely manner.
While part of the Agile manifesto is ‘Working software over comprehensive documentation’, in regulated environments it is sometimes impossible to avoid documentation altogether. Instead, you need to find the right balance between what is a must and what is nice to have.
Strong, collaborative, cross-functional teams can make or break Agile product delivery. As consultants, we are often brought into projects because something isn’t working and one of the most common sources of friction I have come across is tension between team members leading to silos. As a product manager, it is your job to listen for the 10% truth and to try to understand where people are coming from. At the end of the day, a product team should be driving towards a shared goal so understanding someone’s unique perspective can help you to guide them back towards this vision.
Additionally, product managers play a key role in creating collaborative environments as it is our responsibility to represent the voice of the various stakeholder groups and prioritise these different opinions to progress the vision and strategy of a given product. Not only is it important to foster good collaboration within the team, but it’s important to do so between teams too and create a one team approach to resolving issues and delivering value. This may sound simple but instead of trying to find who to blame for something going wrong, taking the time to see how it can be improved next time and how to resolve it for now is essential to create high-performing teams.
At the end of the day, very few projects are true paragons of Agile delivery. After all, Agile is a methodology that provides some great guidance for delivering products and projects that truly respond to user needs and requirements, but organisations and people are complicated and it’s important to be flexible in these different environments.
This doesn’t mean that regulated environments, such as the public sector, should avoid Agile entirely as traditional Waterfall delivery is also at risk of delivering a product which does not sufficiently respond to user needs.