Cross-functional team doesn’t mean everybody has to know everything – this seems to be a common misinterpretation though. Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.
Are you unsure if your team is cross-functional enough for the product they are building, or are you sensing a lack of teamwork? Here’s a useful workshop technique (with a slight teambuilding effect as well):
Get the team together and bring the product backlog. Ask the team “what are the main skill areas needed to build this product?” and list the skill areas on a whiteboard or flip chart. Then give each person a pen and ask them to rate themselves within each skill area.
- Star = I’m good at this, or this is my main skill area.
- Dot = I know a bit of this, enough to contribute. Or I can learn and am willing to do so.
- Empty = I can’t or won’t do this at all.
This usually triggers valuable discussions and insights such as:
- Joe: “Looks like we don’t have as much of a specialist problem as we thought!”
- Lisa: “Yeah, I didn’t even know Jenny could code Java!”
- Jenny: “Well, I’m not too good at it but I have some personal hobby projects and I really would like to learn more! I’m sure I can contribute as long as I don’t have to do the hard parts.”
- Joe: “I thought I would be a real bottleneck as DB expert, but now I see that Lisa could help me with some DB stuff!”
- Lisa: “Yeah. Java is my main skill but it seems I’m the only person other than you that could do DB stuff, so I should probably spend more time helping you with DB work instead of just coding Java.”
- Joe: “DB knowledge is still a potential weak spot for us as a team though, so I’ll talk to the product owner and look ahead in the product backlog a bit. If we see DB intensive stuff coming up it may be worth getting another DB-skilled person on the team, or at least giving us access to a contractor for a sprint or two.”
- Erik: “I really hate testing, really suck at it, and am not interested in learning more about it. So I’m really happy to see that the rest of you guys are willing to test, now I don’t feel as bad focusing on my other skill areas instead.”
It may even trigger the insight that this team is incorrectly staffed for the product being built. That’s extremely useful to find out early!
A good rule of thumb is that each column should have at least one star and one dot (or two stars). That means we have at least one guy who is good at that job, and at least one additional person who can help out when needed. And the team won’t be completely helpless if the star person gets sick or hit by a bus.
I like this exercise because:
- It’s quick & easy.
- It triggers valuable discussions.
- It helps visualize the team’s strengths and weaknesses.
- It encourages teamwork (“how can we help each other succeed”)
- It counteracts pidgeon-holing (attitudes such as “I’m the Java guy and you’re the DB guy, so the DB stuff is your job!”).
- It helps people get to know each other better.
- It takes into account the fact that people can (and often like to) broaden their skills.