This content is currently in Alpha

Agile

Iterative and user-centred design and development

Agile development is about iterating quickly to deliver value to your users. In contrast to traditional development methodologies like waterfall, agile development requires continuous delivery, improvement and feedback from users. The benefit is that teams can quickly adapt and align services with user needs in rapidly changing environments.

Agile practices don’t guarantee success: you can still fail, but failure should be treated as an opportunity to learn. The ideas of learning by doing, failing fast, and adapting and adjusting to changes are all core agile practices. The agile team should create and promote a culture that experiments and learns from failure. Don’t be afraid to assess, adjust and experiment with new ideas.

There are many agile tools, processes and methodologies, such as scrum or kanban. But working in an agile way does not mean just using a certain tool. Agile is a principle-based approach that requires a change in mindset with regard to how the project vision is created, right down to the way the team prioritises work and runs daily meetings.

Don’t be too intimidated by agile: it’s about bringing together your existing people (business owners, designers and technical developers) to work together in a different way. Pick something small and manageable to begin with, follow the principles, empower the team to solve problems during sprints, and ensure valuable releases through excellent quality assurance. There are plenty of great articles (for example why mixing development methodologies can be a bad idea) available and places to ask questions online.

We know the agile approach can be difficult in government and there are specific contexts where a more traditional project management approach may still be required (for example, on complex applications with critical functionality, and when co-location is not possible for teams).

We are working on making agile easier for agencies to use for service design. You can find out how the Australian Government Department of Finance’s Online Service Branch adopted agile to improve service delivery. If you can help or are willing to share your experience and expertise, please get in touch.

Why must I?

An agile approach is essential to producing high-quality services that both meet user needs and are of value to the user. Working agile helps the team to adapt quickly to user feedback, accurately estimate its speed and output, and encourages a culture that fails and recovers fast. That is, experimenting often and learning quickly from failures.

How do I?

User stories

User stories are a way to understand and capture your user needs. They are a fundamental user research tool for identifying stakeholders and context.

A user story is generally only a few sentences on a role, a need/feature and why:

Examples:

Once you have a collection of user stories that fit into the services’ overall objective you can use them to prioritise the team’s work into sprints.

Roadmap

Agile projects require you to plan in a different way from more traditional methodologies like waterfall. You need flexibility to accommodate on-going workload prioritisation and improvements in your team’s procedures, but still give a consistent pathway to achieving the overall goal of meeting your users’ needs.

The agile roadmap documents the high-level (big picture) vision for the service and should be accessed throughout the project to support prioritisation during sprint planning. Also to guide major changes in direction as you learn more about the project landscape. In addition, the roadmap can help stakeholders to understand and stay up-to-date with your project. You should display it in a place where the whole team can easily access it.

Never take for granted that the current roadmap is workable; make sure you review and revise it frequently. Detailed requirements may not be understood in the beginning nor can all changing and new requirements be predicted.

Agile teams

A good agile team will be motivated and self-organising and managing, cross-functional and co-located. They must be willing to act in an environment of uncertainty, rapid changes and ambiguity.

Generally, a small team of between 5 to 10 people are often more productive and predictable than larger teams. Your team must include specific members focused on the end users’ needs.

A fully functioning agile team is comprised of 3 kinds of roles:

Your team members should share knowledge and build partnerships based on openness, transparency, trust and mutual respect. They should be permitted to continuously improve, innovate and make mistakes but quickly learn from them!

If the team is new to agile (here’s 4 warning signs that a team is not agile) you may need to work on creating cultural change.

Sprints

Sprints are a fixed unit or stage of the team’s work (for example, 2 weeks). The sprint concept is central to scrum software development, but is used in other agile methodologies. Sprints aim to visualise progress for the target users and what’s delivered can be validated at the end of each sprint cycle. This allows the team to move iteratively toward the vision outlined in the roadmap, with opportunity for quick course correction. The flexibility of sprints enable the team to continuously add value through incremental improvement.

Sprints are generally used in work with key delivery timelines for releases. Other agile methodologies like kanban are intended for more reactive or ‘production line’ business-as-usual work, such as an IT service desk, and do not use sprints.

Each sprint has several iterations and a release plan. Generally, the team will use user stories to prioritise the backlog of tasks that will be carried out by each member in each sprint. The work must be made ready for assessment by the product owner against established success criteria. Each sprint should be of equal length, typically 2 weeks, however you can use longer or shorter sprints in your project in agreement with your sprint goals.

The process usually starts with a sprint planning event, in order to:

Backlog

Each sprint or unit of work draws on a backlog of prioritised user stories. A well maintained backlog supports an iterative development cycle by enabling the team to track progress at regular intervals, reflecting on what’s been learned and adjusting for future sprints.

Prioritising

Create a list of all the work items arising from user stories that need to be done to achieve the roadmap vision. This includes features, bugs, design tasks, technical tasks, administration tasks and research activities, but should be organised into simple user stories as much as possible.

Consider how you might do a small portion of tasks that could be validated with users, even if it is just a small part of the overall interaction. Focus on a single feature at a time. It can be tempting for team members to individually pursue a variety of different directions, but that makes it difficult to produce a cohesive product or service. Working together means that at the end of the effort, there is not only something to share with the project owner but also something concrete to test with users.

Anything that isn’t feasible for the team to work on should be kept in a separate place, where it can be returned to at the next sprint planning session. Some agile approaches refer to this list as the ‘icebox’.

Backlog grooming

User stories and supporting tasks, such as bugs, should be added to the backlog at any time. It’s important to regularly schedule refinements, or grooming, of the backlog to:

Continuous delivery

Continuous delivery is an important agile concept. Whether you are a using a sprint-based methodology like scrum to deliver software through stages; or using kanban to manage the day-to-day workload of a service desk, you will still be progressing through continuous cycles of planning, testing and release.

As you follow the service design and delivery process the team will be regularly alternating between development work and verifying that work with users. Each sprint, or unit of work, will produce a product and deployable code that can be tested with users. The next iteration will build on the previous one getting you closer to the vision outlined in the roadmap.

You should accelerate the feedback cycle: the smaller the feedback cycle (in days or weeks at most), the sooner you can act and readjust your course. The process begins with the agreement of acceptance criteria standards for each user story. You can either do this when you first write your user stories or later in the form of acceptance tests when you start development work.

Minimum viable product

Agile development requires discipline to incrementally deliver the things that will have a positive, visible impact for the users and being ready to adjust them if they are not right. To do this the team needs to verify the usability of the service with users as early as possible. A minimal viable product (MVP) supports this approach by proving an agreed level of the minimum work required before it can be tested with users.

By focusing on the MVP, the team avoids wasting time on work that doesn’t serve the user and avoiding the need for the work to be repeated later on. It also means you will have a working product or service you can test between sprints.

Designing tests

As the project is always changing, it requires different approaches to testing with different skills, tactics and tools. The team needs to agree on a consistent testing approach across all work issues that balances risks and user needs. Everyone should have responsibility for the product or service quality. They should be proactive if they see a problem with the quality to take action to fix it.

Development should be test-driven. Writing tests before you develop the feature means problems will be identified much earlier. If you write tests to a standard that makes them suitable for reuse throughout the project they will be the fastest possible confirmation that everything is as you expect - or that it isn’t and needs to be fixed.

Although testing is done both manually and through automation, the majority of your test efforts should be centred on automated tests, which should be written with the same care and accuracy as production code. These tests run in continuous integration, which means that they form part of your codebase – any changes to your code will trigger your tests. This way, the team will get immediate feedback on the quality of the code and it will help to prevent bugs happening at a later stage when they become complicated and expensive to resolve.

Agile meetings

Clear and frequent communication among the team is key to agile work. Regular focused meetings are part of this – in particular, brief daily team stand-ups. Other common reoccurring meetings include sprint planning and sprint reviews (in scrum), and retrospectives.

Daily stand-ups

Stand-ups are an opportunity for the team to discuss the progress of a project. They should last no more than 15 minutes and it is best to do them standing up in front of your project wall. This allows your team members to point at user story cards on the wall to keep things on topic.

Each member of your team should share:

Stand-ups meetings are not meant for solving issues. Instead, arrange a huddle after the stand-up to discuss the issues in a smaller group.

Sprint planning and reviews

The team should meet before and after each sprint. Prior to the sprint, the team prioritises the user stories in scope, the tasks required to complete them, and their acceptance criteria. After the sprint, the team members should confirm the completed work against the acceptance criteria. You can include stakeholders in this meeting to explain which user stories have and have not been completed and why.

Retrospectives

Reflective meetings following milestones are important opportunities to evaluate and continuously improve the team’s working process, progress, relationships and even code.

As a minimum, the team should hold retrospectives at the end of each sprint, sprint review, phase, iteration and the project.

A retrospective should cover:

This guide has been adapted from the UK Government Service Design Manual guides on Agile, What agile looks like and Features of agile under the Open Government Licence v2.0; the US Digital Services Playbook - Play 4: Build the service using agile and iterative practices; and 18F’s Agile Principles and Practices.

Last updated: 24 June 2016