This post is about organising large teams, specifically large teams working on a single product. One of the defining characteristics of enterprises is their size and the development teams, and the products they work on, within such an organisation often share that. Our VP used to brag that he had five hundred and fifty people in his engineering organisation, five hundred and fifty one including him. And apart from a few PA’s for the directors, and a small IT team most of that count were developers, QAs or their managers.

In many cases the teams will be organised on functional lines and broken down until you get to a manageable size. In that case each team can use pretty traditional scrum methods with little trouble. They’ll each have a backlog,  four or five developers, two or three QAs and they’ll run their sprints as a single team.

But what happens when the product is large and there are 25 developers and 15 QAs working on it? And here’s the crucial bit, any developer can (within reason) work on any part of the product. Teams aren’t divided functionally, nor are they broken up into front end, services, and DB teams, or any other arbitrary division of responsibility.

This pretty much describes my team, and before you denigrate that arrangement there are good reasons for it;

1. You can bring more developers to bear on problem areas and new features and bring them to market sooner. i.e. you’re more agile.
2. Product knowledge is spread throughout the whole group as opposed to being siloed in functional teams.
3. Developers are more mobile within a team allowing them to find their own niche. And happy developers are productive developers.
4. The team is more efficient. You don’t have one team cruising with an empty backlog doing priority 3 or 4 items while another is under the gun.
5. A single backlog.

Now there are downsides as well, I won’t go into that now. however, with regards to scrum I was fairly sure that a single sprint team with forty members wasn’t going to work.

The solution was to break the team up into six smaller sprint teams with 4 or so developers and two or three QAs each. How we chose the makeup of those teams I’ll leave to a later post. In fact there are many aspects of this  arrangement  that warrant later posts. The immediate issue we had to solve however was scheduling.

Put simply, with a single product and a single backlog and a single product owner, no two sprint teams could have a planning meeting or a handover simultaneously.

Remember that we have six sprint teams in this scenario, and that a planning meeting is usually a half day event. Doing the math on a standard two week sprint that meant that the only time the product owner would have outside of the sprint process was Monday morning and Friday afternoon.

This is just one example of where slavish application to doctrine fails in the enterprise. Two week sprints are too short.  So we made the sprints three weeks long. That meant that by staggering the start of the six teams, we could arrange two planning meetings and two handovers each week.

The reality is that most scrum advice says to start with 14 days, or 30 days and adjust the sprints to whatever works for your team and product. But the reality of our situation was that three week sprints were the only option we had if we wanted to keep a sustainable level of load on management.

So, where other teams might have stretched their sprint cycles out to deal with large or complex backlog items inherent to their product, we had to stick with three weeks. The reality was that often we would admit that some items were just not possible to implement in three weeks. Or, the effort to break them down into chunks that could be consumed by the teams in three weeks was not warranted or simply artificial.

So sometimes we broke the scrum rules about having artifacts of one sprint carry forward into another and having no concrete deliverables from the first sprint. I’m sure everyone in the enterprise has done it at some point. And as long as you can arrange things so that you don’t branch for release between the first and second sprint, where’s the harm.

Of course, when your fresh-out-of-certification-training scrum-master sees this happening you’ll catch an earful, but only the first time. Once you’ve broken another half dozen or so rules this one won’t even be a bump in the road.

Now, would I use that arrangement again? Only if the product can’t be broken along functional lines. It’s not easy. But if you have a big homogenous product and are short on staff it’s worth considering.

If you take this approach you need to consider the following;

1. Scheduling is really important. You need to have your project managers create a schedule for your sprints and teams need to stick to it.
2. Stagger the start of the sprints, and account for a dead couple of weeks at the beginning, and that you will have sprints still running when you hit milestones.
3. If at all possible avoid Mondays for planning or handover meetings. Only because a public holiday will cause a reschedule, and this will invariable clash with one of the other teams and there will be flow on effects.
4. Keep the backlog well groomed and the sizing estimates there normalised and reviewed. You will have enpough trouble tracking velocity metrics for all the teams without the additional complication of adjusting for backlog variance. (This is good advice for any backlog really).
5. You will be have several backlog items consumed per week, so you need to keep ahead. Remember there are two planning meetings per week.
6. Keep track of runs of related backlog items. If you have the runway on the project plan it’s better to have the same team pickup related items. It’s good to give teams choice and let them self organise the work, but that still needs oversight.