Cross-functionality is not scalable. Is there evidence that it is optimal for scrum teams, or did CF just become popular due to low "management cost"?

Question

Is cross-functionality a concept that bleeds in any sufficiently big software-architecture?

Due to an organizational restructuring, we have been working in a cross-functional software-development teams for one year. We are working on an architectural modelling software, where each delivered feature requires quite a lot of specialized knowledge. Lately, we have been struggling to maintain structured work on backlog items due to lack of having a common development domain.

First of all, I understand, that cross-functionality is comfortable for project management. You don't need to conduct API contract negotiations, you cannot have a feature delayed due to having a single component-team not delivering in time, you cannot have multiple clients competing for the same development resource, etc. However, management is not where the bulk of the work happens. As a senior developer, I would estimate myself taking 1/5 (one-fifth!) of the time finding bugs when working on a problem domain I am familiar with, and this number is probably much worse for juniors.

Another interesting consequence is that the time spent refining tasks now take up more than half of our development time. Many teammates confessed feeling distressed discussing issues noone really understands or cares about (the use of words with repeating characters is accidental :)). This behaviour is understandable though, as even other developers of the team are unlikely to pick up issues from the same part of the code-base until it changed so much that the knowledge they would pick up is not out-dated.

The famous term "Wisdom of Crowds" coined by James Surowiecki is the central concept in scrum for estimating how much work the delivery of a feature or a bug-fix would take. It uses the fact, that the aggregate workload estimation of people having domain-specific knowledge of the subject is likely to be better than each individual estimation. However, the pre-requisite for this to be true is that each individual has domain specific knowledge. If I were to pick a random developer from the world, they would not probably not help the estimation one bit, apart from maybe contributing with a new perspective on the problem. Discussing a problem can take up ten minutes from the whole team (which is usually dead-time for most members), and quite a lot of preparation and investigation from the person trying to find the cause of a bug or the alternatives in a user story of a feature. The case is even worse for technical stories.

I came up with a story to illustrate what it feels like:

Imagine being in a car factory, where the problem one needs to solve is that the robot used for painting cars red has insufficient flow rate in the red pistol gun, and the team has a technical story to improve such flow rates. The investigation means that we take the paint-gun expert developer, who measures the flow rates in each segment of the paint gun, and deduces that they can either use a bigger valve, that supports X rate of flow, or redesign the paint-pistol, and it is easy to test afterwards. Noone really cares (as they would probably never need to design a paint pistol, and it is not their expertise domain either), so the person goes with the earlier solution. As for this solution, the bulk of the job is already done, so it is marked with a low number for story point and the issue gets assigned to the next sprint, but the bulk of the work is already done in the refinement phase. The developer replaces the problematic valve and looks for another item on the non-sprint backlog to refine.

I had similar problems in my previous workplace, where the requirement of having cross-functional teams was removed to solve similar issues (where c++ developers, a perl script maintainer and database expert, java developers, a python test automation engineers as well as a manual tester were working together in a single cross functional team, where team-members could not care less about each others expertise), and upon self-reorganizing around a horizontal structure (pointing in the alignment of chapters), productivity and motivation increased tremendously.

At my current workplace as a solution, I suggested trying a team reshuffle, where we ditch the requirement of being cross-functional as well (which is best for a niche problems like creating web-apps), but as far as we understand this goes against the core scrum practices. What is the book-recommendation for doing scrum without cross-functionality? Is CF mandatory to begin with? Why? I tried looking up answers for this question, but most results either view the problem only from the perspective of project management flow or assume, that "whoever thinks CF is bad, likely expects that in CF, people need to have skills for every domain, the team works in" - which is not the case here.

Answer 1

TL;DR

If you aren't doing software development, or working with a business or product-development model (or even just a company culture) that lends itself poorly to small, cross-functional teams, then the Manifesto for Agile Software Development or the Scrum Guide may not be your best options. However, any large-scale system that doesn't have an intense focus on integration—and therefore a cross-functional skill set at least at the organizational level—is pretty much doomed to fail. Your mileage will not vary.

You present some anecdotal evidence about why your organization can't or won't do cross-functional teams or processes, and mostly point to the fact that cross-functional processes aren't necessarily cheaper, may not reduce overhead, and for various reasons make certain individuals or teams within your organization unhappy. Those things are often true but largely beside the point. Rather than argue those points, I will instead address why cross-functionality is pretty much de rigueur for any form of successful development and delivery (small or large), where it's mandated within Scrum, and some systems-thinking alternatives and further reading if you decide you want to take an alternate approach to implementing the required cross-functional integration processes to whatever it is you're actually trying to do within your organization.

Cross-Functionality and Integration Must Exist, Especially at Scale

In this section, I will address why cross-functionality always exists in successful systems, especially large ones. I will also address where Scrum mandates that teams be cross-functional, although you will need to do a lot of additional reading to understand some of the empirical control theory behind why it does so. I will also introduce the notion of systems thinking, which is essentially lacking from both your problem description and the solutions space you are grappling with.

Cross-Functionality is (Pragmatically) a Universal Requirement for Successful Delivery

Is cross-functionality a concept that bleeds in any sufficiently big software-architecture?

Cross-functionality is not mandated by all frameworks, but all projects must be fully cross-functional especially at scale. This can be done in-house by having all the needed skills on one or more teams, or can be done by outsourcing specific skills or pieces of program/product delivery outside the organization, but one way or another you have to have all the needed skills somewhere in your matrix or the project(s) fall apart.

Cross-Functionality is Mandated by the Scrum Framework

What is the book-recommendation for doing scrum without cross-functionality? Is CF mandatory to begin with?

If you plan to do Scrum, or a framework based on Scrum (e.g. SAFe or Nexus), then it is mandatory. Specifically, the very definition of a Scrum Team says:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

Furthermore, attempting to redefine "Scrum" without cross-functional teams make whatever you're doing Not Scrum℠. The Scrum Guide says:

The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety[.]

so while you're free to adapt the framework in any way you see fit, the end result cannot be Scrum if you aren't leveraging cross-functional teams.

Systems Thinking

Scrum may or may not be a good fit for your organization, product, or company culture. That's fine; there are other agile and non-agile frameworks to choose from. However, what you really seem to have is an X/Y problem where you're not taking a truly systemic approach to your organizational and systems-development structure.

One of my favorite authors about systems thinking and IT organizational structure is Bob Lewis. He's been writing about these sorts of topics since at least 1993, and if you search his IS Survivor blog carefully you will find no less than 44 articles that discuss one of his most valuable phrases:

To optimize the whole, you often have to sub-optimize the parts.

This is core to lean and systems thinking. The goal is to optimize for the system (whatever you conceive that to be) rather than to optimize each team, department, or project. Cross-functional teams don't always optimize for organizational, budgetary, or HR concerns, and definitely don't optimize for the individual happiness of I-shaped people or the managers who hire them.

Suggested Reading

While there is a lot less hard science behind the Scrum framework per se, there is a lot of science backed by research and hard data behind systems thinking and the lean approach in general. If you want science and data rather than a more pragmatic approach such as Scrum (which leverages both empirically-proven and well-researched approaches without necessarily pretending to be either one in the academic sense), keep in mind that project management and systems optimization are continuously evolving fields, so any list is both subjective and potentially dated by the time you read it.

That said, you should definitely read books by Drucker, Deming, Poppendieck, Lewis, and anything to do with queuing theory (if you can handle the math) to understand why successful agile principles are generally based on small teams with predictable batch sizes that have frequent inspection and integration points. Especially in larger systems, the predictable cadence of inspect-and-adapt cycles and routine integration points are typically the biggest problems organizations have when operating at scale. Of course, that also means those cycles and integration points are arguably the most important locations to place your cross-functional people and processes within the system.

Answer 2

I have spent some time reading books leading up to the agile frameworks, especially scrum. I think I have found some evidence that the notion of cross-functionality is also a distortion of some general rules.

According to Wikipedia, Conway's Law can be formulated the following ways:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

The structure of any system designed by an organization is isomorphic to the structure of the organization.

Notice, that these definitions are quite easy to misinterpret in a way that promotes cross-functionality!

Back in 2004, when "agile" was this shiny new thing on the list of organization construction methods, James O. Coplien and Neil B. Harrison wrote their famous book (and rightly so) "Organizational Patterns of Agile Software Development", which formulate its rule-set by directly drawing on observations related to Conway's law. This book is even cited on the previously mentioned Wikipedia article.

In this book some of the short, quotable lines can be quite misleading, and this kind of wording is used quite often:

Be sure every deliverable has one and only one owner.

However, it also contains a detailed explanation by what it means by ownership, and it it is not ownership in a sense of owning every component related to a complex user story. In terms of team structuring its wording is:

This is a refinement of the pattern CONWAY’S LAW; it tells what criterion by which the structures of the organization should be aligned with those of the product.

People skills tend to be relatively stable over time, so this organization protects against shifts in staff.

The variation protected against here is the variation in staff skills over time. On a small enough project, the few people may have multiple skills that enable them to mix UI design with infrastructure design with domain design. Unhappily, their successors may not, which makes system evolution more difficult and costly.

On larger projects, the many people are more likely to have single skills and specialities. If their code is intermingled, two expensive difficulties accrue: getting the different people to learn to understand each other and come to common decisions, and the same system evolution difficulty as with the smaller system.

Separating their specialities into different subsystems lets them work with their special issues in their special vocabulary, lets their successors see those issues in isolation, and makes the project easier to staff, since the staff need not be so multidisciplinary. Once the sub- systems are identified, various forms of teaming may be used to develop them. The pattern of course should be applied in moderation; (...)

I found that studies on team compositions use the term "congruence" to describe similarities between responsibilities of team members. There are quite a few statistical analyses available in the form of publications. One report states:

Structural congruence is associated with shorter development times suggesting that when coordination requirements are contained within a formal team and appropriate communication paths exists, task performance increases.

Structural congruence is quite easy to identify, there is quite a lot of evidence on it having a strong correlation with the directory system of a given project, leading to the conclusion, that organization around components of a system architecture is probably better than cross-functionality.