A beginner’s guide to Agile in the B.C. government
This guide provides a flexible introduction to Agile and how it can be adapted for different contexts.
Last updated on
Agile 101
Agile focuses on collaboration, customer feedback and ongoing improvement. It’s a mindset and set of practices that helps teams break down big tasks into smaller, manageable pieces called iterations.
Teams work closely with customers as they develop a product or service and can adjust their work based on frequent feedback.
While they originated in software development, Agile practices can help teams of all kinds. The goal is to deliver a high-value, high-quality product quickly, while reducing waste.
History of Agile
Many people think Agile software development began with a 2001 meeting where the term was first used. However, the practices we now call “Agile” started much earlier than that.
Iteration of Agile practices
In the mid-1990s, various professionals involved in developing software products realized their current methods weren’t working. They began experimenting and blending old and new approaches to find solutions to common software development issues. When they found a combination that worked, they created a set of methods for their team to reference.
These methods focused on:
- Close teamwork with business partners
- Delivering useful results frequently
- Having self-organizing teams
- Efficient coding practices
The set of methods that became successful informed new and existing frameworks. Popular examples include:
- Scrum, which focuses on iterative progress through time-boxed sprints
- Kanban, which relies on visual tasks to manage workflows
- Extreme Programming (XP), which prioritizes high-quality software with frequent releases and continuous testing
- Feature-Driven Development (FDD), which prioritizes customer input to build and deliver features
- Dynamic Systems Development Method (DSDM), which centres on iterative and incremental development with strict time and budget constraints
How Agile hit the mainstream
In February 2001, different framework representatives met to discuss their unique approaches. Despite their differences, they agreed on core values and the need to name the umbrella under which they operate. This resulted in a document called the Agile Manifesto.
Understanding the Agile Manifesto
The Agile Manifesto is made up of 4 foundational values and 12 supporting principles which lead the Agile approach. Values are the core beliefs, while principles are the guidelines for implementing those beliefs.
The 4 Agile values
The Agile mentality has 4 overarching values that set it apart from traditional software development processes. This includes:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The 12 Agile principles
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
- Business people and developers must work together daily throughout the project
- Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
- Working software is the primary measure of progress
- Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely
- Continuous attention to technical excellence and good design enhances agility
- Simplicity — the art of maximizing the amount of work not done — is essential
- The best architectures, requirements and designs emerge from self-organizing teams
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Agile in our workplace
Agile’s focus on people and flexibility has made it widely popular. It’s now used beyond software development teams and can benefit different areas of work to improve collaboration, productivity and adaptability.
Many teams in the B.C. government are adopting Agile practices
In the past, most projects used the waterfall project management methodology. Tasks were completed step-by-step from one phase to the next, on the way to a major product or service launch.
This approach works well for simple, well-defined projects.
Agile helps in more complex problem spaces. It allows teams to uncover accurate needs and change direction through continuous learning.
Choosing between Agile and waterfall project management
Before you start a new project, it’s important to understand the conditions of the work. These include things like scope, resources and the time available to you.
Waterfall
Waterfall is traditionally used for projects that:
- Have a defined scope (The end result is clearly established from the beginning of the project)
- Must meet strict regulations or require approval at each stage of work
- Have a set budget
- Require detailed documentation and reporting
Waterfall projects often start development only after the scope is written down.
Agile
Agile complements projects that:
- Need to include the customer (people) in the design and development process
- Have an undefined solution
- Need to launch a simple version of a product or service and can continually improve on it in the future
Agile has frameworks, such as Scrum, that work well for complex problems because they’re flexible, ongoing and nonlinear.
In complex problem spaces, it’s hard to define the full scope upfront since learning is required through testing, prototypes and customer feedback.
This approach can lead to great success in a government setting. Securing dedicated resources and executive support is key to achieving this success.
Understanding the Minimum Viable Product (MVP)
An MVP is a concept from Agile that refers to the simplest form of a new product or service. It includes just enough features to meet the basic needs of customers.
It’s launched with the goal to quickly test it with real users. The feedback provided from the users then helps responsible teams understand what works, what doesn’t, what to plan for and how to improve.
This can help teams save time and resources.
B.C. government teams often apply the Scrum framework when using Agile
There are various Agile frameworks a team may choose depending on their needs.
In the B.C. government, the Scrum framework is a common and supported way to use Agile practices.
Scrum definitions
Scrum uses its own unique language to signal how it differs from traditional project management.
Sprint: A sprint is a time-boxed iteration, typically lasting 1 to 4 weeks. The team focuses on delivering a valuable increment of work during this period.
Product backlog: A dynamic collection of outcomes and tasks sorted by priorities that describe the deliverable, requirements, improvements and fixes needed to achieve each outcome. They can be tracked with a low-tech solution such as a whiteboard or through an online software application that your ministry gets a license for.
Sprint planning: A meeting where the team selects tasks from the product backlog to complete during the upcoming sprint.
Daily huddle (stand-up): A short, daily meeting for the team to synchronize activities, discuss progress and identify any obstacles.
Sprint review/demo: A working meeting where the team presents their completed work and asks for feedback and guidance. Ideally, the end user or key partner is present.
Sprint retrospective (retro): A reflection session where the team discusses what went well, what could be improved and identifies actions to enhance their processes in the next sprint.
Members of a software Scrum team and their responsibilities
Scrum teams are cross-functional. This means they consist of members with various skills and expertise.
A software development team will typically have around 10 people and will consist of 3 specific roles:
- A product owner, who provides guidance to the team on the product value, goal and vision based on business requirements
- A Scrum master, who facilitates meetings and removes obstacles through process improvements
- The development team, who builds the product or service. This can include roles like software developers, content designers, database administrators, service designers, business analysts and more
How to adopt Agile as a non-software team
Agile practices have been adopted by many different disciplines like policy teams, finance teams, communications teams and more.
Examples of projects that could benefit from Agile include:
- In-person service teams who are seeking to improve customer interactions
- Human resource teams who’d like to enhance recruitment and onboarding processes
- Educational program teams who design and refine curricula based on student performance and feedback
These teams may still include a product owner, a Scrum master (if working in Scrum) and a development team. But the sprint work would be handled by a combination of researchers, policy analysts, outreach specialists and other experts needed for the product or service.
How to build a team
There are courses you can take to learn more about Agile in government.
If you have questions about hiring for Agile or technical roles, contact the Digital Talent team.
For questions about structuring a team, or to find coaching and consulting, contact the Lab Services team.
You don’t need a team to start trying Agile practices. Introducing small, lightweight changes to your work is the first step. Join the Agile Community of Practice to connect and learn from other BC Public Service employees.