Where agile comes from
Agile started out as an alternative approach to software development, but is now applied more widely to running other types of projects and products.
The principles behind agile are set out in the Agile Manifesto) (2001).
The differences between traditional and agile methods
Agile can be very different for people used to traditional waterfall methods for software development.
With waterfall methods the process is sequential. You start by gathering requirements, making plans and going through procurement processes. You then design the product and build it. In the final stage you test and release it to the public. It’s only at this end stage that you get feedback and find out if it works for your users. You only have one chance to get each part of the project right, because you do not return to earlier stages.
Agile takes a different approach. You do all these things - gathering requirements, planning, designing, building and testing - at the same time. You start small in the discovery and alpha phases.
You research, prototype, gather data, test and learn about your users’ needs before you start building the real service in the beta phase.
You only go live when you have enough feedback and data to show your service works for your users and meets their needs. You continuously learn and improve to build a service that meets user needs.
Why agile is better for services
While a sequential waterfall approach is necessary to build things like bridges and buildings, it’s less effective for building and running services when technology changes quickly.
Government services also need to be able to respond quickly to policy changes and the needs of the public.
Using waterfall methods means you may spend 18 months building a service that no longer meets government policy, cannot work with the latest technology and does not meet users’ needs.
Agile methods allow you to quickly make any changes while you’re building the service, and also when it’s live.
Agile fundamentals
- Standups: the team meets daily for short meetings which are typically held standing up, face-to-face to encourage brief sessions. This is not a status meeting. This meeting is for people to ask quick questions that will allow them to get information or remove blockers. Long answers and discussions should have follow-up in smaller groups after the standup meeting.
- Retrospectives: on a regular basis, at end of each sprint, weekly or bi-weekly, a retrospective allows for the team to reflect and adjust practices. Any team member can voice a problem or propose a solution Sprints are the heartbeat of the agile process. Small units of work are delivered in short bursts, typically with 1 or 2 week cycles. We aim for visible progress for people from the target audience that is delivered and validated at the end of each cycle, allowing the team to move iteratively toward the goal, with regular opportunity for course correction.
- Sprint planning: include the whole team in reviewing stories, breaking down use cases into small user-facing stories Sprint Review: A ceremony at the end of each sprint when completed stories are demonstrated to team, stakeholders, and users.
- Backlog Refinement: An ongoing team activity of collaboratively updating the Product Backlog via reprioritization, adding/deleting/rewriting stories, splitting, and estimating. This practice ensures that the backlog is always actionable. (Note: This practice was formerly known as “grooming”, which term is out of favor.)
- Transparency: The idea that information should be shared freely within and between all Agile teams, projects, and stakeholders.
- Iteration (Inspect and Adapt): A problem-solving and development approach that solves large problems by decomposing them into smaller, discrete problems which are each easier to solve, then solving the smaller problems. As each smaller problem is solved, new information is uncovered (Inspect) and decisions can be made and re-made based on the new information (Adapt).
- Potentially Shippable Product Increment: In Agile software development, a fully tested and usable version of a product that is produced at the end of each sprint.
- Self-organizing Teams with Empowered Product Owners: Agile teams are composed of peers who share ownership of the team’s work and decision-making processes. Self-organizing teams are given ownership of their work process, their commitments, and their approach to meeting their commitments. Product Owner is the role that represents the business and customer directly within the development team. The Product Owner must be empowered to make product decisions in response to feedback from stakeholders and customers. Taken together, a team has complete control over how it does its work and what work it does.