Being agile in the Ontario Public Service
Learn about Agile principles and methods to help you build user-centred services and meet the Digital Service Standard.
On this page Skip this page navigation
What is Agile
Agile is a way of working.
A team applying Agile methods to their work will:
- build a product or service quickly
- test what they’ve built
- iterate their work and their processes based on regular feedback
Meeting the Digital Service Standard
Use the Agile approach to manage your work when you build and run government digital services in Ontario. This is to meet the Digital Service Standard.
Agile is also useful when designing policy and programs.
Working in Agile
Work in Agile to:
- empower small teams of experts to solve problems and build things
- focus on users and prioritize delivering value to users quickly and repeatedly
- mitigate risk on an ongoing basis throughout development, not just during planning
- use feedback loops, both qualitative and quantitative, to improve product and process
- use coordinated teams of teams to do all the above
Differences between traditional and Agile methods
Agile can be very different for people used to traditional waterfall methods for management.
Here are the differences.
|Agile methods||Traditional methods|
|Work in iterations||Work in phases|
|Produce incremental value||Build it all in one shot|
|Mitigate risks throughout||Mitigate risks upfront|
|User and product-focused||Organization and project-focused|
|Empower teams of experts||Direct teams to follow a (dictated) plan|
|Measures constantly, adapts in response to data||Uses data to plan, measures after launch|
The Agile approach
You do similar things to the waterfall approach, like gathering requirements, planning, designing, building and testing. However, you do this all at the same time.
You research, prototype, 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 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
The waterfall approach is necessary and suited to building things like bridges and buildings. It’s less effective for building and running services when people’s needs and expectations are constantly changing and are being influenced by rapid technology changes.
Bridges and buildings have well understood material needs, strict building codes to follow, and can have predictable costs up-front. Software has none of these characteristics.
Government services also need to be able to respond quickly to policy and social change.
Using waterfall methods means you may spend six months planning and 18 months building a service that doesn’t meet user’s needs, reflects outdated government policy, and can’t work with the latest technology.
Agile methods allow you to quickly make any changes while you’re building the service, and also when it’s live and being used by people.
To follow the Digital Service Standard you must build and run your service using Agile methods.
There are different Agile methods you can use, but you should always follow the five core principles of:
- focus on user needs
- deliver iteratively
- keep improving how your team works
- fail fast and learn quickly
- keep planning
1. Focus on user needs
Agile is about constantly putting your users first. You must prioritise their needs over everyone else’s, including those of your senior stakeholders.
Why user needs matter
If you start building your service before you understand who your users are and what they need the service to do, you risk:
- building something that nobody needs or wants
- trying to solve problems that aren’t important to users
You need to ask for your users’ feedback early and often, and listen to them, especially when they tell you things you disagree with or don’t want to hear.
You should always use data from real people who are using your service and let it influence the direction of your project.
2. Keep improving your service
To work in an Agile way, you must continuously improve your service and its features. This is called “iterating.”
Every service is different, and building a service is a process which involves a lot of decisions made over time.
In general, follow these steps:
- Understand what your user’s needs are by conducting user research.
- Build something that meets the need that’s most important to your users.
- Show it to your users, listen to their feedback and improve it.
- Repeat this process to meet the next most important user need.
Agile is about making the complex process of building a digital service as simple as possible. It’s based on improving what you do day-by-day and week-by-week.
Why you need to keep improving your service
The process of producing incremental, production-ready features allows you to:
- give value to your users and stakeholders regularly
- shorten feedback loops that could be longer if using a waterfall methodology (where you only seek feedback when the final product is complete)
- decide the features you want to add next
- spend time creating features that your users care about
3. Keep improving how your team works
As well as improving your service gradually by talking to your users, talk to your team to keep improving the way they work.
This is so that the:
- team learns and improves throughout the life of your service
- quality of your service improves, saving you save time, effort and money
Find out what’s not working
Talk to your team to find out what’s working and what needs to be improved. You can do this at your team’s daily standup or regular retrospectives.
You should try to discover:
- any problems the team is having with any part of the work
- anything that’s stopping the team getting work done or delaying work
- any problems individual people have
Fix the problems
Once you’ve found problems for your team, you should agree on a way to fix them.
Use standups and retrospectives to see if what you did fixed problems the team talked about at previous meetings.
4. Fail fast, learn quickly
Agile techniques don’t guarantee success, but you don’t have to be afraid to fail or experiment. Agile allows you to spot problems early and resolve them quickly.
You should learn to fail and create a culture that learns from failure.
You can prevent major issues or failures from happening by:
- demonstrating value to your senior stakeholders (for example, Assistant Deputy Ministers, directors, or other decision makers) with regular releases
- releasing regularly to prevent creating a “too-big-to-fail” service that shouldn’t be released, but must be released anyway because of how much has been invested prior to release
- using processes like test-driven development and automated testing (writing tests before you develop the features to be tested) to highlight issues with quality early on
- identifying important metrics, establishing a baseline and monitoring for changes throughout the project
Regularly releasing and testing small features with your users:
- improves quality
- improves visibility
- reduces cost
5. Keep planning
In an Agile project, you should continuously plan based on data and usage patterns from the service you’re working on.
Your team should plan together and review these plans regularly based on:
- your progress
- any new facts and requirements
An introduction to Agile methods
There are many Agile methods you can use when building your service. Each has its own set of tools and techniques.
This guide introduces the two most popular Agile methods:
Scrum is the most commonly used Agile method.
It allows a highly structured model with clearly defined roles and responsibilities. This can be particularly useful for traditionally structured organisations that are moving to Agile.
Scrum is a good starting point if your team is new to Agile working.
Your team will generally find Scrum most useful when you’re:
- building a new product or service
- enhancing existing features
- adding new features in each ‘sprint’ (a fixed period of time)
When you’re running your live service and have urgent requests you may find sprints constraining and want to move to a flow-based method like Kanban.
But you can still keep using many of the activities associated with Scrum, like daily standup meetings, retrospectives and regular reviews of progress.
Lean-Kanban as a development method was inspired by production systems that focus on reducing waste and improving quality, like those created by Toyota.
Kanban is a way of visualising and improving your current working practices so that work flows through a system quickly.
A fast and smooth flow of work means you can:
- deliver value quickly and predictably
- get early feedback to find out whether your product or service is meeting user needs
The principles of Lean helps your team focus on:
- reducing waste
- delivering quickly
- learning and improving
- using evidence and data to make decisions
Kanban helps your team to:
- find the bottlenecks in your processes
- control the amount of work you’re doing
- predict your output based on actual delivery
It’s particularly useful at times when your team is operating a product or service and needs to react quickly to changing priorities. Applying Lean methods allows your team to focus on learning as quickly as possible, finding the most efficient ways to deliver value to your customers.
Read the following to learn more about Lean-Kanban:
Working with multiple Agile methods
You don’t have to work with just one method. You can choose tools and techniques from several to meet your team’s needs.
Each method has its own language for describing basic tools and techniques. The important thing is to understand:
- why you’ve chosen a tool or technique
- its Agile objective
In general, especially when starting out with implementing Agile methods, it is better to pick either Scrum or Lean-Kanban and follow the methods in a prescriptive fashion.
You can begin customizing your approach using multiple Agile methods once your Agile team has been established and can show that they are following the core principles.