Building agile and adaptive public institutions: insights and observations

Last week, I had the delightful opportunity to host some discussion tables at the 9th Annual FSTGov Government Summit in Canberra. It was an event designed just for public servants, to explore challenges and opportunities for reform and how to better serve the public. I hosted four groups in discussions about “how to build agile and adaptive public institutions”, which included 40 public servants from around 30 departments and agencies. The challenges, insights and highlights are captured below, for broader sharing and learning 🙂

What does agile and adaptive mean?

Challenge: The groups reflected that agile and adaptive still sound a bit buzzwordy, so we explored and documented roughly what they could and should mean in the context of public institutions. 

Insights: Several participants talked about the use of Agile in their orgs (usually in the IT departments) as a development methodology, which helped others to understand that context. When we discussed how to build agile and adaptive public institutions more broadly, we identified a few useful characteristics, which made it more broadly practical:

• Evidence-based and purpose-led at every step – too many people think agile just means fast and iterative, but you can’t iterative towards a destination that is undefined, and if you aren’t using evidence, testing and experimentation to validate and invalidate along the way, then you end up building a lot of unnecessary or even counterproductive things.
• Actively monitored and measured – we discussed how you can’t adapt to change if you don’t have the means and mechanisms to detect change in the first place. Active monitoring is already usually done for system performance (uptime, downtime, latency, etc) and for CX (user satisfaction, etc), but if we don’t also actively monitor for measurable policy impacts and for unintended quality of life impacts, then how can you adapt the policy interventions (which includes services) to ensure policy intent is being met in a humane way? In other words, how can you do no harm if you are unable to detect it? Active monitoring is critical to being adaptive, and to prioritising decision making about investment and efforts (including in the backlog).
• Operationally enabled for continuous change – it’s not enough to just detect change. You need to be able to respond in a timely manner. This is the heart of being both agile and adaptive. If you have a hard and unmovable plan for what you are doing, then you systemically remove the ability to naturally change or adapt according to the results of user testing, to new evidence  or to new extrinsic pressures. This means change only tends to happen under the pressures of urgency, which leads to a lot of short term and techno-centric prioritisation, rather than policy or user-centric prioritisation. Modern organisations needs to be operationally enabled for continuous and evidence based change. This includes delegating actual decision making as far down as possible, so that the people closest to impact and expertise are able to respond quickly to change, with oversight but also trust from their managers, a serious culture change for many teams. 
• Active feedback loops – Monitoring gives you quantitative data, but feedback gives you qualitative data, which can be key to identifying when things are not going well where the monitored measures might be missing something. Open and continuous mechanisms for feedback from end users AND from staff are key to keeping a finger on the pulse, to be adaptive to early indicators of problems before they snowball.
• Staff capacity: necessary to experiment, innovate and think – most public servants are working 100% on the most urgent thing, with no time to stop, think, plan or try something new. Under such conditions, it is little surprising that public institutions are generally slow to detect and respond to change and challenging for individuals to innovate. All public servants, at all levels, could choose to free up 5% or 10% capacity to experiment, innovate and even just to think and plan. For those horrified at the idea who are looking at the exponentially growing backlogs of work, I would suggest that throwing more resources at doing the same thing (a linear response) will only continue to fail at addressing the backlog, because we need exponential solutions to exponential problems. A little time to innovation, to re-engineer, to address causal issues and to work smarter, would create the conditions for more agility and adaptation at a grassroots level. The best way to scale is to support all public servants at all levels to improve their impactfulness, which can’t be done without a little capacity.
• Operational transparency – when you have easy to access visibility of your work program (what is currently being worked on, what’s done, what’s on the roadmap, etc) as well as in showing the outputs of your work (eg, sprint/code/policy reviews, showcases, blogs, research papers, etc), the you achieve two things that helps with institutional agility and adaptability. Firstly, you create an environment where anyone can offer peer review, expertise, experience and serendipitous networks of similarly motivated collaborators, providing the ability to deliver the best possible outcomes. This leads to the building of confidence in what you are doing, which speeds up delivery and adoption because we all work essentially at the speed of trust.
• Financial agility – all tables spoke about the challenges of “waterfall” budgeting and having to define every cent and deliverable years in advance of starting the work (through business cases, NPPs and the like). But even the Finance people in the discussion talked about wanting to shift to outcomes-based budgeting, and encouraging smaller investments in delivering an MVP rather than high risk big-bang launches of new systems at the end of the program plan. There is certainly opportunities to do small things within the cadence of budget planning that can help bring financial agility. For instance, choosing the use outcomes or epics as milestones in delivery roadmaps (rather than functionality or platform based milestones) which ensures you deliver something that works with flexibility on how to get there. We discussed sprints-based procurement, which I first saw at Dept Finance (APS), but none of the APS knew about it, so I dobbed in the incredible Sharyn Clarkson, from whom I learned about it 🙂

“We already have adopted agile in IT, what’s next?”

Challenge: We discussed how agile adoption in IT has helped, but not solved the big challenges facing service and policy delivery in government. When IT/dev teams adopt agile methods, they are usually still in the position of receiving “business requirements” from other parts of the department who are themselves disengaged from the process of designing or delivering the service/system. We identified the fact that many departments have maintained the issues of functionally segmentation structures, with multiple “product owners” emerging (eg, a business PO and a tech PO), which defeats the purpose and undermines the benefits of product management as a methodology. We also discussed how product management, where it has been adopted, still usually relates to managing platforms rather than services, so decision making, prioritisation and risk is analysed at a platform level, not at the service level, leading to cannablistic resourcing behaviours across “product teams” that are actually part of the same service. 

Insights: Ensuring each “product” being managed is at the service level to provide a more realistic and impactful way to priotise, manage risk, maximse intended policy impact and to actively manage the end user experience. Funding a diverse product team, with the design, dev, ops, business and policy expertise all represented (even if only part time, such as 3 hours a week for a policy person) dramatically helps to ensure the benefits, cadences and agility of a proper, agile, test driven and continuously improved product management approach. Explicitly adopting an MVP deployment strategy is also necessary for product management to work, otherwise the team is still driven to build and deploy everything all at once, which never works.

How do we balance risk and agility?

Challenge: Some of the group discussions reflected on what real risk is and isn’t, and we determined that the public sector reputation of being risk averse, has created a mythology that taking no action avoids risk, when the reality is that a culture of taking no action actually creates risk in a world that is continuously and unexpectedly changing around us.

Insights: Analysis of the risk of non-action should always be included in risk assessments, as well as risk to the public and those affected by the proposal. The SES reforms underway could include KPIs for executives to ensure that personal risk is well aligned to the portfolio and policy objectives, as well as aligned to the impact on the public, so that we avoid a situation where personal risk aversion can create risk for the public institutions and/or communities we serve. Risk needs to be assessed in the context of stewardship, looking at long term and short term implications, to ensure a balanced approach, that should also then be prioritised based on measurable policy and public impact.

These are just a few of the insights and observations from our discussion, what are your thoughts? How can you contribute to creating a more agile and adaptive organisation where you work? 🙂