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;
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;