A quick guide to Agile

Agile development tests working versions of a service with end users as quickly as possible. This way of working offers development teams rapid feedback and helps to ensure that the service that goes live meets users’ real needs.

Applying an Agile approach allows service teams to deal with complexity in an open, collaborative and iterative way.

Agile development stages: discovery/alpha/beta/live

Discovery is about understanding a problem before committing to building a service to solve it. It involves learning about your users and what they want to do, what constraints you might be facing and the opportunities to improve how things are delivered today.

Alpha is about trying different solutions to the problem you identified during the discovery phase. By the end of alpha, you should be in a position to know which, if any, of your solutions you want to take forward to the beta stage.

Beta is about taking your best idea from alpha and starting to build it as a service.

Live is about supporting your new service and continuously listening to your users to make changes and improvements.

[diagram of the stages of Agile: Discovery, Alpha, Beta, Live] Discovery shows a light bulb, Alpha shows a pen, Beta is mechanical icons and Live is an outline of a phone

Agile ceremonies

Agile ceremonies are regular meetings that structure a team’s work to encourage collaboration and reflection.

A standup is a daily meeting where the team discuss what they’re working on that day and whether they have any problems or blockers they need help with. Stand-ups should be short (10 minutes is standard) and focused.

Sprint planning meetings are for the team to decide what to work on next and how they’ll do it.

At a show and tell meeting, team members get to demonstrate their work. Show and tells are a great opportunity to invite stakeholders, senior leaders and suppliers to find out about the work the team have been doing. You can even open up show and tells to the rest of your organisation.

Retrospectives (or ‘retros’) give the whole team a chance to discuss what’s going well and what isn’t. They’re used to fix problems and keep the focus on the things that are working.

User-stories describe a user and the reason why they need to use the service you’re building.