The term ‘Cross-Functional teams’ is closely associated with Agile. A cross-functional team has individuals possessing a variety of skills to get the work done. In a team, there can be an individual who will test, code, analyze, do documentation, and so on. Though Scrum teams are cross-functional and self-organized teams, it doesn’t mean that each and every individual in a team has all of the skills.
You can define a Cross-Functional team as a team of cross-functional individuals with various characteristics and domain knowledge. E.g. if any team member is making a sprint cycle weak, team members with sound knowledge can club and work with the other team members to finish the sprint on time. In any case, it isn't compulsory, and Scrum does not direct that each person on the team must be cross-functional.
A Cross-functional team is often referred to as a ‘Self-contained’ team. The thought of the cross-functional teams is contrary to the idea of having separate teams of coders, analyzers, testers, document writers, and so on. In separate teams like these, each of such teams focuses on a small set of skills. Since most Scrum teams can't be totally cross-practical, the team frequently needs Subject Matter Experts (SMEs) or Specialists to assist.
Specialists are accepted in the Agile teams as a lot of productivity can be gained by the teams instead of just having a single person doing everything in a team. If any team consists of one individual who is superior in a certain task, then that person can carry on doing the same in a more advanced way. He or she doesn’t need to learn the other tasks mandatorily.
However, since Agile is an incremental and iterative approach, specialists can cause problems for such teams. Sometimes, they make it difficult to maintain a balance between the types of work done by the team. Suppose, a team has a worldwide famous Java developer. How will you make sure that with this member of the team and your team will actually perform the right amount of work and bring an accurate outcome in an iteration?
Let’s understand this with a few examples. Consider there is a team of four individuals where each team member is a Subject Matter Expert (SME) or Specialist. Individuals 1 and 2 are the coders and know only coding. They are indicated by the orange squares along with the coding icon in the diagram below. Individuals 3 and 4 are the testers and do only testing. They are shown in a grey square with the testing icon.
Figure 1 shows the four individuals capable of finishing 4 tasks (in orange) in one iteration and 4 tasks (in grey) in another. They can’t perform more than those tasks. But, if their tasks are distributed in two product backlog items, as presented in figure 2, this team will be finishing those tasks in one iteration.
But any distribution of task split unevenly will be difficult to finish for this team. This indicates that the SME team of Figure 1 would be unable to complete the work in any of the distributions, as shown in Figure 3.
Now, consider the two of the Specialist team members of figure 1, are able to do both coding and testing tasks. Such team members can be referred to as Multi-Skilled team members. Also, sometimes they are called ‘Generalists’. But, this prompts confusion among the team members. It is sufficient to have a team member or two having several skills a team needs instead of having all of the skills.
Figure 4 represents the multi-skilled team. Individuals 1 and 2 are specialists and can perform only one type of task. But now, Individuals 3 and 4 are multi-skilled and each can either do the orange or grey task.
This team (multi-skilled) can complete many more tasks than the Specialist’s team of figure 1. Figure 5 below represents all possible distributions of the tasks that can be implemented when two multi-skilled members are added to the team.
The team will finish any task distribution (except the tasks that require 0 or 1 unit of either skill) just by replacing a couple of SMEs with multi-skilled individuals. Mostly, the teams can avoid the jumbled product backlog items by simply choosing the product backlog items carefully. In this example, if the first chosen product backlog item is ‘Heavily grey’ then it is recommended that the team should not pick another similar item.