What Cross-Functional Teams Really Are
Cross-functional teams are a core component of agility. The idea is baked into Scrum and Extreme Programming, two frameworks that were developed before, and ultimately contributed to the creation of the Agile Manifesto. The cross-functional team concept is often misunderstood, so what does it really mean?
It’s commonly misunderstood that the term “cross-functional” refers to the skillset of a person, themselves. With this mindset, as a leader, you would want all your developers to be cross-functional with expansive skillsets so that they can work on anything handed to them. You’d be right to want this. You can pivot the team to work in a new space because they’re all cross-functional. And anyone on the team can work by themselves on anything queued up for the team. It’s an ideal situation but, unfortunately, unrealistic. And it’s not what is meant by the term “cross-functional teams.”
So, what exactly does “cross-functional teams” really mean? It’s not about cross-functional people; it’s about the team itself being cross-functional. A cross-functional team is a true team like your local sports franchise. They aren’t simply a group of people reporting to the same manager. Each person on the team has a position to play. Consider a professional sports team comprised of different positions that work together to achieve a common goal. Each player has unique talents that combine with one another to create a more powerful unit. This successful cohesiveness is a result of a cross-functional team model. The same goes for a cross-functional corporate team. Each person on the team has their own strengths and interests that are unique however, some of those strengths and interests will overlap with other team members, and that’s okay. It’s alright to include some of the famous “T-shaped people” on your team that have deep experience in one specific area and some experience with many other things. Still, they’ll eventually run up to their limits, and this is where the rest of the team steps in to fill in the holes. Everyone works as a team to get things done–each member plays their part and collaborates where they can.
Let’s look at an example of a cross-functional team that works on a web application. There is a UI/UX designer that keeps usability at the forefront for the team and may be able to implement their designs in code or participate in exploratory testing. There is a front-end developer that is seemingly a wizard at coding styling, slick interactions, and responsiveness to different devices. There are two full-stack developers that can work from top to bottom in the tech stack the team is using and have experience with other technologies. They can get assistance from the front-end developer on their more challenging front-end problems or pair with them to expand each other’s skill sets. There may be a back-end developer that is very experienced with databases and writing code to interface with them that frequently works with the other developers to get work done and share knowledge. And there are most likely a few people focused on exploratory testing that can also help developers think about how to write tests for their code and help with various levels of automated testing. All these people work together to get work done without delay, share their knowledge, and support each other. Pairing team members to support each other is an essential component of cross-functional teams and necessary to avoid falling into. A key thing to avoid is being in a long-term situation where there are some things that only a single team member can do–encouraging pairing on these efforts is a great way to resolve this over time.
Now let’s think about a situation where you have a similar team, but they don’t have a designer on the team. Is that a problem or not? Is the absence of a designer on the team problematic? It depends on the team you have and the type of work they’re doing. Perhaps you’re in a rare case where the rest of the team is highly skilled across disciplines, and they can do all their own design work. You may be in a more likely scenario where the team still needs to work with designers, but they can get by with them being an external dependency without introducing delays into the work. But maybe the team’s progress is consistently impeded because they don’t have a designer on the team. This is the signal to know that you need to invest in bringing that discipline within the team. Developing your own teams into cross-functional teams works just like this. Identify the skills the team lacks that introduces delay into their delivery of value and bring those skills into the team or develop them within the team through pairing, ensemble development, training, or other methods. Team retrospectives are a great forum for surfacing these needs.
The skills needed to create a cross-functional team are different depending on the team’s each situation. The goal of a cross-functional team is to have the skills within the team needed to complete work that aligns with the team’s mission. This limits dependencies on other teams and the waste and delays produced by coordination across teams as well as handing-off work. The team can complete a piece of work by themselves instead of hoping another team can schedule their part soon, wait for it to be done, then take time having the other team explain it before work can be started–and then possibly having to pass the work off to another team before it can ever get into your customer’s hands. Once you’ve seen the power of a truly cross-functional team, you’ll never look back.