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.

  • 5
    It seems like you have an XY problem. The problem doesn't appear to be with the cross-functional teams, but elsewhere. Is your product so large that it should be considered multiple, more loosely-coupled products? Do you have a ubiquitous language that encodes the domain terminology in all layers and aspects of the system? Are you working to teach domain knowledge to all members of the team?
    – Thomas Owens
    Mar 18, 2022 at 16:31
  • @ThomasOwens I know, that in an ideal world, all products are small, but it is not something easily changeable. I am not asking whether there is a problem CF is an answer to, but whether it is scalable to cases of complex systems. At my previous workplace, they went for the easy answer that sufficient domain specific knowledge is transferable by allocating some time for teaching it, but they soon had to realize, that not only is it unfeasible due to the shear amount of knowledge, but eg. sufficiently good java devs do not even want to know about systems written in c++ and vice versa. Mar 20, 2022 at 16:36
  • 1
    From my reading, your comment and the body of the question are asking very different questions. Yes, cross-functional teams are scalable to complex systems. No, you can't "do Scrum" without cross-functional teams (unless you change the definition of the product to make sure that all the members of the Scrum Team have the skills needed to deliver value). You may or may not be able to achieve agility without cross-functional teams - it helps, but I'm not sure it's a hard requirement. I'd recommend focusing the body of the question on your problem and I'd be able to expand in an answer.
    – Thomas Owens
    Mar 20, 2022 at 16:59
  • I made my case that the concept of cross-functional teams is a very badly scalable one. As this claim of mine was supported by both multiple examples from my work, and the experience of people I know, I assume, that the decision that scrum needs to be done was never made supported by science or empirical proof, but It was just adopted due to its convenience for client requirement management (and claims by agile coaches wanting to sell it) and never tested whether it is optimal for big systems. I am either looking for evidence falsifying this statement or supporting references I can cite. Mar 20, 2022 at 20:42
  • @ThomasOwens Changed the title, so that it shows what I would like to find books/publications/references on. Mar 20, 2022 at 20:51

2 Answers 2



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.

  • Many books written on scrum mandate CF, but there are ones that do not have it listed as a core quality, never even mentioning it (hence the thought that this is probably an appendage added later). None of such writings I found discusses alternatives though. About CF at scale: I never argued, that a company could exists without functional knowledge of its every operational domain. But scaling it "inside" a team eventually leads to no common ground between two individuals. On other redeeming qualities making this sub-optimal setup viable: these were ethereal: what exactly are the benefits. Mar 21, 2022 at 8:24

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.

  • 2
    This self-answer is an example of a cognitive bias where you're looking for support for an argument you're advancing and ignoring other data. In addition, Conway's law is correct so far as it goes, but it doesn't say what you want it to say. Larger organizations tend to have more rigid and layered communications patterns, so of course the systems and processes are often designed around rigidly-siloed teams and communications patterns. This is a tautology, and a more thorough reading doesn't support your premise that cross-functional teams are orthogonal to productivity.
    – Todd A. Jacobs
    Mar 31, 2022 at 14:27
  • There is no bias, I asked for the foundations that lead to the addition of CF to scrum in the modern definitions. As I did not receive any evidence, not even a hypothesis on it, I started to look in early agile books, and this is one hypothesis I came up with. I would be biased if I found evidence for the contrary and cherry picked my results. However, I honestly did not find any. I would be happy to receive data refuting my hypothesis which states negative correlation, not orthogonality: “He who knows only his own side of the case knows little of that" - John Stuart Mill Apr 1, 2022 at 15:53
  • The mention of Conway's Law immediately suggests the converse: in order to have software that's robust in every area and interfaces well between its components, the development teams should be structured so that they are not too specialised to do so. Apr 19, 2022 at 21:51
  • @TobySpeight Is it not the case that a specialized team that "owns" a component can design it more robustly than a team where one person just happened to get temporarily assigned to modify its interfaces? Apr 20, 2022 at 6:48
  • Component-oriented teams can find an agile environment difficult, especially with layered and/or distributed architectures, because the changes to implement a minimal Feature (a "vertical slice" of functionality) that can be demonstrated at the end of the sprint tend to affect many of the components, reintroducing the many-way communication that Agile techniques strive to avoid. To work effectively, the team needs to be able to work at all levels needed for the feature delivery, including making changes to the inter-component interfaces. Apr 20, 2022 at 8:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.