Why the strawberry?
As a kid, growing up in Poland, I used to spend summer holidays at my grandmother’s farmhouse in Wrocław. Even though I was too small to participate in the harvest, I sometimes helped pick strawberries at a nearby field. Some strawberries got more sun than the others, some were lucky to be on the southern part of the bush, while the others were a bit more to the west or north. Each strawberry was unique in this way. Even though most of them reached maturity in late June, some took more time and we could not finish the harvest in one pass.
Your team as maturing strawberries
While some fruits – the most prominent are bananas – mature off the plant (they keep producing ethanol which increases the sweetness and color even in the dark), strawberries ripen only when attached to the vine. This indeed is an organic process and the best you can do is make sure you give them time and space to grow.
I’ve been leading a team of firmware engineers at HP for more than five years, and we have learned a lot about each other, found our areas of specialization and reached efficiency in the internal processes of agile development. But even in the most successful teams people tend to come and go, and the pressure and the demand on the team changes, which leads to knowledge gaps and silos.
Over the years we have been under governance of 5 different TPMs, we had a turnover of more than 20 developers and testers (our team typically stayed around 10 people). Each time one of these changes appeared on the horizon, I made sure we had a smooth transition, whether gathering the knowledge from a colleague that was leaving or welcoming and ramping up a new team member.
But issues (product epics, refactors or simple bug fixes) we were handling required a balanced level of skills within a multi-disciplinary agile team. Sometimes we found ourselves in need of upskilling someone to handle the new workload. This of course required assessing the knowledge and skills of the team.
You can keep track of it in a spreadsheet. But would you?
In Agile teams it’s best to avoid comparison of individual throughput between team members or any other quantitative statistic that puts one in bad light compared to the others. It tends to be a zero-sum game. Being less skilled doesn’t necessarily mean being less productive, and in addition, team members often offer complementary skills and should support each other to achieve a common goal.
There are surely many ways to keep track of the team growth, you can keep the loose notes in the notebook from one-on-one meetings, track the progress of an individual in an annual review process, or put it all in a matrix in excel to quantify the possible personal score.
All this does make sense, but to assess the team as a whole it’s best to create a skill matrix that visualizes skill distribution in an easy-to-assess way. When we started building this skill matrix in our team I wanted to add some color coding to it (excuse me color-blind colleagues, maybe this can still be improved), and I was looking for a metaphor to express the maturity of each of the team members in the areas that we broadly worked on as a team.
One of the well-recognized approaches is Shu-Ha-Ri, a way of thinking about how to learn a technique. The name comes from Japanese martial arts (particularly Aikido), and Alistair Cockburn introduced it as a way of thinking about learning techniques and methodologies for software development.
Three stages of growth
You can read more about this in the blog post from https://martinfowler.com/bliki/ShuHaRi.html, but I’m also including a short summary of the steps for your convenience.
The idea is that a person passes through three stages of gaining knowledge:
Shu: In this beginning stage students follow the teachings of one master precisely. They concentrate on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, they concentrate on just the one way their master teaches them.
Ha: At this point students begin to branch out. With the basic practices working they now start to learn the underlying principles and theory behind the technique. They also start learning from other masters and integrate that learning into their practice.
Ri: Now the students aren’t learning from other people, but from their own practice. They create their own approaches and adapt what they’ve learned to their own particular circumstances.
In relation to our development processes, this translated to the following
As a result I’ve created this matrix in Miro that got popular among managers in our firmware lab:
This gave a very clear and transparent view of the areas that were dangerous knowledge silos prone to creating knowledge gaps. It triggered a conversation about balancing the team responsibilities and creating a path of growth for our team members.
How the growth was directed within the team
It’s important to point out that this chart was created in order to improve an already well-functioning team and not to create a competition for getting the most red labels in the knowledge verticals. This wasn’t a tool either for assigning bonuses or recognitions (although one or two of our team members definitely deserved the “Ripe strawberry award”).
Everyone’s initial assessment was done through a conversation in our one-on-one meetings where we discussed the experience and confidence in each of the areas. Getting an orange label required involvement in the development of core-area functionality during a few release cycles, and becoming an “expert” in the area was usually connected to an important increment of value and being able to handle the technical leadership of a new firmware module.
Finally, everyone had the opportunity to challenge themselves in the area of their choice, establishing the goal for the next period (I typically kept a separate/private board with everyone’s opportunities written down on their cards).
Wrapping this all up,
we had an opportunity to learn more about each other’s experiences, expertise, and do the qualitative comparison of the team skills. Some verticals resulted more balanced than initially suspected, and others required action, which was easy to justify and understandable at a first glance.
In case you’d like to try it out in your team, check out the template I’ve uploaded to Miro and let me know about your experiences and feedback!
https://miro.com/miroverse/team-growth-strawberry-indexskill-matrix
Feel free to contact me on LinkedIn https://www.linkedin.com/in/krzysztof-kucharewicz/