Since my new book Rethinking Agile was published, readers have been posting excerpts from it many times. I have noticed that many readers are particularly interested in the topic of cross-functionality. Like the Spotify model, cross-functional teams belong to the inventory of the agile reliquary shrine: their existence is usually worshiped without reflection, but often they are nothing more than silos whose walls have been repainted. I am of the opinion: True cross-functionality does not arise from simply throwing people from different disciplines together in a team. For all those who have not yet read Rethinking Agile: Here is the section from the book that deals with it.
Cross-functionality has nothing to do with team setup
It all sounds very romantic, doesn’t it? The fact is, though, this is about enormous change. Why should the business departments simply go along with it? The demarcation between “us” and “them” is a fundamental historical problem that exists in most organizations, regardless what type of organization it is. This can be attributed to specialized splinter groups that typically organize themselves into departments. They split themselves apart from each other and the whole organization. Requests and results are usually “given over” (or tossed over) to the other departments, whose approach and requirements might be completely different than in their own department. Then the demarcation can be seen: the departments are a red flag for product development, software developers are better than software testers, the business departments see everyone else simply as suppliers, and so on.
Trying to make a company agile does not inevitably make this situation better. Cross-functional teams are great to have and an important part of the company. However, it doesn’t necessarily mean that old prejudices just disappear. Now you just have cross-functional Team A that performs better than cross-functional Team B. Instead of functional silos, there are cross-functional silos. Congratulations! If you reduce the dependencies and combine teams according to product lines, Product Y is naturally more idiotic than Product Z. And taken from the portfolio point of view, there are only complete morons sitting at the top. With “performance” bonuses, you can easily reinforce this animosity or even make it worse. In doing so, only individual parts of an organization will be optimized, but not the value creation for the customer.This competition must first be removed. As I have shown with this company, it isn’t as easy as it sounds. It is a cultural process that already starts with recruitment. The required maxim should be “don’t hire skills, hire attitude”. Sure, subject matter expertise is important, but it is much easier to acquire subject matter competence than it is to change attitudes. Cross-functional teams are in no way the Holy Grail of agility making social points of friction between the performance areas of a value stream just magically disappear—sometimes they just shift. Bringing together various schools of thought in one team is still better than focusing on individual performance or on the performance of individual specialist silos. When it’s about focusing on the customer, integrated value generation is only a small drop in a very large bucket.
Cross-functionality is a company mentality and not an organizational setup for teams. It means creating an environment where it is ok, or even desired, to perform poorly locally (whilst learning) if it helps the overall performance of the organization. It isn’t enough having everyone is pulling on the same rope—they must all pull in the same direction, too.