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.