How To Split a Scrum Team: Creating New Teams at FQ
Last year, Christopher Ngo had a post about going through a scrum team split from the perspective of an engineer. This post is a step-by-step internal process we generally use and iterate upon to split scrum teams with goals of stability, decoupling, and early success in mind. As with most documentation – your mileage may vary, and there may be adjustments for your teams and company.
The Problem
We generally split new scrum teams from existing ones at FloQast R&D when:
- The current team’s backlog is a about a year or more
- We want to get to those backlog items sooner than later
Moving teams can be a jarring experience for the team members, so we consider the movement carefully. If poorly done, it can cause team instability, tightly coupled codebases, and an extended storming period without delivering for our customers.
Assumptions
- At FloQast, most of our engineering scrum teams have 2-4 full-stack software engineers and a quality engineer per team, and their work is also full-stack. There are a few scrum teams that are mostly backend or mostly frontend.
- In addition to people management and technical guidance, our Engineering Managers also act as Agile/Scrum leads
- Much of this post also assumes that we are talking about a team with a lengthy roadmap instead of a new experimental team where we validate a unique customer opportunity. For those teams, you can skip the first two or three steps.
(This Is) How We Do It 🎵
Steps
- Find the data boundaries
- Define a roadmap
- Self-organizing teams
- Team kickoff
- Delivery in Sprint 1
👩🏽💻 Data Boundaries
Goal: Creating a focused domain for a team boils down to finding the boundaries that meet our current and future customer needs.
What: Look at the epics for the team, and find boundaries of which future roadmap belongs on Team 1 vs. Team 2, based on the data, codebases, features, and epics.
Who: Pod-level leadership (Product Manager, Engineering Manager, Tech Lead if applicable)
Output: Clear understanding of the data and product domains a new team will be responsible for and any shared boundaries with other teams.
🛣️ Define a Roadmap
Goal: By understanding the product and data boundaries, Pod Leadership can vet the high-level initiatives the team will work on for the next six months or more.
What: Based on the domain exercise, ensure a 4-6+ month roadmap for each team. Having a sustainable roadmap reduces the instability/stress of an unhealthy team backlog. If there isn’t a long-enough roadmap, this is an opportunity to consider if we need to create a new team at all or if, instead, we should prioritize specific initiatives differently in Team 1. Once epics are split out, take a look at the roadmaps. Is one team balanced heavily while the other’s is light? Are there areas where the teams will work in the same codebases? How could we reduce that? Does each team generally look full-stack in its domain? If not, does that impact hiring/recruiting for the team?
Who: Pod-level leadership (Product Manager, Engineering Manager)
Output: High-level epics for two teams
🧠 Self-Organizing Teams
Goal: The domains and roadmap are getting more apparent, but who will be on the team is still TBD. Let’s clarify.
What: The EM/PM presents the roadmap and upcoming team split to the team. The EM mentions that throughout upcoming 1:1s, they ask for each team member’s preference and try to accommodate as best they can for the upcoming split. The EM puts together the groupings with the EM’s manager to finalize team staffing.
What happens if everyone picks Team A? That’s where the EM will try their best to meet both the organization’s and the engineer’s needs and share the outcome transparently.
Who: Engineering Manager
Output: A document that gathers each team member’s preference on which team they would like to join, with criteria (personnel skills plus alignment of the roadmap, etc.)
Note: Using a document like this is ideal, but it may sometimes not work out. Lean towards transparency as early as possible to reduce surprises.
🤝 Team 2 Kickoff
Goal: Now that we have the why, the what, and the who – we form the new team.
What: The EM notifies people which team they are on, and when the new team will begin. Pod Level leadership begins to collate the North Star and Quarterly goals. The EM sets up a Team Kickoff meeting with the new team members, where the group reviews the team’s north star quarterly goal. They also build the working agreement and a team name.
Team Name
At FloQast, most of our team names are moons. (Long story 😂) The EM guides the team through a team values and naming exercise. The reason is that each team has strengths that make it unique, and the values become a shared understanding.
Team Charter
A team charter is the north star for a team, and it also acts as an opportunity to differentiate how this team is different from another team’s work. The roles and responsibilities section is from a Lara Hogan book many of our Engineering Managers read.
Team Working Agreement
The new team members build this document together. People work with each other in various ways – and getting everyone on the same page helps the team gel faster.
The PM generally guides the Team Vision, and then the EM takes over the roles and responsibilities and team working agreement discussion.
Who: PM/Engineering Manager
Output:
- Team Confluence Page (with all the above info)
- Slack user group with new team name
- Jira epic and sprint boards
- Jira Automation
- Schema ownership changes and repo ownership changes as applicable to the new team.
- Notify various slack channels for new Pod Setup
🏃🏻♂️ Delivery in Sprint 1
Goal: We now have the why, the what, and the who – the macro team can start to fracture and finish up any remaining work.
What: At this point, the members of Team 1 and Team 2 work together in Team 1’s sprint on a Discovery Card. The entire group works through an upcoming epic for Team 2, to understand the shared data boundaries and work. At the end of this, tickets are ready for Team 2 to deploy to production in their first sprint.
Who: Engineering Manager
Output: New sprints with the two new teams are started, with clear sprint goals, and a summary of the new team is announced in our main engineering Slack channel. A new team is ready to go!
Vinoj Zacharia
Vinoj Zacharia is a developer turned engineering leader who leads with empathy to build data-driven, empowered, collaborative teams from the ground-up. He is a Director of Engineering at FloQast.
Back to Blog