A skills backlog with a capability table

I wrote an article a while ago, suggesting that it is a good idea to invest in the growth of our crew. I promised at the time that I would also explain the concept of a “skills backlog”. Now, several months later, I thought I would write the promised article.

The approach is quite simple:

• Identify the skills you want to improve; and
• Continuously work on improving them.

We have already looked at some ways to identify areas for improvement, which is nice, but I have found that I often get really busy after that and seem to focus on anything but development.

So let’s steal some basic agile approaches that translate fairly easily into continuous (human) development.

Level 1 – plan to improve

Some teams grow stale and lose resilience over time because they are too busy surviving to think about their own development. This is clearly bad, so a simple antidote is to add a question to existing planning sessions:

“What opportunity do we have here to spread learning through the team?”

Many teams who want to enjoy their work

For example in sprint planning, instead of allocating the stories to people who are the most experienced in each type of story, lower your velocity by 0.00001 story points in order to allocate a story to someone else and then allocate the experienced person to peer review the work or practice coaching them.

Along the same lines, if someone reports a blocker in a stand-up then just ask whether there is a chance for someone to teach them to tackle it rather than just clearing the way.

Even in story splitting, backlog refinement or “the cup of tea we should have before starting,” look at breaking down the work so that people share knowledge or learn new things.

Learning is now happening by default rather than “planning to avoid learning.”

If you implement this simple change to your team then you will have already achieved maturity level 1 in people development. Well done.

Level 2 – Leverage existing meetings

I sometimes joke that people do retrospectives as a kind of fortnightly therapy session, where they all talk about their issues and express empathy for one another then forget to do anything about what they have been discussing. That way they can come back two weeks later and have, essentially, the same discussion.

Instead, I hope that most teams agree to some action in their retrospective and then take those actions into the next sprint planning session and prioritise the improvements against other work.

The same can be done with skill and capability growth.

• Identify areas in your retro that suggest an opportunity for someone in the team to learn;
• Consider tweaking your story wall to dig further into areas that can be improved; and
• Take the outcomes of these into your planning sessions as separate learning activities.

If you like you can evan word the learning as user stories, where members of the team are customers

• As a new BA I want to watch the original blade runner movie so I understand the obscure references and lame attempts at humour that the team rely on for bonding
  • Given someone says something, when everyone laughs then I will be confident that I am not laughing because their humour is lame rather than because i don’t understand the reference
  • Given I want to live, when I see origami animals lying around the office, then I will know whether to be worried
• As a Front-end developer I want to pair program on the backend java thing so that I understand how to code without cutting and pasting things off the web
• As the MQ Series legacy guru, I want to transfer the knowledge of asynchronous channels to the other developers so they stop asking for my help when messages don’t appear

Now your team is level 2 – it doesn’t sound very mature but you are outperforming many other teams.

Level 3 Learn deliberately

Some agile teams sprint around happily focusing on the work due this week and wait until the next sprint planning session to discover what needs to happen next week.

Others manage a backlog or roadmap of work so that the team is confident that it is moving in a desired direction and many of these teams use epics (big stories) or a plan on a page to clarify the goals that will not be achieved this week.

The idea here is that, instead of just planning what to learn on a weekly basis, you can come up with some longer term goals and then split these into stories or goals for each sprint.

This works pretty well and you can simply add some “epics” to your backlog, where the epic is really a learning goal for the team. You can create these epics by conducting a needs analysis on the team, as I referenced at the beginning of this articel.

One approach I find useful though is to employ a tool known as a capability table. This is where you identify the things you need to be able to do in order to deliver value to customers. Some people include a capability in their “story hierarchy” as kind of a big epic or, I guess, “saga.” Others, often process engineers, use a capability as a generic thing that requires improvement.

Enough explanation though – here is a capability table:

Capability	Current state	Desired	Gap/opportunity	Improvement options
Team coolness	Team is not cool	Be at least cool enough to have people say hi in the cafe	Lack of generic conversation skills	– Watch Blade Runner – Watch Princess Bride – Attend course on listening – Purchase enough T-shirts to wear a clean one each day
Defensive coding	Team passes PCI Audits with minor changes. Architects review code when relevant releases occur	Team confident that they are coding to protect against predictable threats prior to audit	Team lack an understanding of attack vectors and threat patterns	– Purchase static test tool – Complete our own research on OWASP scary thing – Hire outside guru to train the team
Ticket handling	Processing 80% tickets in 5 days and 95% in 20 days	Process 95% of tickets in less than 1 day	Lack of knowledge of existing problem patterns	– Brown bag sessions – SWAT team to tackle any tickets over 2 days – Just promise management and hope we are lucky

Next, you prioritise the capabilities that you will improve first and then assess the options. In this case the team might choose “team coolness” as the most important capability gap and review the options that can be implemented.

During their next story slicing session they agree that they can drop one feature from each of the next two sprints and instead watch Princess Bride in the coming sprint, watch Blade Runner the following sprint and then reassess their coolness before deciding to increase their wardrobe to allow the wearing of clean clothes each day. They might then continue on this journey or switch to a focus on defensive coding in the next sprint instead.

Having done this the “learning activity” simply enters the kanban wall or sprint planning session as would any other work.

If you can do this, then I would rate you as “level 3” in people development maturity and I would also certify you as a team worth recommending to people, subject to some identified wardrobe improvements that have already been identified.

To move to higher levels of maturity takes a little more work. You will need to:

• Review the learning on an ongoing basis and assess whether it is paying off ;
• Do a little more research to learn where your team might find its best opportunity for growth; and
• practice some succession planning and forward thinking.

I don’t think any of these maturity levels is unattainable, I just think teams are too busy focusing on other things, like building value for others. Hopefully you and your team will find these approaches useful, or find other ways to invest in yourselves. I promise that the pay-off is worth it for you, your organisation and your clients.