In the Agile and Scrum classes that I teach, one of the topics that seems to cause a fair bit of stress, or at least, more than it should, is Cross-functional Teams. The stress tends to be rooted in a misinterpretation of what cross-functional means.
So first, what it doesn’t mean is that everyone on the team has to have the exact same skill set. That would probably make finding people to work on the teams pretty tough. Everyone has things they gravitate towards and develop a certain amount of expertise in. Finding a really talented graphic designer who can code like Neo and is still willing to write documentation is unlikely. But we still want to have a team of people who have some ability to help each other out.
When I think about these things I sometimes find it helps to consider it outside of the context of Agile and Scrum.
Example 1: The A-Team
In 1972, a crack commando unit was sent to prison by a military court for a crime they didn't commit. These men promptly escaped from a maximum security stockade to the Los Angeles underground. Today, still wanted by the government they survive as soldiers of fortune. If you have a problem, if no one else can help, and if you can find them .... maybe you can hire The A-Team.
In the A-Team, everyone has a role:
Hannibal – the Planner and Visionary
Face – The Master of Disguise (and Social Engineering)
Murdoch – Pilot of anything that can fly and team Wildcard
BA – Wheel Man and Muscle
Now, BA hates Murdoch. Actually, that’s not really true. BA pities the fool. He does not trust Murdoch because:
1) Murdoch is certifiably insane
2) BA hates to travel by air.
So, every time they have to fly, Face or Hannibal has to slip BA a mickey finn or a needle and put him out. While he out, they travel by air. When they land, someone has to drive. This role typically falls to BA because it is his primary area of expertise. However, if BA is still knocked out. Someone else has to drive. The other team members do not necessarily have to be as good at driving as BA, but they have to be able to drive well enough to get from A to B and possibly evade some law enforcement along the way.
Example 2: Ninja Baker Priest
Let’s say you have a team comprised of a Ninja, a Baker and a Priest. As part of the work they have committed to for the Sprint, they are responsible for taking steps which will result in the death of Mr. X. Since the team has a Ninja on it, this should be no problem at all. But what if the Ninja comes down with a terrible case of the sniffles. He (or she) can’t exactly be a silent agent of death if they have to stop and blow their nose every 5 minutes.
So, the team has a meeting and discusses the situation. It is agreed that the Ninja should stay home, have come chicken soup and try to get better. In discussing the work, the Priest and the Baker agree that between the two of them, the Baker has the most experience with knives, so he agrees to head out and complete the contract on Mr. X. The only catch is that the Baker also had work to do. Fortunately, the priest has been well trained and has been known to be able to do some pretty cool stuff with Bread too, so he will help the Baker while the Baker is helping the Ninja.
So, the idea of cross functionality is that the team has or develops the ability to help one another when they need to. It is not that everyone on the team develop the exact set of skills. Once they have made a commitment, they are responsible for meeting it. If everyone on the team has a specific skill set that is not shared, a smart team will take some tome pairing or cross-training to remove single points of failure.
This is just a simple explanation. For me, these kinds tend to work the best. If you’d like something that digs a little deeper on this topic, I’d recommend checking out Heinrick Kniberg’s post on Crisp.