Cross Functional Teams MBABrief.com defines a cross-functional team as “a group of people whose members hold different backgrounds, expertise, and functions working toward shared objectives.” In a traditional waterfall approach, we typically see a series of hand-off teams. Typically, there is a team gathering the requirements, then a team developing a design based on requirements, […]
MBABrief.com defines a cross-functional team as “a group of people whose members hold different backgrounds, expertise, and functions working toward shared objectives.” In a traditional waterfall approach, we typically see a series of hand-off teams. Typically, there is a team gathering the requirements, then a team developing a design based on requirements, followed by the development team building the product based on that design. Finally, there’s a team testing the developed product. Every hand-off slows the process down and introduces risk.
From a Scrum standpoint, teams should have capabilities such as analysis, design, development, and testing to all occur on the same team. Thus we have cross-functional teams. On a software team, there may be team members with backgrounds in business analysis, UI/UX design, coding, and testing. In fact, Scrum moves away from calling team members titles based on specific roles such as analysts, testers, coders, and designers. Rather, Scrum calls these team members “developers.” By calling them developers, it doesn’t mean they are all coders. It means that they are all team members working together to develop the product. A team member might be a developer with a background in UI/UX design, or expertise in testing, or with skillsets in coding. But they are all ultimately developers working together to develop a solution.
Thus, if a Scrum team is behind on the testing, some of the team members with a background in software development can pick up the slack. If they are behind on coding, another developer with expertise in testing, who may not have skillsets in coding, should still have a perspective of how they can help. The ultimate goal is for team members to move away from ever saying “that’s not my job.” By having all the skillsets needed to develop the product on the same team, slowness and risk of having multiple hand off teams is reduced.
Does that mean that each team member needs to have skillsets to do every job on a team? Not necessarily. However, the more skillsets members have, the more and better options the team has to solve problems. If the team members can only do their own niche of work, then the team has fewer options to solve problems.
Here are two quick examples: I worked with a client who had software teams made up of frontend developers and backend developers. On this specific project, it was mostly middleware transactions with some light frontend work. This meant the backend developers were very busy while the frontend developers were not. I talked to the team and asked if the frontend developers could do some backend work. In this case, it turned out that while the frontend developers could technically help, they actually weren’t allowed to. The two types of developers reported to different managers, and their managers didn’t want them to do the other’s work. This project went very slowly until we were able to convince their leadership to change these policies.
On the other hand, when I was a Scrum Master at the Motley Fool, my team was made up of frontend web developers, backend developers, and UI/UX designers. On this specific team, most of the backend developers could do some frontend development. Most of the frontend web developers could do some back nd work and UI/UX work. Most of the UI/UX designers could do some frontend work.
Thus, if we had a lot of backend development for a sprint, the frontend web developers would chip in to help with the volume and prioritize the critical backend work. This cross-functionality at the individual team member level allows the team more options and permutations to solve problems.
Does this mean teams can’t have experts or specialists on the team? Not at all! The concept of “T-shaped” team members is great idea. A “T-shaped” team member means having a team member that is knowledgeable in a specific area, but also has a broad range of skills in others. Your team members may not have this broadness and cross functionality initially, but through training, pairing, mentoring, and coaching, team members can develop these additional skillsets and allow their teams to better solve problems.
By having cross-functional teams, it allows our Scrum teams to quickly deliver value. But by having cross-functional team members, it gives our teams more options on how they overcome obstacles and build their product.