Skip to main content

Three Strategies to Build Cross-functional Teams and Why You Need Them for Agile

cross functional agile team

When working through an Agile transformation, many organizations struggle to efficiently re-organize delivery teams. Although you won’t find specific mention in the Agile Manifesto or the 12 Principles, most Agile frameworks (such as Scrum and XP) note that Agile teams should strive to be cross-functional. What exactly is a cross-functional team, why are they best for Agile, and how can you successfully transition from a single-skill team approach to high-performing cross-functional teams? 

What is a cross-functional team and why are they a better fit for Agile?

Traditional waterfall development teams tend to be organized around single skills, such as developers, QA, UI/UX, and more, with each single-skill team working on a part of the project and then passing it on to the next team, until the value is finally delivered to the customer. These siloed teams pose well-known challenges, including:

Too many handoffs. When a back-end team has to send their features to QA, there’s a handoff that requires extra coordination, using up resources and time. 

Delayed feedback. When a UI/UX developer needs to give feedback to an automation engineer, they have to coordinate with the other team, often working on a different agenda. Again, this requires more effort and more coordination, leading to delays.

Accrual of tech debt. Poor communication and lack of coding standards among teams can increase the amount of tech debt you carry forward..

Quality, morale, and ultimately customer satisfaction all suffer. 

A more effective approach involves Agile cross-functional teams. A cross-functional team is a self-contained team, with access to all the skills they need to go from the initial specification of features to the delivery of customer value. Members of Agile cross-functional teams may be generalists who have some knowledge about many different areas, or specialists who have deep expertise in one or two areas. Many cross-functional teams will have both, and all members on the team typically can help out in several different areas as needed.

High-performing, Agile cross-functional teams deliver significant benefits, including:

• Faster response times when challenges arise

• Higher levels of confidence in planning and visualizing end-to-end features

• Increased quality of deliverables

These teams are also more likely to embody critical Agile values such as openness, courage, focus, respect, commitment, and trust. 

Three strategies to build Agile cross-functional teams

Environments, products to deliver, culture, product size and scope, personal beliefs, team member personalities, and many other variables come into play when forming teams. 

Let’s consider three different ways you can transition to Agile cross-functional teams, including the advantages of each approach and how to overcome some of the more common roadblocks you might encounter. 

Before you start, you want to understand what skills you have with each team member, and what skills you need on each team. Create a list or inventory of what the teams would need and what their composition will be then share this list with management to provide visibility. You will probably uncover costs previously unknown and avoid surprises which could be detrimental for the change. 

Also, decide what success criteria you will use to evaluate and which metrics you will use to evaluate the success of your approach, and how you will keep your teams and stakeholders informed. Continue gathering metrics and documenting challenges so that you can compare the results you achieve with what you were capable of in the past. 

Strategy 1: Progressively move people from team to team

In this gradual approach, you incrementally move skills from one team to another. This may be an excellent strategy if you can dedicate time to your transition. For example, you could start by moving one or two people from the QA roster into a UI/UX team, and start the new team on a project with small automation features. The number of people you move at the same time will depend on a number of factors, such as the size of your department and how much time you plan to dedicate to the transition.

When moving an individual with a particular skill into a team, be sure to define the minimum expected outcomes in a given period. Open up a discussion with the peers and let them share ideas on what would be the expected benefits of having a new skill on the team. 

Also, work as fast as it makes sense. Moving just one or two resources per sprint might work well for a smaller organization, but if you have 500 people on your delivery team, that pace might be too slow. Be pragmatic!


Reduced resistance to change. When making small team tweaks, the impact is less noticeable, which can make it easier to adopt the new structure easier.

Less risk. Failure on an all-out movement of teams could be catastrophic for an organization. It’s usually better to deal with small chunks of uncertainty/challenges and scale from there.

Learnings are cumulative. What you discover after moving the first few individuals will be very valuable when thinking about the next group to move.

Potential roadblocks and how to work through them:

• If the timing isn’t right or the pace isn’t fast enough, the change initiative could lose momentum and the team could lose motivation. You can mitigate this potential roadblock by using a transition timeline that gives everyone involved enough visibility to the expected milestones and their target dates.

• It can be time-consuming for teams that will need to readjust and go back to the forming stage each time a new member joins the team. You can counter this roadblock by setting a knowledge transfer process with defined target dates, making sure everyone knows the time needed to complete each onboarding process for new team members. 

Strategy 2: All-in approach

In this approach, you create all the teams you need all at the same time. This approach requires heavy investment in coordination and conversations to make sure that each team has all the skills and tools they need by the time they are formed. 

Keep in mind that, even with this single move, you might not be able to eliminate all the dependencies across all the teams. You might have to implement a scaled Agile framework, because the new teams might be too big to efficiently run Scrum or other frameworks. 


• Less time to organize teams. Once you implement the new teams, the moves needed to cover any personnel gaps shouldn’t be very big. 

• It might be easier to establish a regular delivery cadence. If you have multiple teams that are working together, you will have the opportunity to match their cadence more easily than with incremental approaches.

Potential roadblocks and how to work through them:

• Resistance. Massive change is massively disruptive. The message of change must be handled with care within the organization. An all-in approach will likely shake the foundations of personal relationships in your department. There will also be skeptics and resistors. Be prepared to face these challenges and get the support you need in advance to make the transition as smooth as possible. To avoid potential negativity among the team, use open spaces to allow team members to express how they feel about the transformation, and leave them a set proposal to mitigate the challenges they are facing.

• Increased costs at the beginning. Because this approach involves such significant change and impacts so many people all at the same time, you might need support from coaches, you might need training, new tools, more meeting time. A good way to avoid surprises is to work aligned with the financial team, communicate the requirements, and define a budget for all the support you need.  

Strategy 3: Create a few teams first, then inspect, adapt, and grow

Depending on the size of your department, you might consider creating a few fully cross-functional teams initially, maybe between one and five teams. Have them run a few sprints. Learn from those teams, adjust, and then continue forming more teams, until all teams are as self-sufficient as possible. This approach provides a good balance between the risks taken and the pace of improvements, because it is typically faster than progressively moving people from one team to another, and it’s not as risky as forming all teams at one time.

With each iteration of teams, two important things will happen: your risks will decrease, and you can build new teams easier and faster. This happens because your department will have more expertise and learnings based on previous actions.

As you add new teams, make sure you agree between management and the teams on the minimum outcomes expected before deciding to form the next roster of teams. 


Lowers risk and costs. You probably won’t have to invest so much in coaches and other personnel because the teams will coach themselves through incremental knowledge sharing. This also helps reduce uncertainty.

It’s easier to convince people that the change works. You can strategically create a few starting teams that are in favor of the change and highly motivated to make it happen. This increases the probability of the team’s success, and also makes the succeeding teams more confident.

Potential roadblocks and how to work through them:

• If you don’t properly plan this approach, it could end up taking too much time. For example, decide up front how long will you run each new team before forming the next team. You don’t want to wait too long, because this can create distrust and doubt. Be clear and transparent during the process, and keep the team aware of what to expect and when.

• If a group of teams fails on the expected outcomes, you could lose momentum and motivation to keep moving forward. Retrospective is a great key tool here, because both the team and the stakeholders can provide proposals on improving the current performance and learning from previous mistakes.

Successfully transitioning to high-performing, Agile cross-functional teams

When you combine the strategies for building Agile cross-functional teams that we’ve shared here, with good conversations and feedback sessions with management, team members, product owners, and other important change agents, you get a greatly expanded toolbox of organizational and team leadership skills. You can use these skills and your experience building cross-functional teams during many different transformation efforts, especially for Scrum Masters, Agile Coaches, and similar roles. Healthy doses of pragmatism and balanced decision-making will help you discover what is most effective at creating long-lived, high-performing, cross-functional teams that deliver value faster for your organization.


New call-to-action