What will it take for government to truly become agile?

By Dean Gingell

October 14, 2015

With enthusiasm from a new Prime Minister for digital technology as a means of government service delivery, government departments have been given a mandate to become more agile.

But while Malcolm Turnbull seems to be talking about “agile” with a small “a”, there is an Agile with a capital A — a rigorous methodology which start-ups and larger digital companies have been successfully using for years to accelerate innovation.

“… it’s worth paying attention to how the Agile approach … can be used in government because it goes very well with digital.”

Seeing the well-intentioned enthusiasm for government for adopting these capital-A methods in The Mandarin, I thought it might be worth highlighting the lessons that other large organisations have already learned. In my experience in the digital start-up arms of major enterprises such as Bigpond, Fairfax and Westfield, successful Agile product development is easier for small start-ups than large existing organisations. Moreover, the reasons for success or failure of Agile projects in larger organisations typically revolve around the problem chosen, the mandate provided and set-up of the Agile team itself.

I would also argue it’s worth paying attention to how the Agile approach, with its adaptation to the environment and experimental approach, can be used in government because it goes very well with digital. With so many technologies that now work together more easily than ever and the imperative to deliver government services more efficiently and quickly, this switch to Agile methodologies using digital technologies is driven by interest from the top and necessity from the bottom.

Most importantly, an agile approach is much more likely to succeed than more traditional methods, as large IT projects conducted under these approaches have a well-known, fairly dismal track record in governments and other large organisations.

Agile and data driven –- the philosophy

Words like agile, digital, lean star-tup and pivot are often mingled with other vernacular from Silicon Valley and have been popularised in books such as The Lean Startup by Eric Ries. Ries himself also argues that his Lean methodology is as applicable to large organisations as small start-ups. However, having worked in both large companies and start-ups as they’ve adopted agile methodologies, I would argue it’s far more difficult to achieve genuine, timely innovation in larger organisations than in tiny new ventures, despite the much larger level of resources that are often available.

Some of these issues are outlined in the Innovators Dilemma by Clayton Christensen, which is about the difficulty of innovating within larger organisations. For example, a common issue in large organisations is that to obtain the required budget certain promises must be made on direction. At the same time, an experimental approach is not well received, which makes it difficult for an Agile team to do one of their most important manoeuvres — “pivoting” (quickly changing direction) to succeed.

Before we dive into how to make agile work within large governmental organisations, we should start with an agile manifesto for government, or a Lean start-up approach to government services. Agile has many approaches, of which “Scrum” is the most popular, but they all share the following characteristics:

  • Work is done by self-organising teams that draw on the full talents of those doing the work. The team includes all that work on the project including not only developers but designers and relevant subject matter experts.
  • Work is focused on directly meeting customer needs (note that this means the end customer, not internal stakeholders).
  • The lens that focuses attention on the customer needs in the Agile scrum methodology is the “product owner” who is part of the team. In practice, the product owner is first among equals as they also manage stakeholders.
  • Work proceeds in an iterative fashion through “sprints” — a short period of work, typically a few weeks, for the completion of a set of prioritised tasks resulting in a deliverable or software release.
  • The aim is to release a minimum viable product into the world as soon as possible and start collecting data on its use in order to improve future releases.

This approach is very different to the traditional hierarchical and top-down, directive approach employed by large organisations. It is effective because it empowers teams, and those teams become increasingly productive and happier as they gain experience.

Of course, the flipside of this approach can be tensions within an organisation’s usual hierarchy by Agile peer-based teams typically ignore the opinions of “hippos” (the highest paid people in the room) in favour of focusing on the customer.

The Agile teams’ “product owner” role (note that the DTO calls this role a product manager or service manger in their guide to Agile terms) has a lens focused on the customer, while also dealing with feedback from the large organisation’s hierarchy. It’s a difficult role if the organisation doesn’t empower and trust the team completely.


The reality is that it takes time and experience to build truly agile cultures so it is important to select the right project to start with and perhaps bring in some external help if internal resources are not already experienced in Agile development.

Projects should be selected whose success is measurable but also where experimentation is probably necessary to optimise outcomes. Focus on how to capture and measure the relevant metrics in tidy data sets that provide enough information to allow teams to decide how their experiments are going, and whether or not to pivot.

Smaller useful products created early in a process can be increasingly connected together using application programming interfaces or APIs (the “glue” that binds many of the digital applications we all use every day by allowing them to communicate and work with each other). These enable projects to share each other’s resources and data and are very popular in building larger more powerful systems.

Finally, it also takes time and experience to get the best out of digital tools so input, talent and skills are important for success.

Agile success factors

Agile is not easy, so it is usually best to select people and objectives that are likely to succeed and then build on that success as the Agile culture becomes established.

The key in Agile is to select projects that are likely to be suited to the approach, with its variations in scope focusing on measureable outcomes and empowerment of staff. A good candidate for a successful Agile project is likely to have the following characteristics, which come from Nic Holder, managing director of LEK Consulting:

  • It needs to be something which the leadership really cares about and is known to care about — the agile team needs a strong mandate as it elbows its way around established ways of doing things;
  • It needs to be something where the team is free to make change happen, independent of long-term irreversible system roadmap issues;
  • It needs to be something that is not totally mission critical right now — if innovation fails then heads don’t need to roll (in other words, the leader needs to remove fear of failure from the team;
  • It needs to be something where early impact can be detected — allowing an immediate feedback loop to create velocity and the unprecedented tempo;
  • It needs to be something where early impact can be celebrated and energy snowballs – lots of people outside the agile team need to share the excitement, and add support to help create a “movement”, and;
  • It needs to be a problem where feedback can be measured and rapid, changeable actions can be put into the field immediately — agile is not about making new plans, consulting and so on; it is about learning by doing.

It’s not surprising that definition comes from consulting because data-oriented strategy firms like LEK focus on bringing together teams to solve business problems in relatively short timeframes, in a similar manner to a time-boxed Agile team.

It’s also not surprising that the teams that are put together to solve a problem might give way to Agile teams who solve it with digital tools and adapt and experiment when all the answers are not knowable upfront.

Select really expert people into the relevant roles regardless of background and empower them. Generally high performing people will start to put the performance of the team ahead of other priorities. Set time limits for the project so that everyone involved knows that resources are not infinite and there will be a time to finish.

Be aware, though, that most successful Agile outcomes morph from a project to a valuable product that requires some ongoing care and attention. This means you should always make sure to plan for continuous measurement and improvement

Some further tips for success in large organisations in particular centre on teams and how they’re managed:

  • Good Agile teams are egalitarian — hierarchy is flat and people are treated with respect, regardless of how they’re employed (e.g. permanent or contract). Most importantly, hippos don’t dominate.
  • Teams are co-located (although I have experienced successful Agile teams that are geographically spread using tools such as Skype for communication).
  • Learnings are rapidly incorporated each sprint and over time velocity (productivity) improves as people get used to working with each other efficiently as the methodology of Agile is observed.
  • Stakeholders are strictly managed through a single product owner so that the team is not pulled in multiple directions at one time.
  • There are metrics to optimise to measure real business success and learnings (i.e. not “vanity metrics” such as page views of a website which don’t lead to action)
  • People know their roles and are eager to contribute and optimistic.

A great example of a successful Agile product development was one at Westfield to mobilise inventory and other vital (for shoppers) information about Westfield shopping centres in an early mobile web output. The project succeeded as marketing experts joined experienced Agile designers and developers in a team over a very short timeframe of 12 weeks. At the end of that time, we had a sophisticated but easy to use Pinterest style product for mobile in the market. Importantly, the team members had all learned how to do Agile well after a couple of years of working on larger Agile projects.

Now is the time, while there is interest from the top and necessity from the bottom, to adopt the Agile philosophy in solving problems in government service delivery. Many organisations in government have a renewed enthusiasm for doing quick service delivery in an agile manner.

Agile with a capital A is a rigorous methodology suited to rapid and high-quality development, and for developing and delivering innovative approaches to government service delivery. It does come with a number of prerequisites for success but if they’re followed, it can be used to maximise the speed of delivery and the probability of success.

The Agile approach works particularly well for digital projects and doing it reasonably well is an extremely valuable tool in a public service organisation but requires practice and attention to this issues raised in this article.

About the author
Inline Feedbacks
View all comments
The Mandarin Premium

Canberra’s changed

Stay on top for only $5 a week


Get Premium Today