A practical guide to scaling agile teams

With an agile work methodology we shift away from projects to an approach that’s focussed entirely on delivering the maximum increment of value in the minimum amount of time.

Our main objective is to eliminate waste by reducing time and effort spent working on things we don’t absolutely need; delivering 80% of the value in 20% of the time.

Sounds nice, but how?

Instead of working on full scope projects, we split and prioritise values we want to create in as-thin-slices-as possible; for example:

• “Cross-company Agile Implementation”

Can be broken down into a Who, What, and Why:

• A member across any team should be able to read the agile best practices and FAQ so they can refer back to it or submit comments if something is unclear.
• A member of the leadership team should be able to view how the backlog works in practice with their submitted projects add into the backlog so we can run a refinement session together.
• …

In contrary to a project driven approach, values are split in to small actionable slices, making it possible to prioritise, or even eliminate, them. To make manage this process we use the backlog.

Each team has it’s own backlog and is in charge of defining the backlog items (Aka. Values or Stories).

Note: I use Values, Stories, and Backlog Items interchangeably but they carry the same meaning. Values are encaptured within Stories that describe the Who, What, and Why.

When defining these values its important that they aren’t treated as sub-tasks but as complete increments of values, this way you’ll be able to deliver value every step of the way while maintaining maximum flexibility to make changes to items not yet started — without wasting previous efforts.

Sounds great, but who’s going to do this?

In our implementation of agile everyone is on “scrum team” that consist of 3 roles:

1. Product Owner
2. Team
3. Scrum Master

Product owner

Product owners are in charge the backlog, their main responsibility is to prepare, prioritise and verify the values are as clear as possible. This process includes research, speaking to stakeholders, and running backlog refinement sessions together with the team.

Team members

Teams work together in cycles on values they’ve accepted to deliver within a giving cycle; two weeks for example. Whereas the Product Owner is in charge of the backlog, the Team is in charge of the backlog items with a Cycle (Aka. Sprint). Even though teams are comprised of members with different specialities, it’s the team’s collective responsibility to get everything 100% completed according to the agreed upon Acceptance Criteria.

Scrum master

While the Product owner focusses on the backlog and the Team on the current sprint, the Scrum master coordinates the process; setting up daily stand up meetings, plans backlog refinement meetings, protects the team from interruptions, and is constantly looking for ways to improve the efficiency of the process. The Scrum master is not involved with what is done, strictly focussing only how we do it — with the goal to continuously increase the Team’s velocity.

How will we know when the Deadlines are?

Each sprint contains a full value cycle; moving items from Todo to Done with all the necessary stages in between.

Values are delivered according to the acceptance criteria at the end of each cycle, which in essence is the deadline for whatever is planned.

With Agile we focus on velocity, not deadlines - where the team and scrum master constantly seek to uncover ways to increase their velocity during a cycle.

Gotcha… but how do we approach large values that can’t be completed within a cycle?

As rule of thumb any item on the backlog should be no larger than 1/6th of a cycle’s total capacity. Values that can’t be completed within a cycle indicate they need to be analysed further and split into independently deliverable values before the team can accept the task.

There are 6 key criteria (INVEST) for any backlog item before it can be actioned upon:

1. Is the story Independent and sufficiently self-contained that it can be prioritised without dependencies?
2. Are the details for the story Negotiable in such a way there's room for simplifying how it's implemented?
3. Does the story add Value for a customer or team member?
4. Is the story detailed enough to properly Estimate?
5. Is the story Small enough to fit 6 - 10 of these stories into a sprint?
6. Is there a way to Test the story to against it's acceptance criteria and concretely mark it as completed?

This is where the art of the backlog refinement process comes in; the top priority of any product owner os splitting stories in ways they maximise value.

There are many patterns to split stories so they can split to meet the INVEST criteria and be improved over time, for example:

• Does the story describe a workflow of multiple steps?
• Does the story include multiple operations?
• Does the story contain multiple variables?
• Does the story do the same thing to different kinds of data? Can we do one part first?
• Does the story have a complex interface?
• ...

There are countless variations to split stories so they maintain value. How it is done will depend on a variety of factors, such as; preferences of the Product Owner and Team and wether Stories are technical, operational, or of a different nature.

Isn’t this for Product development only?

Although agile methodologies are widely used within software development and production lines, they can be adapted to any type of team:

• In leadership, a cycle could be four weeks to define which values we want to implement for the company, and their backlog items might primarily consist of enabling other teams: for example: A product owner should be briefed about the importance of incorporating the third-party AI tool offer by Copylime within the Bnberry onboarding wizard to generate content automatically and reduce time lost waiting for copywriters.
• In sales, a cycle could be 12 weeks that defines which leads/deals will we worked upon, and the backlog could be the leads that have the highest upcoming priority for the next cycles.
• In support, planning could be daily, with a backlog of tickets, and a quick daily scrum meeting to discuss completed, open tickets, or things that might be causing impediments.
• In account management, cycles could be 2 weeks to schedule which accounts need to be onboarded, and contracts that need to be extended.
• …

This makes sense on a team-level, but what if there are multiple teams?

For optimal communication, everyone is on a scrum team no larger than 7 people. To scale this scrums can be chained, where each layer is also a scrum team; comprised of Product Owners, for example:

The Leadership team’s Product Owner could be the CEO, and the team could be comprised of:

• Product PO
• Operations PO
• Account management PO
• Finance PO
• Sales PO
• Marketing PO

This process repeats itself to break-down the entire organisation into teams of maximum 7 members:

The Product team’s Product Owner could the Head of Product, and the team could be comprised of:

• Distributions PO
• Inventory PO
• Listings PO

The Sales team

• Sales US PO
• Sales EU PO
• Onboarding PO
• Renewals PO
• …

Who manages everything that’s in progress?

In general each team layer aims to coordinate prioritise and enable the teams “below” it. In agile there’s no manager; each team manages itself, delivers value in cycles, and organises according to their backlog.

How do we keep everyone’s backlog aligned?

Since every team has their own backlog that’s managed by a Product Owner who in turn is on a team of Product Owners, who also have a backlog, everything stays aligned.

Here’s a practical example:

• The Leadership team might prioritise several values, for example, A product owner should be briefed to prepare an AI listing creation tool to increase onboarding of new hotels
• The Product CPO, who’s on the leadership team, is likely to pick up this story, and will refine and prioritise this backlog item with the Product team, which is comprised of on the Distributions PO, Inventory PO, Listings PO.
• The Listings PO, who’s on the product team, is likely to pick up this story, and further refine it with the Listings team.

This process leads to atomic precision, and enables teams to execute at speeds not possible before because this process would generally only begin once the task gets assigned.

What happens if a team isn’t able to fully complete a backlog item?

In the same way that values need to be slices of full independent value, teams need to be equipped with all the necessary skills to be fully self-sufficient within their area of responsibility.

Conceptually agile teams are structured similarly to Navy SEAL teams. Because SEAL teams need to be able to function as independent units they need to have all the necessary expertise for their mission on the team; structured in 8-man squads comprised with all the skills required.

Who is responsible if some items aren’t completed?

If the sprint fails, the WHOLE team fails. Simple as that. It’s doesn’t matter to who the task was assigned because, just like a SEAL team, completing a part of the value means it’s not completed.

In agile, rewards and responsibilities are team based, with only specific “key conversion” rewards for individuals to stimulate action depending on market demands; for example, contract renewals.

The dynamic we want to create is a team that collectively moved all the sprint items to done, just like a scrum team in Rugby would move the ball across the field.

But what do I do if a task gets stuck outside of my control?

How many times have you discovered something was made unnecessarily difficult only at the end after it was too late? To uncover these issues each scrum team has a quick daily stand-up  meeting to run through:

1. What did you do yesterday to help the team finish the Sprint?
2. What will you do today to help the team finish the Sprint?
3. What obstacles are getting in the team’s way?”

What happens when sudden changes are requested by my manager?

In agile there’s no manager and adding items to a sprint is not allowed, the scrum master safeguards this process. In extreme cases the Product Owner has the power to initiate a Sprint Re-planning session, this means that some or all items from the current sprint backlog will be replaced in order to address the urgent matter.

Scenarios when this occurs will vary per team, for example:

• For development teams it might be an urgent bug
• For sales teams it might be a sudden major opportunity
• For operations teams it might be an urgent high value customer request
• For finance it might an unexpected blocking of a bank account
• …

How do we keep everything organised?

The first rule is: If it’s not in the backlog, it does not exist. In all cases everything needs to be in the backlog, never work on items that are not in the backlog.

The second rule is: only discuss what is in the backlog. Notes, comments, documents, files, and everything else must be attached to the relevant backlog item.

What happens if we get new ideas or learn something?

Anyone can add to the backlog, team members included, these items can then be processed during the next Backlog refinement meeting.

Every item a scrum team works on goes through the following cycle:

1. Backlog An item of value is added to the bottom of backlog specifying the Who, What, Why
2. Requires Clarification The items need to be specified further will information, resources, ideas, etc.
3. Under Consideration Once the item is clarified, it can be brought up during the backlog refinement meeting, a 2-hour time-boxed session held by teams every week discussing and “refining” future work.
4. Todo During the backlog refinement session the item is discussed, split, estimated, and prioritised. This meeting is solely for the product owner to gather feedback from the team, and might decide to change the priority again at anytime.

What happens if we need several specific team members to coordinate across multiple teams?

Team members who require cross-team coordination are structured very similarly to scrum teams, via something called the MetaScrum. These teams can have daily, weekly, monthly, or even quarterly meetings with each other.

The only difference is that MetaScrum teams generally do not have a backlog, instead they work together to discuss whatever items the MetaScrum is about - in turn the MetaScrum team members use this meeting to refine their backlog, for example; a MetaScrum team could be formed by the most senior leaders of each team.

There are a large variety of MetaScrums that could be setup, and team members are free to setup as many MetaScrums as they like. The only criteria being that they must never be scheduled ad hoc, they need to be planned upfront, and scheduled periodically at an agreed upon time with all the MetaScrum attendees — to avoid disruption of the sprint cycles.

If you have any questions or want to share your experience with scaling scrum, please don't hesitate to reach out! You can contact me via Twitter below.