By the end of this module you should be able to understand:
- What agile is
- The agile process
- How to apply agile to your everyday work
What is agile?
‘Agile’ is a relatively new method of delivering project work that has been widely adopted in digital and technology industries, and is increasingly being taken up in government.
It focuses on delivering work in small, “iterative” chunks that solve specific problems, and building those chunks together to make a solution, rather than working step-by-step towards a fixed product specification.
The Agile Manifesto (2001) prioritises:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
What is ‘Waterfall’?
Traditionally, projects are managed in a style known as ‘waterfall’. In this method, a project plan is built by working out what sequential steps will need to be taken to meet an end goal, and working backwards from a delivery deadline to plan that activity. PRINCE2 is an example of this type of methodology.It’s the sort of thing you can visualise in a Gantt Chart.
Waterfall thinking is popular in industries such as construction, where budgets and timeframes are fixed, and tasks need to be completed in a set order (eg. you can’t lay the carpet before you’ve laid the foundations).
Waterfall projects have their advantages, but when we need to adapt to rapidly evolving technologies, being tied to a fixed plan allows us less control, and can result in going over time or over budget.
How is agile different?
Agile provides an alternative method by breaking down large, complicated projects into small, simple ones, and working on a bit at a time. By doing so, we can reduce the levels of risk in a project. Here’s how it works.
Agile work tends to be made up of 4 phases:
- Discovery – working out what your user needs are, what services already exist to meet those needs, and how they are currently performing.
- Alpha – building prototype services to meet the user needs, and testing them with the users. Understanding what you’ll need to do to build and run a functional end-to-end service. You can think of this as ‘proof of concept’.
- Beta – building an end-to-end prototype, testing it in public and preparing to run it
- Live – releasing and running your service, and continuously improving it based on analytics and user feedback.
At the end of each phase there will be a working system, informed by the needs of its users. In the waterfall way of doing things, a live system might not be seen by the users until right at the end of the project, which is risky.
The discovery and alpha phases are short – often less than 10 weeks. Work is managed in weekly or fortnightly ‘sprints’, with a key chunk of work built and tested after each sprint. At the end of each sprint, an agile team will ‘show the thing’ that they have prototyped, and reflect on what they need to deliver over the next sprint.
Once a sprint is complete, the team moves onto the next sprint and works on a new set of features, each time building up the system to meet the identified user needs.
Agile is great for building products, but is also increasingly being used as an approach to policy making. The user testing that’s integral to developing a modern digital service can also highlight where policy needs to be improved. This takes a bit of a culture shift – GDS has published a useful blog on being agile in a non-agile environment which is an interesting place to start.
This video is a great introduction into what agile methods are, and how they work.
Examples of agile
In November 2013 the digital team worked with internal communications colleagues to build a new intranet for DH staff. We replaced the old system (called Delphi) with one that is 4 times smaller, 5 times faster, 90% cheaper and built around user needs. The 4 phases of work looked like this:
- Discovery – conducted extensive user research to build up a picture of what would make staff’s working lives more efficient and less stressful
- Alpha – created a minimum viable product (MVP) and tested with 100 users across DH
- Beta – ran 3 development sprints, constantly iterating and refining content and functionality, and tested with 20% of DH
- Live – the new service went live
Since going live there have been 3 further development sprints to ensure the platform is responsive to the changing needs of users.
This will continue throughout the life of the intranet.
- The Government Digital Service’s service manual provides an incredible amount of material on the phases of agile project delivery.
- The Agile Manifesto is one of the earliest articulations of the agile way of working.
- This blog from the digital health team looks at how agile methodologies might be applicable to policy, with a guide to the ‘double diamond’ model of product/service design.