Can agile work for policy?

Following the release of our whole-of-government policy for secure cloud, we look at how it was developed. And whether policy design can be iterative.

A group of people standing in front of a white board covered in post-it notes.
Caption: Colleagues from across government get involved in planning our new whole-of-government strategy for secure cloud

Agile strategy — does it work?

I was a little nervous when I joined the DTA to build a whole-of-government cloud strategy — not because of the strategy itself but because I was to deliver it using an agile approach.

I started my career as a mainframe programmer and waterfall project management was ingrained in me early on. It is a process I am familiar with and while I’ve seen agile methods become a more and more common approach to how we build and deliver products, I hadn’t seen it fully embedded in the way we deliver other activities. Was it a good approach to use for development of a strategy?

The intent and mindset is what matters

I had assumed agile was about delivering an online service, app or another type of digital product but I’ve developed a new perspective on that. A strategy is a product. There are people who use it and those users have needs. Combining design thinking and an agile approach helped me focus on those and deliver against them.

For me the mindset and process boiled down to 4 things:

  • find out what users need
  • create products to test back with them
  • take their feedback and make changes to the product
  • build something users need.

During Discovery I talked with the people that would use the strategy and tried to understand their experiences. When it came to making the most of cloud services, what were the barriers standing in their way? My users weren’t just government agencies, they were also industry.

During Alpha, I created prototypes to be tested and put them in front of the people who would use them. Was I tackling the right issues in the right way? I kept improving the prototype based on what I learnt and continued to check in.

I didn’t follow a particular agile approach. I didn’t have a Kanban, backlog or do a formal ‘show the thing’. I didn’t do sprint planning and I wasn’t in a multidisciplinary team. I questioned myself, could I really be agile without doing these things? The answer is yes. There is more to agile than the tools we use. It’s the intent and mindset that matters. Using an agile approach with a focus on service design helped me get to a product that worked for the people who need it. That’s the real benefit.

I should add, there is value in more formal agile methods. But it’s worth trying a less formal approach with a product that — at first glance — may not seem the best fit.

It is all about the user need

Discovery taught me a valuable lesson — what you think you know is not always what your users experience. I had to get my users to show me what they saw so I could solve problems for them.

I felt uncomfortable when I was faced with issues I didn’t expect. But each new insight gave me an opportunity to learn things outside my world view. The process gave me confidence I could create the right product.

Another good lesson for me was to keep checking the product was still meeting people’s needs — and I mean all the time. I ran a validation workshop with my users near the end of Alpha. They raised things I hadn’t considered because I hadn’t tested back with them enough. On reflection, I should have done more of that checking in. But I know more about what my users need now and can keep working towards that. That’s the beauty of delivering in an iterative way.

The result

Any whole-of-government initiative can be difficult. One size has never fit all and trying to have an impact across government will always need to balance what is needed against what is feasible and practical.

This is where using a service design delivery process gave me the right approach to solve the problem. Discovery helped me understand what users really needed and what was important to them. Alpha kept it on track, checking those needs were still being met, the things being proposed were achievable and I was solving real problems. Each stage added to my confidence the strategy represents a broader view across government.

The agile journey isn’t over for me. I’m heading into Beta now, implementing the strategy to deliver products we will keep working on, adapting and improving.

For me, it turned out agile could work for other products and not just for technology delivery. Waterfall was what I knew, but agile was a step in the right direction.

 

The DTA will be hosting monthly showcases for federal government agencies to share their experiences with cloud. To join our next one in early March, email secure.cloud@digital.gov.au

Marika Stefanik is an enterprise architect working with the Chief Technology Officer Group at the DTA.