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.
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.
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.
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 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.
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 (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.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
