After a decade working in some of the most complex, highest revenue raising programs in Australia, I think I’m now understanding the nature of government programs and what agile means to the Australian Federal Government.
Several of the Agile Release Trains we were coaching to be agile pivoted in less than 6 weeks from announcement to implementation of their COVID-19 Job Keeper measures. This was down from 6-9 months only a year earlier. We were very proud to have brought agile to these teams and their leadership.
A dozen different divisions in a government department were trying to merge (aka “MOG” – Machinery of Government) but there was little progress and little transparency after 6 months. Their CIO asked if this could be done in an agile way. It could. And we helped teams of teams collaborate and iterate their way toward merging. Executives saw immediate progress and radical transparency of what was holding them up. As CEO of ZXM, I was very proud of my agile consultant teams working to help and coach people throughout the ATO.
So, I’ve taken some time to reflect on what are the core elements that have made these agency’s work successful and define an operating framework for agility for government.
We all like to follow the proverbial “bouncing ball”. A well defined process makes things easy to follow. It makes management of the outcomes of a process easy. It should also make decisions easy: you know exactly what to do and what to produce at a specific time. This is a methodology. And it’s exactly what we don’t need in complex environments, especially for government.
Traditional linear, Waterfall methodologies, assume that by creating a plan we can know how every part of a solution will come together. The reality is very different. Only when we start to put the pieces together can we be certain that they do indeed fit together in the way we’ve planned. This is why we need agile frameworks like Scrum and not Waterfall.
As more is unknown than known then only an adaptive approach to planning will deliver sufficient transparency to whether we’re going to achieve an intended outcome.
Scrum remains my favourite of the agile frameworks because it is a superior framework for making iterative steps toward a goal. Set a goal, create a list of work that will help achieve that goal, and then work with long-lived teams in short work cycles (“Sprints”) to iterate toward the larger goal. Each Sprint contributes a slice of value to the bigger goal. And if we get to the end of a Sprint and need to create a different plan or adjust one so we continue to head toward the bigger goal, then that’s what we do.
The results from this way of working are pretty straight forward:
To make this way of working – using agile frameworks – operate successfully in government requires more than just implementing a process.
While these elements are not unique to government being agile, they are a vital component of changing behaviour from upfront planning mindset to iterative planning and adjustment based on increments of a working solution over adjustments based on % complete of activities.
Short-lived teams and projects create a short term focus over a sustainable long-term focus. New operating models with new capabilities are needed to create the structure needed to make foundation elements real and tangible.
When an organisation isn’t there for purely commercial reasons, sometimes it’s hard to understand what benefits a government agency can reap from being agile. Simply, agility for government means delivery of value to its citizens with lower costs, in a faster timeframe, without sacrificing on quality. Agile never means doing bad work. Agile never means compromising on quality to get out an initiative, a policy, or software faster.
The State of Agile survey has, almost every year, identified that the following are key risks to adoption and sustaining good agility:
For agile to truly succeed, and to be faster to pivot, and to reduce costs, the entire system of people, process and tools must change. You can’t get twice as much in half the time as an outcome if you just “tweak” the way you work, change to visual management and kanban, and just do “stand-ups”.
Many agile initiatives I’ve coached have failed because the system of work is only tweaked, people don’t change their behaviours, and leadership feel “it’s just a team thing” and don’t change the way they work themselves.
If you want the outcomes that strong agility brings, the risks must be mitigated and the way the whole system of work operates has to eventually change.
That doesn’t mean, though, you can’t change a few things and not get any benefits. But the team will quickly run into a wall in terms of productivity improvement if other teams and if managers don’t also change. This of course takes time. If you’re willing to get the results agile will bring, be prepared for a collection of teams to take 6-12 months to have new, sustainable behaviours. If you’ve got several large programs of work, and want to be agile, be prepared for it to take 3 months to see results, and 6-12 months to see outcomes, and 3-4 years before the behaviours attached to organisational culture begin to show signs of agility.
Agile product management operating models that work well include Scrum @ Scale and SAFe. When the whole system of work thinks agile and works in an agile way I’ve seen ability to pivot happen in whole programs reduce to a few weeks and cost savings for teams in a large program to amount to $3M AUD per quarter. These programs have a familiar agile “fingerprint”:
How do you write great User Stories?
When building Agile OKRs I start with the strategy and then ask if the attribute we are measuring, increased or decreased, and by what percentage? This is why flow metrics around ability to innovate and get to market as well as customer outcomes are where I start to build my Agile OKRs.
Here are my learnings and my tips for preparing for the PSPO PST Journey and PSPO III exam.
Understanding the value stream’s attributes and how the enterprise serves its customers, allows us to look at ways to optimise the operational value stream. This is why measuring flow metrics such as Ability to Innovate and Time to Market based on mapping the value stream are key.
What are flow and value metrics and why should you make the change from project management metrics ?
When building Agile OKRs I start with the strategy and then ask if the attribute we are measuring, increased or decreased, and by what percentage? Thi
Copyright © Zen Ex Machina® and ™ (2021). All rights reserved. ABN 93 153 194 220