Cross-Functional Teams Don’t Come Free

How should people be grouped together? Basically there are two main options to choose from: group people by similar function or by similar business.

Grouping people by similar function means that you put developers with developers, testers with testers, and project managers with project managers. Such groups are called functional units, and the driving motivation behind this kind of structure is efficiency and functional learning. After all, it is easiest for writers of user stories to learn how to be efficient user story writers when they’re all put together in one department called User Story Writing.

Grouping people by similar business means that you put everyone together who works on the delivery of the same business value (the same feature, the same product, or the same customer). Such groups are sometimes called cross-functional units, because all people involved in the same project(s), from user story writers to binary assembly deployers, end up in the same group.

Good communication is both hard and crucial for any organization. It is therefore imperative that we let communication be one of our guiding principles when choosing between the two variants.

Which people need each other most often?

The ones with the same job titles?
Or the ones working on the same project?

If you were to analyze daily communication between employees it would quickly become clear that most of that communication is oriented around the business, and not around the function. People with different functions but working on the same projects need to communicate more frequently than people with the same functions who work on different projects (see figure). We can thus conclude that, for projects, cross-functional teams are a more suitable solution to the grouping problem.

 More communication within projects than within functional groups. 

It has been reported that, in organizations where people are grouped by function (sometimes referred to as functional silos), there are too many dependencies between the functional teams. Delivering even the smallest piece of business value (like one feature of a product) requires communication and co-ordination across multiple teams. Functional silos therefore have a high interaction penalty.

However… when you build teams across the functional silos, and not inside the silos, the interaction penalty is lower, but not zero! There are three problems with cross-functional teams: suboptimization at the project level, inefficiencies due to lack of coordination across projects, and reduced expertise because of limited knowledge sharing across specialists [Reinertsen 1997]. So it appears that with cross-functional teams the penalty is paid for synchronization of standards, methods and approaches within one functional discipline across different teams. For example, it will take a quality assurance manager more effort to co-ordinate best practices in testing, when the testers and QA people are spread over multiple teams. But the price being paid here is generally lower than in the case of functional units.

There are several other advantages to cross-functional teams (varyingly referred to as feature teams, project teams, organic teams, or product teams). Several experts report improved design decisions, reduced waste from hand-offs of intermediate products, improved speed, improved adaptability, simplified planning, and focus on delivering value.

But remember, unlike the Dutch score at world cup final, the costs of having cross-functional teams will not stand at zero!

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

(image by Jayel Aheram)

 Twitter –  Subscribe – Newsletter – LinkedIn – SlideShare