Agile approaches

This page explains why we use agile approaches.

The Manifesto for Agile Software Development sets out 4 principles for delivery:

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

The manifesto started as a better way to deliver software, but its principles apply in a wide range of non-technical use cases too.

For teams delivering user-centred products and services, working in an agile way provides many advantages over methodologies used in government (for example, waterfall or PRINCE2).

# Create value for people earlier

Rather than waiting 3 or 4 years to deliver a polished, finished product to users for the first time, taking an agile approach requires you to deliver in small increments, early and often.

This means users get access to new government services in months, not years. It gives you the ability to gather evidence early on of what is and is not working, before the biggest design and delivery decisions are yet to be made.

We often launch new services as a Public Beta. This makes clear to users and stakeholders that the service is new and still being improved.

# Adapt quicker

We focus planning on the things that are most valuable that we can deliver to the people who use the service.

This gives you greater flexibility to change and adapt as you go.

Working in a sprint, you'll have regular opportunities to reshape, recalibrate and reprioritise based on the things you've learned from delivery so far.

This also means your stakeholders have more opportunities to get involved with the product, playing an active role in user research, prioritising the backlog and measuring performance.

High-performing teams chase outcomes, not deliverables. This gives you the flexibility to change your approach as you find out what actually solves the user's problems.

# Reduce the risk of technology failure

Traditional waterfall IT projects favour big releases right at the end. This means risks and assumptions are not able to be tested during development.

The result may be issues only being detected when a new service is released and accessed by users. Technology might not work when it's operated in a real world environment.

Agile allows more effective pacing of the management of risk.

By releasing smaller increments of software into production far earlier into the journey, and operating it for users with genuine needs, this risk is substantially reduced.

By initially releasing software to a smaller cohort of users, or with only a subset of the overall functionality, you can prove your technology in a lower-risk environment before rolling out to a wider group of users.