Home > Articles > Software Development & Management > Agile

This chapter is from the book

Functional Teams versus Cross-Functional Teams

Whether team formation is done by the manager or by the teams, one important question needs to be answered, "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 [Larman, Vodde 2009:243]. 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.

In Chapter 12, "Communication on Structure," we discussed that 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 13.4). We can thus conclude that for projects cross-functional teams are a more suitable solution to the grouping problem.

Figure 13.4

Figure 13.4 More communication in 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 coordination across multiple teams [Poppendieck 2009:68]. Functional silos therefore have a high interaction penalty [Augustine 2005:26].

When you build teams across the functional silos and not inside the silos, the interaction penalty is lower but not zero. Donald Reinertsen lists 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:104]. 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 [Cohn 2009:182–188] [Larman 2009:154].

  • + Share This
  • 🔖 Save To Your Account