A team is asked to take on a special project but they feel uneasy because they lack all of the skills necessary for a successful outcome.
Have you experienced that problem before? Perhaps a Skills Inventory could help.
This is a skills inventory I helped a team create in the past (I’ve redacted their names for anonymity):
Background
There were two teams that would be pioneering the inclusion of some new technologies into their website. They needed to make the site responsive/adaptive, older Java technologies like Struts 1.1 were preventing the move to HTML5 and were going to be removed and replaced with mostly Spring technologies. They wanted to use some of the practices of TDD, BDD, and automated UI testing. Even the old Ant-based build system was being replaced with Gradle. The mood was pretty gloomy and weighed down with so many things to learn and the number of unknowns they had. It felt more like they had been set up to fail than to succeed. They had taken a basic Spring course but hadn’t applied any of it on a project yet. I suggested we create a Skills Inventory and create a plan for how they would handle so many of the things they needed to learn. After we finished the atmosphere was notably lighter. Everyone knew there was work ahead, but they felt like they had an approach to conquer it.
Checklist
Here is a checklist for how to create a Skills Inventory. I’ll elaborate each step below:
- Get the entire team together
- Make safety a prerequisite
- List the new/additional skills or technologies
- Explain the scale
- Team members self-rate (can be done in parallel)
- Find volunteers to “scout” ahead of the team and bring back learning
- Make everyone aware of who the “experts” they have in the room (and outside) are
Get the entire team together
I’ve only ever done this together as a whole team. It’s important to have the whole team present. A team often knows more than it thinks it does. Team members have additional skills or knowledge that the team as a whole doesn’t know about. You want these to be discovered.
Make Safety a Prerequisite
A team in a situation like this one can feel a little edgy. When emotions are running high, it helps to make alternatives and options as visible as possible and assess them objectively.
Depending on the organization and environment, it could be a bit sensitive to ask the team members to rate themselves. In reality, I haven’t had a problem so far as it has already been recognized that they have no expertise in these areas, and this is an attempt to do something to help. So, this step moves along quickly, but I always introduce it and ask if everyone is comfortable with it. By the way, I don’t include things which they already know. This was a Java shop, I didn’t list Java.
List the new/additional skills or technologies
This can be gathered ahead of time or done at the meeting. Create a list of the notable skills, practices or technologies which the team has concern about or are lacking for the mission at hand.
Explain the scale
Personally, I hate reinventing the wheel. I’d rather use an already validated mechanism than try to create my own. In the field of software development skills assessment, I use the Seven Stages of Expertise in Software Engineering by Meilir Page-Jones. It’s a 7-point scale. I summarize it for the team this way:
Expertise Scale
- Innocent – may have heard of it
- Exposed – can use it correctly in a sentence
- Apprentice – has tried it, or taken a class
- Practitioner – has used it successfully on a project
- Journeyman – uses it all the time, or on multiple projects, can mentor
- Master – teaches it, transcends rules
- Researcher – writes books, conferences, etc.
Team members self-rate
Let the team members self-rate. In the photo, I put everyone’s name at the top of a column and they filled in the table for their name. With enough dry-erase markers, this can be done in parallel. Whenever self-assessment comes into play, it’s good to consider the Dunning-Kruger Effect (Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments).
For scores of 1 through 3, we’ll be treating them all the same (as unskilled). For the scores of 4 and 5, we are really asking about whether you’ve completed a project successfully with the item (4), or whether you use it all the time or completed multiple projects with it (5). So rather than asking “are you an expert,” we’re simply asking, “how frequently have you used it.” For ratings of 5 or higher I treat them as a 5 (skilled). The risk is believing you have an expert on the team when you don’t. This should surface rather quickly, or create backup scouts in the next step.
Find volunteers to “scout” ahead of the team and bring back learning
Once the skill inventory is completed, it should give the team information to decide how to tackle their problem.
The approach I’ve taken is to ask for volunteers to be the “scout” for a particular item. A scout’s job is to take point and scout out ahead of the team and spend time learning their particular item. Often a few hours spent by a scout can be distilled into a few minutes that are relevant in the context of the team’s application. Try to route all questions through the scout and if they don’t have an answer and someone else tracks it down, let them know the answers too as they’re discovered. You’ll be growing an expert this way. Eventually, everyone should level out and gain expertise in everything needed, but while your team is still mostly in the dark this strategy will help them make progress. With this divide and conquer strategy each scout takes the hit on learning a different item and brings back the distilled ideas to spread across the team.
In the picture above, the first and fifth columns were Tech Leads on their teams. The second tech lead loved new stuff and volunteered to take on quite a bit. A (5) on the table indicated the team already had a skilled person in that area, indicating them as a scout wasn’t really necessary, sorry for the inconsistency. The sixth column was a developer new to the team and somewhat shy. The reason for duplicates was they wanted a scout on each team.
A quick note about Mob Programming
I used this technique before I learned about mob programming. I’m now a huge fan of mob programming, and would highly recommend it. Among other things it has a huge leveling effect for getting the expertise from one (or a few) team member’s head spread throughout the whole team. It lifts those without expertise very quickly, and it can’t be beat for onboarding new members. Although when no one in the room has a clue about something, it’s not a stellar experience to all read a tutorial together and smacks of duplicated learning. In a mobbing situation, it’s best to have an expert (stage 5 or above) to come mob with the team to transfer knowledge. In the absence of an outside expert, I’d still have scouts concentrate on their particular topic when outside the mob, so they can share it when in the mob.
Make everyone aware of who the “experts” they have in the room (and outside) are
On the completed table I circled the intersection of a person (column) and an item (row) to indicate that person volunteered to be the scout for that item. It is helpful to also list “outside experts,” skilled people outside of the team, who could be used as a resource when needed. It’s good to have your scout along when talking with an outside expert.
Conclusion
Having the necessary skills is critical for success, teams are ideally equipped with stage-5 team members. If you don’t have it, you’ll need to cultivate the expertise. When birds fly in a V-formation the lead bird has it the hardest, but its efforts make it easier for the rest of the flock. Until everyone has gained the necessary expertise, and rather than everyone having to struggle with everything all at once, it’s helpful to have volunteers each take point and focus on an area and share with each other what they’ve learned.
Links:
Seven Stages of Expertise in Software Engineering by Meilir Page-Jones
