This article describes an essential element of Lean-Agile initiatives: The cross-functional team.

Introduction

What is a cross-functional team?

• A cross-functional team is not just a group of people each of whom can do anything. Rather it is a group of people working together, on the same goal, that between them have all of the skills and capabilities needed to deliver the value requested of them. This may require a degree of specialization by some of the team members.
• Cross-functional teams promote creativity more powerfully than when people work separately from each other.
• The cross-functional team is a core component of any Lean-Agile initiative because they make the management of the work easier, enable teams to learn how to work together better, and help to eliminate delays between the workflow steps since the team comprises virtually all of the people needed to get the job done.
• Cross-functional teams may be formed at every level of the organization including the executive team.

For software development, the most well known example of the cross-functional team is the Scrum team. The heart of Scrum is the self-organizing, cross-functional team. Because it is so well known, this article will explore the cross-functional team in this context. The ideas work at other levels.

Listen to Al Shalloway reflect on this case study

Challenges to cross-functionality

There are two parts to cross-functionality. The first is that different skills need to work together. The second is that teams need to have all of the skills required to produce value.

Scrum teams face many challenges in completing the work committed to in a sprint. Here are two major kinds of challenges they face:

• Testing is not completed by the end of the sprint. This challenge arises when Testers do not collaborate in an ongoing basis with the developers.
• When multiple teams are involved, there is a tendency for the teams to work in layers instead of being truly cross-functional. This challenge arises because working in layers delays the integration of the function built.

Challenge: Testing is not completed by the end of the sprint

It is very common for Scrum teams not to complete testing at the end of every sprint. Even when testing is completed within the sprint, developers have likely moved on to the next stories to be developed. When testing lags the completion of coding, a significant amount of work is added to the development process (see Looking at time is critical). The best and easiest solution to this challenge is to specify tests before writing the code. These test specifications need to be very specific. They are designed to answer the question, “How will we know we have done that?” regarding a particular requirement or story.

There are variants of this process such as Acceptance Test-Driven Development, Behavioral-Driven Development, Story Writing with Tests, and Specification by Example. An excellent resource is Lean-Agile Acceptance Test-Driven Development by Ken Pugh.

Challenge: Splitting teams by layer

A few years ago, Al Shalloway was teaching a Lean Software Development course in San Francisco. One day during lunch, two students talked with Al about a specific problem they were having. One of these students was the director of a large development group and the other was one of his top technical folks. The problem had to do with the structure of the group.

In their area, they were organized as three separate teams. As shown in Figure 1, each team had its own area of expertise: User Experience, Mid-Tier (business logic), and Database.

They recognized that this being organized this way caused delays when functioning code was written. As they had been thinking about the Lean-Agile ideas presented in the course, they realized that they needed a change. The structure reinforced the idea that teams can and should work independently. Too often, teams would start out with an agreed-upon set of requirements and then work independently to complete them and then, only at the end of the sprint, would they try to integrate the components. The result was a lot of delay!

They wanted a structure that improved the flow of value. Lean-Agile principles helped them see that reorganizing into cross-functional teams would be better. Each team would have some UX, some mid-tier, and some  database developers. This would enable each team to build complete end-to-end stories.

Al agreed with their idea and asked them why they had chosen the old structure. Their reason was that it was based on their understanding of Scrum, to let teams self-organize. And this was the structure the teams came up with on their own. In fact, the Scrum principle is to have “cross-functional, self-organizing” teams. The teams had missed the first part! They had organized without considering what would work best to promote overall flow of value.

When Al asked how the teams justified this structure, the students said that teams wanted to have the UX developers together to ensure a common interface, the Mid-Tier teams needed to talk with each other for a common architecture, and the database developers emphasized that a schema being worked on by several people independently would be risky.

This sounds logical and could even be true but it is too limited, too parochial. It may be based on factors such as lines of friendship (UX guys like hanging out together). The problem is that “self-organization” by itself does not result in perfect structures. Self-organization must be informed by the larger picture and motivated by the overall flow of business value.

Challenge: Cross-functional collaboration in two dimensions

In cross-functional teams, we want to encourage collaboration along two dimensions: collaboration across the skill discipline (UX, Mid-Tier, Database) and collaboration on the work to be done (to optimize the overall flow of value). See Figure 2.

Notice how this structure has several advantages and a few disadvantages. First, teams are now cross-functional. This means that complete functionality can be built at a story level by one team. At the end of the sprint the work should be completely developed, integrated and tested. Furthermore, although coordination must be made across the teams at the UI, Mid-Tier, and Database level, the people who need to do that coordination are a type of team already since they have a vested interest in keeping the UI, Mid-Tier and Database well-coordinated. It is important to notice how our tribal nature works against us in the first organizational structure while it works for us in the second.

A side note is that the teams didn’t really mind reorganizing this way. Although they weren’t really given a choice, they understood why it was a good idea. They were willing to try something that they realized was for their best interest but that required a little adjustment.

Do you always want cross-functional teams?

There is no question that diverse teams make for better innovations. In The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century, Steve Denning says,

“Complex problems, such as discovering ways to delight clients, is best solved by a cognitively diverse group of people that is given responsibility for solving the problem, self-organizes, and then works together to solve it.”

Scrum’s mandate for cross-functional teams takes diverse teams a step further by saying each team should have all of the skills needed to create the value needed by the customer.

This is ideal; however it is often much more difficult or financially expensive to create cross-functional teams than it is to create diverse teams. One reason for this is that we sometimes have certain people that are needed by several teams whose skill, or other abilities/knowledge is hard to replicate. We often think of these people being essential due to the skills they have, and this is, often the case. But there are other reasons that we may require someone’s presence. For example, they may have extensive knowledge about the problem domain they are working in. They may also have been present when the code was written years ago and know how it works – something that can be invaluable.

Although cross-functional teams have definite advantages, they are not always viable. Most all companies of any size will have people that need to be available to more than one team. This can be for any number of reasons. A simple example for large organizations is the role of the architect. Large organizations will not have a skilled architect for each team. Yet, architecture for large systems is an important skill to share across teams. Another reason is that people with the skills are not available, can not be found.

Even if you do not or cannot use cross-functional teams, you must make sure the right people are present at the right time to get the work done. This is where Kanban can be extremely useful.

Summary

It is important that teams self-organize but they must also have the right composition of team mates. Even the right composition is not enough: teams must work together as teams.

Teams face many challenges. This article looked at two of them.

• The first challenge described how teams often had developers and testers but they are not working together. This is not a true team but two separate units under the guise of a team.
• The second challenge looked at splitting work up across teams. It is best to organize the teams to be cross-functional instead of by layer. This is not always the preference of the individual team members as they may not be aware that what they would like to do isn’t the most effective method available. This is where an opportunity for coaching by the teams’ leadership is available. Provide the understanding of the laws of flow and recognize why one particular team composition is better than another.

It is risky to always assume teams will structure themselves with the bigger picture in mind. In general, teams should be composed to enable them to work on the broadest extent of the value stream possible.