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.

At Agile 2009, Mary Poppendieck presented on “Deliberate Practice” – how people become experts. The video and slides are available from InfoQ.

Consider the fifth value statement proposed for the Agile Manifesto by Bob Martin:

Craftsmanship over Crap

This presentation follows in the theme craftsmanship – How do we as a community bring it about?

The answer given in this talk is we need to consider what it takes to develop elite level skills in other professions – deliberate practice.  Consider the visual note below:

It seems to me that virtually every company I have every worked for or with has done virtually nothing to bring about excellence in technical (or other) skills.  Imagine what the world would be like if companies viewed their employees as assets and invested in them with mentoring and challenges so that they get deliberate practice.  This requires companies to think about Production Capability and not just Production.  More than just thinking about hitting the deadline.  This is an essential component in build lasting success.

Ever heard of this crazy-sounding approach called eXtreme Programming (XP)? Maybe they were on to something.

Jared Spool gave a pretty good banquet keynote for Agile 2009 on User Interface Engineering.  The main point is that is that very successful companies use amazing interfaces as a key competitive advantage.  And the key to this is good user experience design.

Case and point is Apple.  We watched an Apple video from the 80’s that showed Apple’s vision for the future of the computer (funny/sad was a plot element so long ago was about global climate change).  Everyone at Apple knew what the vision was and could explain it.  So what this means is that everyone is thinking about the long-term vision.  Every time they have a choice to make on design they can take a step in the right direction so that the future can be achieved in part through many many tiny shifts.

Good design is INVISIBLE.  NetFlicks is destroying their competition through a ridiculously high net promoter score (how likely someone is to refer a friend).  No one ever mentions their Web UI even though it rocks – it’s invisble: It does what it needs to and it’s easy.  How do they do it?  In part through a culture of excellence – employees are the top priority and the CEO puts this ahead of board meetings.  To support this they hire fast and fire fast.  They also pass the culture test.

How do you learn good user interface design?  Mentoring!  Good designers know what good design is, but cannot explain it.  Like chicken sexing.  (Makes me wonder how much we are kidding ourselves that good design can simply be taught through patterns or what not.)

The company test is a recipe for successful cultures.  All the companies with awesome user experience met the test even though they were radically different in many ways.

The last point about celebrating failure is critical.  If people are not making mistakes, then they are playing it safe.  And if they are playing it safe, the result is mediocrity not excellence.  There is a similar field of thought around innovation – it also requires support for failure.

If you need help building better UI, start with #2 – spend some time observing your users and then make it better.

Here is the Visual Note (see earlier blog) of Alistair Cockburn’ Keynote talk at Agile 2009.  His main intent is that as Agile is becoming mainstream we need to look at some of the larger issues of software development such as large teams, distributed, etc.

Alistair followed on Last Years Key note speaker Bob Martin in talking about Craftsmanship as a key approach in considering all the different skills needed in software development.  He also spoke of developmental learning levels Shu-Ha-Ri that are key to a mentoring approach.  This is also very relevant for coaching.

I strongly encourage you to watch the video or check out the slides.