Scrum Team has grown too large, how should it be split

Question

The insurance company for which I work has had an ongoing software development project for the last several years, which has been split between multiple lines.

1. software package:
   The suite we are using is broken up between several major packages, they are independent, but tied to each other, each with it's own domain: one for billing, one for claims, one for policies, and one for contacts each package is managed separately and is broken down further by line of business.
2. Line Of Business:
   We essentially have 3 lines of business, and we have been rolling out each line of business individually. The teams are broken down one step further; they are broken down by type of work.

3. Type Of Work:
   We have split up the type of work based on integration between packages, configuration of an individual package, and document generation.

   These splits aren't universal, for example on the first line of business, which we have already rolled out, we never had an integration team to my knowledge (this project was started prior to my involvement to the team).

   The issue that we have ran into, is that we have rolled out 2 of the 3 lines of business and after we did this, we merged the scrum teams from those lines of business together for one of the software packages. This means that where we had 4 individual scrum teams, we now have 1. Obviously, this was a mistake; and now our scrum master is overwhelmed, scrum meetings are only relevant to a subset of those in attendance, and take too long leading to people not paying attention.

   So, now moving forward, there has been some push back to break this MEGA-TEAM back down into it's previous component parts, at least partially owing to the fact that much of the granularization that was done prior to taking line of business 2 live is finished, and the line between configuration and integration is much messier. We have been discussing how to proceed, but there has been a deafening silence on the part of most people when it is brought up.

   To give one an idea of the scope of the problem, aforementioned MEGA-TEAM is about 35 people, and if we split it back the way we had it, several key people would, by necessity, end up on multiple teams. Furthermore if we split it back the way it was, our teams would still be bigger than an ideal team size, but the more we split them, the more personnel sharing would be necessary. Which could eventually end up with all of our time being spent in meetings.

   How do we proceed? How do we decide where to draw the lines, and how do we address the need to have some people on multiple teams seemingly regardless of how we split up the teams?

Answer 1

Two thing to remember:

• One, while daily scrum meetings can be useful, for some projects one or two meetings a week can be sufficient.

• Two, having people attend multiple scrum meetings is not a bad thing in and of itself (having people split their time between projects is inefficient, but that's life/business sometimes).

Scrum/Standup meetings should be small enough such that everyone present is genuinely interested in what everyone has to say. This is usually five people or less. Product managers/stake holders may be happy to have a single meeting, but developers will hate it (and they should), and the quality of whats discussed will suffer.

I'd recommend breaking things up into tiny scrums/standups, and decrease their frequency so that each developer averages no more than 1.5 scrums/standups a day. You could then also have a once a week (or every other week) meeting where team leads show up (or whomever teams decide to send) and give more relevant updates/demos to the stake holders and other teams. This will save time, and hopefully generate much more meaningful conversations.

Answer 2

The question mentions Scrum. We can start there.

If you ask a Scrum purist, they will tell you that a Scrum team is self-organizing. That means that if you are forming one or more Scrum teams in an organization, the teams should be allowed to structure themselves appropriately. A Scrum Master (or another kind of coach) will teach the team about the roles, team sizing, and will help the teams ensure that they are cross-functional or have a plan to get cross-functional.

Now, Scrum is built around one team of between 4 and 11 people (see my answer here for rationale). Scrum doesn't have a whole lot of guidance for dealing with multiple teams. However, some frameworks do support multiple teams. Nexus is designed to scale to 3-9 teams all using Scrum. Large-Scale Scrum (LeSS) is another framework that helps to scale the Scrum principles up to multiple teams. The Scaled Agile Framework (SAFe) provides a few different flavors for different sized organizations. Disciplined Agile Delivery (DAD) provides a framework that considers the entire organization operating in a lean or agile environment along with different delivery lifecycles and considerations for non-technical aspects of organizations.

If you look at the details for Nexus, LeSS, and SAFe, you see that smaller teams are recommended. Nexus and LeSS are formed around Scrum teams, so the teams should be between 4 and 11 people, all working in standard Scrum. SAFe recommends 5-10 people and considers teams working in something other than Scrum as a basis for their approach. DAD, though, has considerations for several teams, including two methods for what it calls Medium Sized Teams (teams of between 25 and 30 people) or Medium Sized Team of Teams (groups of 12 to 50 organized into sub-teams).

So, onto the problem - how do you break down a team.

Nearly every agile method considers cross-functional teams. The question proposed three ways of breaking teams down. It seems like the third method, breaking teams down by the type of work, is the least consistent with agile practices as the teams are more likely not to be cross-functional. Any way of organizing teams should give the team all of the skills needed to deliver meaningful value to stakeholders.

My recommendation would be to break down the teams by deliverable components (package) and staff the team with developers who already have or can build competence in those particular components. You should likely also form "meta teams" of your roles to coordinate and knowledge share across teams - this is especially true for your product managers and architecture experts to ensure a common vision and direction across teams. As long as you can staff each team with a person in a coaching/leadership role, a product owner, an architecture owner, and a handful of developers, you can apply the agile principles. To promote a fully cross-functional team, I'd recommend making sure that there are enough specialists (think independent testers, user experience designers and engineers, similar) to support each team.

I'd recommend looking at DAD as a foundation. It's generally close enough to Scrum that a transition will be smooth for most involved, but does guide situations where you may break down a team but still have teams that are too large and traditional Scrum methods break down.