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.
- 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. - 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. -
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?
Best Answer
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.