big

NOOP.NL | The Creative Networker

Cross-Functional Teams Don’t Come Free

12/07/2010


Team-aheram-525764042
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.

Figure13-4c
 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 TwitterRss SubscribeEmail NewsletterLinkedIn LinkedInSlideShare SlideShare

Latest, greatest and favoritest posts:

Widen People’s Job Titles

T-Shaped People

How to Grow: More or Bigger?

This article is written by on in Communication & Relations. Jurgen Appelo is at Happy Melly. Connect with Jurgen Appelo on .

This article was posted in:

  • http://profile.typepad.com/jfbauer Jfbauer

    Another good post especially around the costs of having a cross-functional team not standing at zero. Interesting timing in that just recently, I posted a similar article with a sightly different slant on the effects of team structure on enterprise architecture. I compared the team organizational structure of functional versus business aligned and my take on the corresponding impacts on the strength of an enterprise architecture: http://bit.ly/9JIoNj
    Always enjoy the thought provoking posts and looking forward to the book!

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Thanks for the feedback John!

  • http://profile.typepad.com/galleman Glen B. Alleman

    Jurgen,
    I our domain, cross functional teams are supported by a Center of Excellence for each function. The COE provides the standards, methods, and approaches for that discipline.
    At the next level, the Systems Engineering COE provides the connections between the functional disciplines.
    This matrix of disciplines is then applied to individual programs and projects.

  • http://profile.typepad.com/theleaderlab TheLeaderLab

    Jurgen,
    Good points. I think cross-functional teams, like many things, are a trend caused by good ideas that grew too far.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Glen,
    Thanks for the input.
    Sounds like the “Communities of Practice” that are sometimes referred to in agile literature.

  • Lec

    Great post,
    Isn’t the root of the issue just a management issue ? When you refer to grouping people, it comes to who they report to. For responsibility of delivery reasons, managers tends to dislike competition and avoid having people managed by 2 heads.
    If you can solve the communication issue at the management level, then you can still have functional grouping (for competency sharing) and, at the same time, get people to report to a dedicated manager for a specific project.
    Functional groups can be seen as a service, from which you get competencies as required by a project. During the project, the amount, and level of expertise can change (like you need more QA at the end of a project, or you need very specific development skills for a short period of time).
    If you do this is a very administrative way, then project managers might spend most of their time getting available resources and competing with other projects. If you have a good communication and cooperation between managers, things comes easier.