This content is currently in Alpha
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 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:
- As a … (who the user is)
- I want to …(what they need from the service)
- So that I can … (why they need it).
- “As an individual taxpayer I want to obtain my tax details online so that I can meet my obligations.”
- “As a tax agent, I want to see my client’s details online so that I can help them meet their obligations.”
- “As a tax officer, I want to know that the taxpayer has entered correct information so that I can correctly assess their tax return.”
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.
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.
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:
- Service / Product Manager - responsible for creating products or services that meet user needs
- Delivery / Project Manager (Scrum Master, in the scrum methodology) - the agile expert responsible for removing blockers and also the facilitator at team meetings
- team members - self-organising and multi-disciplinary staff that produce user stories, carry out the Product Manager’s vision and are responsible for estimation of their output and speed.
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 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:
- get the development and working environments set up
- agree to some of the design principles (such as, architecture, technical, product, interaction, content)
- prepare the product backlog (the workload) for the first sprint.
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.
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’.
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:
- re-sort tasks to ensure new higher priority items float to the top
- write or re-write descriptions of items so they are clear to the team
- agree or revisit the acceptance criteria for completion of items.
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.
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.
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.
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:
- What they worked on/produced yesterday.
- What they are working on today (and help they might need).
- What is stopping them from finishing a user story card (blockers).
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.
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:
- what went well
- what went badly
- how to improve the working environment or process for the next sprint/iteration/project.
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