Behold the Power of Agile

Sharyn Clarkson

The Department of Finance Archive

The content on this page and other Finance archive pages is provided to assist research and may contain references to activities or policies that have no current application. See the full archive disclaimer.


Online Service Branch is a small, lean and busy branch which develops and maintains a range of ‘Whole of Government’ information and service products such as, The Australian Government Directory (GOLD),, Govdex, Govspace and Govsearch.

We love innovating and coming up with new ideas. This year we are focussed on the redesign of and making GovCMS a reality, two very exciting pieces of work!

We face the same issues as others across government and in the private sector. We’re getting smaller and leaner but have more products to maintain. And if we want to keep good people we have to keep doing interesting work and create things that make a practical difference.

So for the last 2 years we have been undergoing an extensive transformation to make ourselves more efficient, our products more robust and to keep improving our sites for our customers.

Central to our transformation is our adoption of an AGILE approach.

The problem we needed to solve

Our technical resources were then, and still are limited and prior to the adoption of AGILE, individuals focused on and were experts in, one particular product. We had stovepipes of knowledge, we were at risk when people left for a new job, took leave or were sick and we often couldn’t muster the resources to make improvements to products unless we had a funded waterfall project. With up to 7 services to maintain and an expectation that we continue to produce new things, but usually only able to commit to two projects a year, you can do the maths. Even when we initiated a project, it took a long time to get going and we were slow at releasing the changes and improvements to our customers.

decorative wordmap. keywords: agile, development and software

How AGILE is making a difference

With AGILE the team can now focus on a single product in a short development sprint (at the moment we use 3 week sprints). This has empowered our team and we are seeing improved quality with better knowledge transfer and peer review process. We also have a faster release cycle with more work being included each release. Furthermore, the individuals in the team retain their existing expertise but now also broaden their skills and are experienced across a number of products.

All our products are up to date technically; all our products are regularly releasing improvements in user experience and functionality to our users. And for our people, seeing that a good idea can go from being suggested, the idea tested with users, designed, implemented and released live on the site in only a matter of weeks is both satisfying and addictive.

We sought/anticipated/hoped for these improvements in the move to AGILE and got them!

We got benefits we didn’t expect

We also accrued a number of other benefits that we did not anticipate including:

  • Better shared planning as the sprint schedule is developed collaboratively several months in advance and is stuck up on the wall for everyone to see.
  • Better communication across the branch as people and teams need to interact continually during the sprint.
  • Business is more empowered as they can get the changes they want done faster
  • Increased productivity during the sprint due to requirement definitions
  • Improved morale from the improved communication and release cycle as teams are able to see a much closer connection between collaborative effort and the end result.

So what’s next on the AGILE front?

We are looking for ways to increase our productivity further and will experiment with running more than one sprint concurrently within the resource limits we have.

We are adopting an AGILE like process to manage “Business as Usual“change outside of the sprint process, (use your favourite search engine and find “Kanban”).

This is our first blog post about the how we have changed how we work. Over the next year we’ll be sharing more about our experiences, sharing artefacts, writing about specific aspects of AGILE, talking about the issues and risks we encounter and sharing the results as we try faster sprints, concurrent sprints and sprinting for business as usual tasks.


Comments on this blog are now closed. Please let us know if you would like to discuss this post or have any general comments.

Comments (8)

Hi Sahryn,

This sounds like great news for OSB and also for government. It is working examples like this which are needed to display how successful this approach can be. Even within the realm of government.

It would be great if you could go into a bit more detail about the BAU element in your future posts.

Good luck to OSB into the future. :)


Great to see a concrete example of Agile working for an internal public sector team. It would be great to hear how you made the case for change and made the switch.

Thanks Geoff,

We are really happy with what this approach has done for our group. It's worth noting that we haven't experienced any negatives from doing this which I think is quite rare when you have completely changed the way you work.

We will write up our experience with Kanban for business as usual, probably not till we've given it at least 3 months to properly trial it, but I'll add to the list of future blog posts to write this year.


Hi Rebecca,

That's a good point and its a large part of the reason for writing this blog post.

We aren't the first or the only team in government to be using AGILE but we are uniquely placed in that our leadership is supportive of us talking about the changes we make and the new things we try, and that we have the Finance AGCTO Blog to facilitate the conversation.

Being a 'whole of government' focussed team we talk to other web and IT people across government all the time. We know that many people across the APS want to work differently but are sometimes unsure how to make it happen. I hope that writing about our adoption of AGILE and the success we are having from this approach will be useful and provide others something 'local' to reference if they decide to raise the idea in their agency.

I came into Finance having already led AGILE teams elsewhere and my branch had already come to the view they wanted to try this, so that part of our journey was very positve and completely painless. But I still had to to get buy in outside of our team.

A follow up blog post (coming soon) will go into a lot more detail on how we socialised the idea outside of our branch (especially upwards) and how we got the ok to go ahead.


Congrats on this shift in thinking and the way of working. Working agency side, we have been advocating an AGILE style with some of our clients, but the transition is not easy for every organisation, it requires a healthy dose of willpower. Great to see the evidence of it being worthwhile and working.

An inspiring write up Sharyn, thank you for sharing. I suspect I'll be getting in touch to share war stories.

7 services x 3 week sprint is still 5 months between updates to each. Are the customers happy with this frequency?

Thanks Berry,

Interesting to hear your experience. I wonder if you want to share your observations on why some workplaces struggle to get this working for them?

We do have people in our team who hadn't had good prior experiences with how AGILE was used in other places though they also saw the value in the method if it could be done well. It's to their credit that despite that history they were fully behind giving it a go.

I can't explain why we're managed the change so easily, it just hasn't felt like hard work at all.

However it shouldn't be imagined that we picked up the AGILE method and started with a stand-up on Monday morning, doggedly applied it by the book and the team just quietly followed the direction. We had a far more iterative journey, the sprint teams had lively review sessions and loud robust debates. They tried following the method rigidly and tried doing it free form in keeping with the spirit of what we were trying to achieve, and somewhere in the middle of this we have found what works for our environment.

Maybe preparation was another part of the reason its working. We did socialise it across the team well before implementing. The team wanted to do this. And we did pick our time to begin quite deliberately to coincide with a short lull between major projects, in that we knew that people would need the space and time to make the shift.


Hi David,

Good spotting! We do have enough sprint capacity to keep all sites upgraded, patched and working and progress modest iterative improvements. But we need to find more capacity which is the reason behind us wanting to try 2 week sprints and double sprinting.

Looking across the full range of our products they are at different stages of their life cycle. Some are very mature and stable and require only minor iterative improvements, some are coming to end of life technically so major change and investment will be deferred until they have been re-platformed or completely redesigned meaning that only necessary change is being implemented. Some are being aggressively improved with frequent sprints. Our sprint schedule isn't giving equal time to all products.

So to your question: I think our customers would like us making constant improvements much more regularly:)

I'd like to make constant improvements especially to the user experience.

My challenge is trying to find ways to make that a reality in the current fiscal climate. AGILE is just one of the ways we are trying to be more effective.


Last updated: 23 August 2016