When we think of scaling the work, we’re typically thinking of stories that are grouped within features or epics, which might be grouped inside even larger items. This is vertical scaling and is fairly common. There is another type of scaling, which we need to also consider, and that is horizontal.
Horizontal scaling is when we pass the work from one team to another and there is no real value until multiple teams have touched it.
Our assumption should always be that the work items flowing through our system are valuable, or at least they are something that we expect to be valuable. In a horizontal scaling model, we are saying that no single team is able to deliver value on their own, and we have to establish cross-team handoffs.
For example (as seen in the diagram below), we might have a product team that does the research and comes up with the idea. They pass that work to a dev team to actually build and they then pass it off to a completely different team to be deployed. While each of the three teams might consider their work to be “done” when they’ve handed it off, there is truly no value until the final team has done their part.
The longest chain I’ve seen was a group of seven teams where the work would be passed from one to another to another until it finally got delivered and we would then discover if there had been any value at all. I had been asked to coach the fourth team in this chain and it quickly became apparent that we needed to look at the larger picture in order to make any real improvements. This one team delivered no direct customer value on their own and had little visibility into the entire flow.
When we can’t see the full picture, it’s extremely hard to stay focused on real value and we end up optimizing for busyness.
How might we have gotten to this place?
Conway’s law effectively states that the architecture of our systems will follow the communication paths of the organization. In other words, our org-chart will define how our systems work together.
“To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces. The larger an organization is, the less flexibility it has and the more pronounced is the phenomenon.”
— Melvin E. Conway, 1968, How Do Committees Invent?
When we end up with horizontal scaling, where multiple teams are required in order to deliver any value at all, we often discover that each of those teams reports up through a different area of management and that unraveling that to make the system more efficient will require changing the reporting hierarchy. Something that many companies are reluctant to do.
Sometimes we find that due to the way we’ve structured the organization, we have teams of specialists together. So there might be a product team, and a UX team, and a database team, and a testing team. This is inefficient because we have introduced handoffs between these groups and no single team can deliver value on their own.
In most cases, we’d be better off if we created cross-functional teams that could do all the work themselves. Of course, that introduces the next possible reason for horizontal scaling.
Sometimes we need such a diverse skill set to complete the work that for a team to be fully cross-functional, it might need to be huge and there is typically a desire for smaller teams.
Smaller cross-functional teams have many advantages over larger cross-functional teams and tend to be far more effective. The trick here is that to compare them effectively, they have to both be cross-functional. Two teams of 10 that are dependent on each other because of required skills, will typically be less effective than a single 20 person team that has all the skills they need.
The point is that we will often scale horizontally out of a desire to keep team size small and will then make both teams less effective as a result.
If you think you need horizontal scaling because you can’t create a single small team with all the required skills then take a look at FAST Agile and their approach to dynamic reteaming. That may be a better approach for you.
There are times that we have to scale horizontally, typically because of Conway’s Law. Consider whether that is benefiting your environment or if there is a way to reorganize to avoid it.
See also: This visual from John Cutler, showing all the work we didn’t visualize that still is part of the workflow. This is also a variant of horizontal scaling even though it isn’t explicitly teams passing to teams.