So your once-small Scrum team that was knocking out releases like clockwork has begun growing, and now it feels like it’s about to break under its own success. Your sprint planning meetings have become marathons, and stories aren’t getting “done done” because there’s always some small thing slipping through the cracks. Now you need to look at how to scale your team, but you don’t want to lose the agility that helped create the success in the first place.
Scrum is great, but by-the-book it starts to break down when your scrum team grows. (8 members seem to be about the maximum before things get out of hand for me). You won’t want to overreact and install heavy management practices that you know don’t really work, but you have to face that 1) software is complex and 2) people are complex. The more you have of both, the more complex the management problem.
One of the first ways product leads may try to scale their team is to split it horizontally. In practice this usually starts as a “front-end” team and a “back-end” team. The challenge with this approach is that it makes it harder to focus on delivering completed, releasable, end-user functionality (user stories) at regular intervals. You end up with stories not getting done because of communication problems between the teams and no one team taking full responsibility for getting things done. Finger pointing and tears ensue.
To see if you are ready to scale your team horizontally like this, take a look at the maturity of the API that sits between the front-end and back-ends you are planning on forming teams around. Based upon the state of this API, you can evaluate the benefits and drawbacks of splitting your team horizontally and either scale in a different way or push to move up the API maturity ladder so you can efficiently scale your team.
0 – No API: If you are here, your project simply isn’t architected to be conducive to a horizontal split. You will still likely just have one large team effectively because the horizontal layers aren’t independent enough. Developers will still need to know everything up and down in the code base to get anything done, and they need to coordinate their changes. (By API here, it doesn’t have to be a REST API, or some other physical tier, but any reasonable well-defined separation of concerns can quality.)
I – Immature: Most projects (especially mobile and modern web apps) start here. Although there is an API and well defined layers, no reasonable functionality can be built without changes to each layer in the stack. Design of the API itself is still being fleshed out as you go.
II – Typical: The project isn’t API focused but does have a clear division between the layers. Developers can quickly identify which layers will need to change to implement a feature and have an established ‘lingo’ for talking about how the layers communicate. Many user stories require changes to multiple layers, but not all.
III – Mature: The product is API focused, and many substantial product improvements can be made without requiring changes to the other half. In practice, this often means user stories are more about exposing functionality to the user rather than implementing it. Changes to the back-end behind the API are seen as larger strategic initiatives that may not be completed within a single sprint cycle.
Not surprisingly, as you move up the scale, the more effective a horizontal team split becomes. In the lower tiers, the separate teams aren’t able to bring much value on their own. Tier II is about where it starts making sense to consider a split, but you have to look at where most of the work is being done and what type of features you need to deliver in the future. You may still be better with separate functional teams (vertical teams) depending on your particular project.
Tier III is obviously where it’s easier to make independent horizontal teams. If you are here, you probably already have de facto horizontal teams; they are just cohabitating. Not every project moves to this level, nor does it need to. It does require an API-first mindset, and it often only happens if the API is published for outside clients to use. But it is the most conducive to horizontally align teams; it minimizes the dependencies between teams that quickly bog down larger teams.
Tier II is where many projects stay, especially during a growth phase. Moving to Tier III requires a different mindset and isn’t necessarily ‘better’. In fact, maybe Tier III apps may be better managed not using Scrum (blasphemy), but that’s the subject of a different discussion.
So before you just default to splitting your team into horizontal groups, take a look at the maturity of your API. By carefully looking at it, along with the direction of the product itself, you’re likely to avoid some of the traps many teams fall into.
