Disciplined Agile

Achieving Cross-Functional Teams


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 the skills and capabilities needed to deliver the value requested of them. This may require some team members to have a degree of specialization.

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 agile/lean 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 because of fewer hand-offs. 

Cross-functional teams may be formed at every level of the organization including the executive team.


If it is financially viable and the skill sets are available, then setting up cross-functional teams is the preferred approach. Often, this is not possible. 

Unfortunately, with development organizations larger than, say, 30 people, creating idealized cross-functional teams becomes a challenge: difficult, expensive, or even impossible. This may be due to a shortage of a particular skill set or simply people reacting to what has happened in the past. 

There are alternatives available to gain the benefits of the cross-functional team approach as much as possible.

Challenge: Testing Is Not Completed by the End of the Iteration

It is very common for agile 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. 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.

Challenge: Splitting Teams by Layer

The director of a large development group had a problem with the structure of her group. In their area, they were organized into three separate teams. Each team had its own area of expertise: User Experience, Mid-Tier (business logic), and Database (Figure 1).


Figure 1: Composition of teams prior to course.

This type of organization caused delays in writing code. 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 iteration, would they try to integrate the components. The result was a lot of delay.
The old structure had been created by the teams to let them self-organize by discipline. But they had missed the first part of the scrum principle: to use cross-functional, self-organizing teams. They had organized without considering what would work best to promote overall flow of value. Self-organization must be informed by the larger picture and motivated by the overall flow of business value.
They wanted a structure that improved the flow of value and felt 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.
Challenge: Need for Cross-functional Collaboration Across 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.


Figure 2. Cross-functional collaboration

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.

Challenge: Building Up Skills

One of the challenges faced by cross-functional teams is that a team member’s skill is needed by more than one team and the person does not have the time to cross-train someone else. In cases like this, have someone shadow this person. It may take a little more time to get them up to speed but it won’t be a burden on the person with the specialized skills. In fact, the “shadow” person may even be able to help at times.

Challenge: A Nearly Cross-functional Team Needs Time from Another Team

If a team is mostly cross-functional team but needs people from another group for two or more weeks, loaning people from the other group to the team may be a good choice. 

For example, a team needs help from a team that makes components for an application that is used by several teams. Say that they require 20% of the capacity of the 10-person component team. Rather than asking for 20% of the component team’s time, they could just ask to have two people loaned to them for a time. These two people would be involved in two daily coordination meetings (their temporary team and the component team) so that they could keep in sync. While this is not ideal, it is a good price to pay. For that time, the team was now able to work as a true cross-functional team.

Challenge: A Nearly Cross-functional Team Needs Someone Who Supports Several Teams

If a team is mostly cross-functional team but needs someone who must support several teams and cannot be loaned out. 
One approach is for that person to create their own visible kanban board so that teams can see what sort of delays they will face. This is helpful especially when there are dependencies. The kanban board should not be a FIFO (first-in first-out) but rather sequenced with the intention of reducing cost-of-delay based on the relative importance of the work being done.

Challenge: A Team That is Not Even Close to Being Cross-functional

If a team is not even close to having all the skills required to be cross-functional, they may have to adopt a pure flow model such as kanban to lower the delays in hand-offs between different people. 

How to Test If an Alternative Is Better

When considering a change, look to see what you expect to happen to the cycle time of work by looking at the value stream impedance scorecard. If the scorecard improves, you likely have an improvement. Try it as an experiment for a couple of iterations and see what happens.

June 2023