Enterprise Agile represents a movement away from the siloed teams traditionally found in Waterfall or Agile 1.0 in favor of cross-functionality. Although cross-functional teams are certainly not a new idea, they’re still something that many organizations are struggling to absorb.

Cross-functional teams optimize flexibility, creativity, and productivity, and have been proven to be the best way to provide on-time delivery of high-quality solutions while optimizing delivery flow and eliminating impediments. Without effective teams, composed of empowered and motivated individuals, organizations cannot achieve the larger business benefits of Lean-Agile development.

What is a Cross-Functional Team?

According to the Scrum Guide, a cross-functional team is a team that is organized around a product, a defined portion of a product, a service, or a customer value stream, and must include all competencies needed to accomplish their work without depending on others that are not part of the team.

These teams deliver products iteratively and incrementally, maximizing opportunities for feedback and ensuring a potentially useful version of working product is always available. Additionally, these teams should be self-organizing, choosing how best to accomplish their work rather than being directed by others outside the team.

Quite simply, your teams need to hold within themselves all of the skills required to plan and deliver the fastest realization of value for a new product or change request, without having to pass their work to others for next steps. This would include code writing, user story elaboration, and manual and automated product testing.

Cross-Functional Team Size

How many people to include on your cross-functional team is an often-asked question to which there is no definitive answer. Each team should include only one Product Owner and one Scrum Master, but the size of your Development Team within your cross-functional team depends on the size and complexity of your project.

The optimal Development Team size is small enough to remain nimble, yet large enough to complete significant amounts of work within each Sprint. Having less than three people on the Development Team decreases interaction and results in smaller productivity gains. Having more than nine people requires too much coordination. A good range to stay within is 3-7 team members, depending on the size and complexity of your development project. Keep in mind that the Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

For large enterprise projects, the typical cross-functional team size is 7 people: one Product Owner, one Scrum Master, and 5 people on the Development Team. For smaller projects, we recommend a minimum team size of 5: one Product Owner, one Scrum Master, and 3 people on the Development Team.

Of course, if you discover that you have too many or too few people on your cross-functional teams, feel free to add or remove team members as needed, but do so at the end of a release sprint and not in the middle of a development cycle.

Roles in a Cross-Functional Team

Waterfall methodologies incentivized a person to stay in their specific lane – BA’s do requirements, QA manual testers manually test, and so on. But when you put those same people together in a cross-functional team, the incentives change. The people on the team are incentivized to be cross-functional and execute on a number of skills so that roadblocks and bottlenecks are cleared rapidly.

It’s important to remember that you still may need some specialists, but by thinking about the Agile team as a collection of competencies and skills, you can focus on sourcing people who enhance and improve your team’s overall process. It’s not about going to the extremes where everyone can do everyone else’s jobs, but about finding individuals who can add value and work well with the rest of the team.

The Product Owner

The Product Owner is responsible for maximizing the value of the product that comes from the work of the developers. How this is done may vary widely across organizations, teams, and individuals.

The Product Owner is also the sole person responsible for managing the Product Backlog.

Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the team will work on next; and
• Ensuring the development team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or involve his team in completing it. However, the Product Owner remains accountable.

The Product Owner should be one person, not a committee. Although the Product Owner may represent the desires of a committee in the Product Backlog, those wanting to change a Product Backlog item’s priority must address the Product Owner themselves.

For the Product Owner to succeed, the entire organization must respect his or her decisions as they’re expressed in the Product Backlog. No one can force the Development Team to work from a different set of requirements.

The Development Team

The Development Team (which can be thought of as a ‘sub-team’ within each cross-functional team) is comprised of professionals who do the work of delivering a potentially releasable increment of product at the end of each Sprint. This cross-functional sub-team is empowered to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

Development Teams typically have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn the Product Backlog into increments of potentially-releasable functionality;
• Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
• They recognize no specific titles for Development Team members, regardless of the work being performed by the person;
• They recognize no sub-teams within the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the team as a whole.

The primary roles that fall within the Development Team are Back-end and Front-end developers, Mobile developers, and Business Analysts, but it is also increasingly critical for an Agile team to include people with quality assurance skills, as well as UX/UI designers.

To create a common understanding across all members, you need to add the context of how and why each capability and user story will be used with graphical models or by leveraging user experience walkthroughs. This ensures that the business perspective, user experience, and customer experience is included in the team’s process.

The Scrum Master

As a member of the Agile cross-functional team, the Scrum Master acts as a servant leader and team coach. They help the team to remove impediments, facilitate team events, and foster an environment for high-performing teams. They also help individuals outside the cross-functional team understand which of their interactions with the team are helpful and which aren’t, they then help everyone change these interactions to maximize the value created by the team.

The Scrum Master supports the Product Owner by:

• Ensuring goals, scope, and product domain are understood by everyone on the team;
• Finding effective Product Backlog management techniques;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and
• Facilitating Scrum events as requested or needed.

The Scrum Master supports the Development Team by:

• Coaching the Development Team towards becoming self-organizing and increasingly cross-functional;
• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and
• Coaching the Development Team in organizational environments in which Agile is not yet fully adopted and understood.

The Scrum Master supports the organization by:

• Leading and coaching the organization in its Agile and Scrum adoption;
• Helping employees and stakeholders understand and enact Scrum, Agile, and empirical product development processes;
• Causing changes that increase the productivity of cross-functional teams; and
• Working with other Scrum Masters to increase the effectiveness Agile across the organization.

Benefits of Cross-Functional Teams

Moving from siloed to cross-functional teams offers great benefits to Agile organizations. If your organization wants to implement cross-functional teams, you should have a good reason for this change that can be easily communicated to the people who may be placed on those teams.

Here are the 7 primary benefits of organizing your Agile teams cross-functionally that will supercharge your SDLC.

Cross-Functional Teams Help Resolve Conflicting Priority Issues

In companies that have organized teams around skill-set silos, any project that requires multiple skill sets will need to involve multiple departments. Typically, different departments will have different sets of priorities and certain departments will, almost inevitably, become bottlenecks.

Conflicting priority issues arise primarily when individuals work on or get assigned to multiple projects at the same time. When one individual is done with their portion of the work, the person with the next skill set in the chain often isn’t available because they’re working on something else. This adds a delay. When the next person does become free, the first person has to switch back to the project in order to brief them, adding additional delays.

Across the organization, many projects are being worked on at the same time. If each of them is taking a little step forward, then waiting, then moving forward or backward depending on the review and the amount of re-work, not only will it add overhead costs, but the product will inch along slowly to a distant finish.

Cross-functional teams eliminate most, if not all, of the conflicting priorities issues because everyone on the team has the same priority: the success of the project and the completion of the next iteration of work. Their loyalties are to the project, not to their department or functional manager.

Cross-Functional Teams Improve Communication and Quality

Coordinating projects across multiple departments requires meetings. In many cases, lots of meetings. Documents and processes like development specifications can introduce the possibility for miscommunication, with consequent quality and re-work implications.

Thankfully, cross-functional teams inherently improve communication and quality of work. A web developer, for example, can develop a deeper understanding of a project if they’re assigned to it and involved in meetings from the beginning. It may seem inefficient to have a web developer or a UX designer sitting in early meetings where scope, customer audience and other important considerations for the project are discussed, but these discussions provide important context. The time “wasted” before the web developer writes code or the UX/UI designer starts providing mock-ups is small – particularly if the team is working in an Agile, iterative fashion rather than a waterfall environment.

Cross-Functional Teams Ensure Consistent Focus on the Customer Experience

Cross-functional teams should be organized around delivering a particular customer intent, action or value stream. This helps the team to remain focused on the customer experience. Although less common, companies still fall into the trap of building products for themselves, rather than for their customers. By organizing teams around the customer experience, they inevitably become the building blocks for creating and delivering greater value to the end user.

Cross-Functional Teams Iterate Quickly

Cross-functional teams can often iterate faster than teams siloed by skill-sets, and rapid iteration leads to testing products early on, receiving direct feedback from customers, and delivering value in the marketplace before competitors.

While siloed teams often find themselves delayed as one or more skill-sets are not available when they’re needed, cross-functional teams have all of the necessary resources and skills to rapidly prototype and deliver minimum viable products (MVPs) themselves. Cross-functional teams also tend to spend less time in meetings than siloed teams, and the people producing the work have the context necessary to understand customer needs and the specific problems being solved.

Cross-Functional Teams Improve Conflict Resolution

This is one of the greatest and most overlooked benefits of cross-functional teams. Siloed teams often spend many hours in meetings trying to reconcile conflicts, each team taking a point of view that often relies heavily on the biases of their formal training. In almost all cases, teams with a full plate of work and tight schedules often have veto power over a project and there is little incentive to work with other teams. With cross-functional teams, people are rewarded not only for exercising their skills, but for the overall success of the project. If the schedule seems impossible or they disagree about a particular approach, rather than just throwing up their hands and going on to another project, they must find a way to resolve the conflict so that the project moves forward.

Cross-Functional Teams Improve Alignment and Use of Resources

One common objection to cross-functional teams is that there aren’t enough people in the organization to form the teams needed to address current problems. Rather than seeing this as a limitation, this should be seen as a strength. When forming cross-functional teams, management is forced to prioritize the most important problems to be solved and the most important customer value streams to be delivered. Teams can work rapidly to solve these problems and deliver value to customers, and then the teams can be re-constituted to address other challenges and value streams.

Organizing by cross-functional teams sends the message that people should spend their time on the tasks that uphold greater business priorities rather than on less important tasks or projects that clog up the queues. This results in a more effective use of time and resources.

Cross-Functional Teams Lead to Greater Innovation

People with different formal training and skill sets often look at a problem in different ways, so including multiple skill sets on your team can often lead to innovation in unexpected ways. For example, a developer working on a product whose audience is other developers may provide insight to the UX team members that wouldn’t otherwise be available.

As well, there is some scientific research that confirms that cross-functional teams are more innovative. Rajeth Seshi and Daniel C. Smith studied 141 cross-functional product development teams and found innovativeness was positively related to the strength of the team-members’ identification with the team, encouragement to take risks, customer influence, and monitoring of the team by senior management.