Cross-training charts (also skill training charts) are a standard part of the Lean toolkit. They are used to identify limited skill sets that can lead to bottlenecks and work stoppage. See manufacturing example.
In Scrum (and some Agile), we have the notion of cross-functional teams and place value on generalists who can go where the work is. Cross-training charts can help get you there.
Technology and Domain skills
When helping teams assess themselves, I separate technology skills (who knows a library or tool) from domain skills (who know the frazzit module). Once teams do this, the lightbulb goes off – “Oh that’s why it takes so long when we need to do work on the frazzit – only Bill knows it and he is busy with other stuff”.
On the left is a legend I have used with a couple of wiki-enabled clients to track the matrix. (Excel works too and has a nice colouring feature under conditional rules but is less visible.
Consider the example cross-training matrix below for the developers. (QA, BA important too, but they have different technologies/skills). Across the top we have the names of the developers. As you can see, on the front end, they have an OK idea how to use SpringMVC and JSTL; there are no experts, though, so it may not be clear what their frame of reference is. Sometimes people don’t know what they don’t know. Very limited experience with UXD (User eXperience Design) which may be an area for attention depending on usability goals for the product.
What about the domain matrix? Well, it looks the same but with areas of the application outlined at an appropriate level of detail. You can put the whole team (not just dev) on this one.
Lottery/Truck Factor – Are you managing your risks?
Truck factor is about how many people on your team can be hit by a truck before you can no longer effectively support a piece of software.
The cross-training chart can be used to assess how well management is managing risk. Usually what I see is “not at all” and the result shows in terms of deteriorating code quality due to departures and growth.
How to spread knowledge?
There are lots of ways. My favourite is pairing. I also like to impose a limit on publicly declared learning goals – just pick one thing to learn at a time to provide focus.
My suggestion: give your team time to share knowledge and let them decide h0w they want to do it.
Footnotes
- I keep talking to people about this so I thought I had better post on it. Most recent discussion was at a session at Agile Coach Camp in Waterloo.
- See complementary practice of Timeline and Marketplace for understanding other team members.
