- About the Department
- Advertising - Campaign and Non-Campaign
- Assurance Reviews and Risk Assessments
- Australian Government Investment Funds
- Central Budget Management System
- Financial Reporting and Accounting Policy
- Land, Property and Asset Management
- Parliamentary Services
- Resource Management
- Vehicle Leasing & Fleet Management
- Whole of Government Information and Communications Technology
- AGCIO (216)
- AGCTO (179)
- AGICT (141)
- Accessibility (15)
- Big Data (13)
- Cloud computing (37)
- Common Operating Environment (11)
- Data Centres (49)
- Document Accessibility (9)
- General (62)
- Gov 2.0 (65)
- Guest post (17)
- ICT Strategy (16)
- ICT Two Pass Review (1)
- Mobile (11)
- Open Source (5)
- Procurement (181)
- Procurement Coordinator (105)
- Skills (26)
- Standards (10)
- Telecommunications (10)
- Web Guide (23)
Behold the Power of Agile
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 Australia.gov.au, The Australian Government Directory (GOLD), data.gov.au, Govdex, Govspace and Govsearch.
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.
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.
Last updated: 23 August 2016