Working on an Agile team

Agile 101

“Agile” is a discipline that emphasizes collaboration and customer feedback. It’s a mindset and wide set of practices that helps teams break down big tasks into smaller, manageable pieces called iterations.

It’s founded upon the Lean mindset and methodology.

Teams work closely with customers (people) as they develop a service and can flexibly adjust what is delivered based on frequent feedback. The goal is to deliver a high-value and high-quality product quickly, while reducing waste in the process.

History of Agile

The original Agile methodology was created in the early 2000s in response to the limitations of traditional software development approaches. The creators wanted to address common challenges like inflexible plans, long development cycles and difficulty adapting to changes, while promoting a more iterative and collaborative approach to software development. 

They believed that prioritizing individuals and interactions, functional software, customer collaboration and adaptation to change could improve efficiency and responsiveness.

• Read the original Agile manifesto

This focus on people and flexibility has made Agile widely popular, and it’s no longer only used by software development teams.

Agile in practice

People may use the word “Agile” in a variety of contexts, so it’s important to confirm what people mean when they say they are “Agile.” They might be referring to specific methods of work, or speaking about their team’s general practice.

Regardless, there are common, core values that underpin Agile ways of working and align with the Digital Code of Practice.

Collaboration and communication

• An emphasis on frequent collaboration and open communication among team members 
• Face-to-face interactions and regular updates 

Flexibility and adaptability

• Prioritizing iterative development, allowing for continuous improvement 
• Ability to adjust project goals and requirements as needed 

Human focus

• People at the center of the development process 
• Regular feedback from customers and stakeholders, allowing teams to deliver value and address their needs effectively 

Empowered and self-organized teams

• Self-organizing teams that have the authority to make decisions and take ownership of their work 
• Fosters creativity, innovation and accountability. Leads to higher productivity and better results

The value of a Minimum Viable Product (MVP)

An MVP is the simplest form of a new product or service. It includes only the necessary features to meet the basic needs of users.

Rather than requiring a full, long-term plan to deliver all the value imagined, Agile teams focus on an MVP.

The goal of an MVP is to test and validate an idea quickly, allowing teams to make improvements based on real user feedback. By concentrating on essential functions, teams can save time and resources in the initial development stage.

A roadmap of anticipated features and the related backlog of future work becomes more clear and refined once the team learns from people using the service.

---

Agile method: Scrum

There are various Agile methods a team may choose to use. In the B.C. government, the Scrum framework is a common and supported approach to applying Agile mindset and practices.

The language of Scrum is unique and signals how the approach is different from more traditional project management.

Understand Scrum and sprints

Scrum helps teams manage and organize projects or products by using small, focused work periods called “sprints” to make progress in iterations.

A sprint is a time-boxed iteration in Scrum, typically lasting 1 to 4 weeks, where the team focuses on delivering a valuable increment of work. 

A sprint begins with sprint planning, where the team selects and commits to a set of tasks from the product backlog to complete during the sprint. 

During the sprint, the team collaborates to develop and test the selected work items. That could mean testing new code, showing a new draft of policy to decision-makers or getting a design for a new website or poster approved.

Product backlog

A product backlog helps the team stay organized, focusing on what needs to be tackled next to meet the overall goals of the project.

The backlog lists all the features, improvements and tasks that need to be done for a project. Scrum teams use it to set priorities so high-value tasks can be worked on first.

The product backlog is dynamic, evolving as the service development (project) progresses. Often new items are added and priorities get adjusted (this is especially common in government). You may even decide to remove or deprioritize items.

How to track your product backlog

You can track a product backlog with low-tech solutions like a whiteboard or a stack of sticky notes, but there are many online tools built specifically for Scrum teams. These are often Software as a Service (SaaS) tools that your team or ministry can get a license for.  

We recommend connecting with the SaaS adoption team to learn about your options.

Get to know the Scrum ceremonies (events)

Sprint planning 

A meeting where the team determines the work to be done in the upcoming sprint and sets a sprint goal. 

Daily stand-up 

A daily short meeting for the team to synchronize their activities, discuss progress and identify any obstacles. 

Sprint review/demo 

A meeting to present the work completed during the sprint and collect feedback for further improvements. 

Sprint retrospective (The 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.

Agile or waterfall project management

In the past, most B.C. government projects used the waterfall project management methodology. Tasks are completed step-by-step, moving from one phase to the next without revisiting previous stages.

While this approach still works for simple, well-defined projects, it’s not designed for more complex problems. To solve those complex problems, the B.C. government has started adopting Agile practices.

How to decide if Agile or waterfall is best for your project

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 useful 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.

If you’re not sure if waterfall is the right choice for your project, focus on the scope. If there’s very little guess work involved in determining the scope, there’s a good chance it’s not a complex problem to solve for and waterfall is appropriate.

Agile

Agile is useful for projects that:

• Need or want to include the customer (people) in the design and development process
• Have an undefined end result
• Need to launch an MVP and can continually improve on it in future sprints

Agile is more adaptable to complex problem spaces, as it’s not linear. The planning happens continuously, from short-term sprints for the team, to mid-term objectives and longer-term roadmaps.

In complex problem spaces, scope is nearly impossible to determine because no real learning happens until you test your ideas, prototypes or MVP. And launching an MVP allows Agile teams to uncover the needs of the customer and change direction as needed.

Sometimes the Agile approach can be scary in a government setting. Getting the support of your executive is key to achieving success.

Teams working on technical products

Scrum teams working on software and product development are the most common Agile users. Most widely available resources about Agile practices, tools and education are focused on technical teams.

These teams usually include:

• A product owner
  • Responsible for guiding the team based on business and technical requirements. Works with the team to escalate concerns and negotiate trade-offs as needed 

• A Scrum master
  • Facilitates Scrum ceremonies and removes obstacles slowing the team’s progress, promoting self-organization, collaboration and adherence to Agile principles

• Developers
  • Implement changes according to sprint plans, and regularly report their progress
  • Depending on the type of team, this role can include software developers (front-end, back-end and full-stack), UX/UI designers, service designers (who research issues and consider the impact on end users), testers and auditors

Agile for policy, design, communications and more

Agile methods can also be adopted for less technically-focused projects, like a new in-person service or an online content refresh. More and more government teams are now tackling improvements to their product, policy or service using this approach.  

These teams may still include a product owner, a Scrum master if working in Scrum, and often developers and designers. 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. They would also collaborate with people and teams like marketing and communications, community organizations, external contractors and the public.

Some government projects might take a “hybrid” approach, using Agile methods whenever possible while tracking some components traditionally where ministry processes require it. For example, your branch could manage the development and ongoing support of a new application with Agile methods, but use traditional methods to plan the application launch event since it requires a set date.

Get help building 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.