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.
Good one!
Hi Henrik!
A really good idea, thanks for sharing it. Do you have any tips on how to find the competence areas to map? I have done a few “competence mappings” in my time and it’s really hard. For your example, the column “Web” could just as easily have been divided into “Dynamics/JS”, “Graphic design”, “HTML/CSS”, “Web fw”, “Availability”, and “Interaction design”, just to name a few. I think a lack of skills in any of these areas would seriously hamper the speed/quality of this project.
Anyway, I think the exercise is really good and worth doing. I’ll try it out. Cheers!
I usually let the team choose whatever skill areas they feel are most relevant (or most likely to be problematic). If they get too detailed it becomes quite obvious, since there will be too many columns. So sometimes we iterate a couple of times through the list of skill areas until we get a reasonable number of columns (4 – 8 usually).
A nice simple idea.
Perhaps even more powerful if you go one step more. Who do each of the team know who would be happy to help them learn?
A team of six turns into thousands of experts pretty quickly with a little imaginative use of social networks.
Great idea Ed, thanks! Although I’d probably wait with that second step until the team actually actually identifies a weak spot, so that we don’t accidentally waste time trying to solve hypothetical problems. In the example above it’d be a great idea for the team to follow up by listing people they know who are good at DB.
Yes agreed.
On the non-technical (most important) front I would encourage the whole team to seek out domain experts though (particularly Jenny and Lisa in your hypothetical team). Nice to have David on the team to teach and validate what they learn.
Personally I don’t like anyone on an agile team using their technical skills until they fully understand the business problem they are trying to solve.
This could also be a useful tool for self development and for future project staffing choices too.
To start with, it helps team members identify useful areas they may wish to improve on. Not just for the companies sake, but to make their own life more interesting.
Then, if the project managers need some real high level skills in certain areas they also know who to call on.
Regards,
David
http://www.jacksguides.com
Great exercise I will as soon as possible test it on the team.
Thank you for sharing.
/Michael
This is great Henrik … this reminds me of a skills matrix that I saw when using Lean in the office at a health insurance company … part of lean operations is to foster cross-functional teams so that a lot of people could (in this case) process a claim without having to hand it off to another specialty. The matrix was a very large andon and acted as an “action plan”. It differed slightly in that team members evaluated themselves across many different processes and gave themselves a ranking from 1-4, however the spirit of what you describe here is the same … thanks for sharing this with the world!
Got pointed to this post today. This is a useful technique to remember. One small gem in this post that is worth pointing out is the title of the diagram, “Skills Needed to implement top X Backlog Items”. To me this signifies that whenever the top X backlog items are implemented you should review your list of skills ask the questions: are all skills still relevant for the next top X items? Are any new skills needed for the next top X items?
Very good point Mendelt, thanks for pointing it out!
Hi Henrik,
I think you need a lot of trust in a team to fill out this file.
I tried something similar with a team on knowledge of their own (large) program. It did not work, now I think the trust was too low in the team to actually fill out the fill truthfully.
Interesting. Did you do it in a file, or did you do it together in a room with a whiteboard? So far I have only tried this with moderaly small groups (10 people at most) in a room with a whiteboard. Worked well, in that it triggered interesting and valuable discussions. But I can imagine that it might not work as well in a low-trust environment. I wonder if there is any damage in trying though.
A very good visible drawing! Sometimes obvious things needs to be visulazied in order for real use to be retrieved from those facts. It must also be good for the team member itself to aknowledge where he/she currently stands. For testing this is a great drawing. A testing person needs to be very detailed and needs to like to find problems. A person who doesn’t like to find problems, like myself, will not be any good tester, since one is more likely to only test normal cases. Good post.
You know what first came up to my mind when reading this? Have these imaginary people ever met each other before? Do they communicate in any other manner than hello? How come that to get to know people you’ve been working with for like years you need to draw some table? In this case the knowledge of your team head is also a bit stunning, there is no such.
I am sorry guys, its just in my opinion that your team either knows each other much better than through stars and dots or they will never be able to see around as they have no will to do so. You may of course force them with this bright functionality. Good luck with that.
Great article
I have one question. Why not dividing the dot in a dot and a circle? This way you could distinguish between ‘can already contribute’ and ‘willing to learn’.
Great idea 🙂
I just wrote an article taking this approach to the “Team of Teams” / “Agile Release Train” level while mentioning this great article.
http://yuvalyeret.com/safe-agile-release-train-flexible-enough/. Let me know what you think.
Thanks for your valuable insight! I shared this with my team and tweaked the ratings slightly.
Star – This is my main skill area. I can be a Mentor in this area.
Dot – I know a bit of this, enough to contribute.
Check – I don’t know this now but can learn and am willing to do so. (NOTE: I can mentor someone who’s interested in my main skill area in exchange for mentoring me on this skill)
Empty – I can’t or won’t do this at all.
Looking forward to promoting cross-functioning in my scrum Team!