Experiment: Increase Cross-Functionality with a Skill Matrix
In our book — the Zombie Scrum Survival Guide — we dive deep into what causes Zombie Scrum; something that looks like Scrum from a distance, but lacks a beating heart. We also offer 40+ experiments to recover from Zombie Scrum. In this series, we share experiments that either didn’t make it to the book or a selection of those that did and are just too good to miss. Download the paper “10 Powerful Experiments to Overcome Zombie Scrum” to get more inspiration on how to fight Zombie Scrum.
Is your team experiencing bottlenecks because only one person is capable of testing work? Is a developer on your team struggling to implement something that is blocking everyone else until she is done? Do team members start work on unrelated and low-value tasks simply because they have nothing else to do? These symptoms arise when teams are not cross-functional enough, causing work to pile-up for some people and creating delays for others.
The Scrum Framework is built on cross-functional teams because they are better able to overcome the unpredictable challenges that arise when working on complex problems. Your team is cross-functional enough when items flow smoothly through your workflow. Cross-functionality does not mean that everyone can perform any kind of task, or require having at least two experts for every kind of skill in your team. Often, just having another person who has a particular skill, even when they are slower and less experienced at it, already improves flow enough to prevent most problems.
This experiment offers your team practical strategies to help them improve their cross-functionality.
Required Skill
This experiment aims at one of the toughest causes of Zombie Scrum. You may have to deal with resignation and cynicism.
Impact on Survival
Finding ways to distribute skills in your team not only improves flow, but it is also good for morale.
Steps
To implement this experiment, do the following:
- With your team, map the skills you need during a typical Sprint. Together, create a matrix on a flipchart where you plot the members of your team against the skills you identified. Invite people to decide for themselves what skills they possess and to self-rate their proficiency with it using plusses (+, ++ and +++).
- When you’re done with the matrix, ask “What do you notice about how the skills in our team are distributed? What is immediately obvious?” Invite people to reflect on this question individually for two minutes, then for a few minutes in pairs. With the whole group, capture important patterns on a flipchart.
- Ask “What does this mean for our work as a team? Where should we focus our improvements?”. Let people reflect on this individually, then in pairs for a few minutes, and capture the biggest insights on the flip.
- Ask “Where should we start improving? What first step is possible for us without needing approval from others or resources we don’t have?”. Let people reflect on this individually, then in pairs for a few minutes, and capture the biggest insights on the flipchart. Use the strategies as described in the next section as inspiration when people struggle to see possibilities.
- Keep the Skill Matrix in your team room and update it frequently. You can tie it to flow-based metrics like throughput and cycle time, which should improve over time as cross-functionality increases. See the experiment “Limit Your Work-in-Progress” to learn how to do this.
There are many strategies for improving cross-functionality in your team.
- You can add people to your team that already have the skills that you need. Although a seemingly obvious solution, it isn’t always possible. It’s also doubtful how structural this solution really is, as it can cause “Skill Whac-A-Mole” where other skills then become bottlenecks and you have to add even more specialized people. Instead of maintaining high degrees of skill specialization, it’s often more effective to distribute skills.
- You can automate tasks that require scarce skills. For example, creating a backup of a database or deploying a release are critical tasks that are often performed by database specialists and release engineers. When you automate these tasks, you improve not only the speed of the activity, but also how frequently these tasks can be performed, while also removing the constraint.
- You can purposefully limit your team’s Work-in-Progress, putting constraints on how much new work can be started, to encourage cross-functionality. Instead of starting a new Product Backlog item, because there isn’t anything else to do, ask: “How can I help others complete their current work?” or “How can others help me complete this work?”. The Daily Scrum is a natural opportunity to offer and request help.
- You can encourage people to pair on tasks that only a few people can perform. When you pair experienced and inexperienced people, the less experienced people develop new skills, and they both find better ways to support each other. For example, pairing developers that typically work on the frontend with developers that work on the backend makes it easier to support each other when bottlenecks occur.
- You can use approaches like “Specification by Example” to allow customers, developers, and testers to work together to develop automated test cases. In a similar vein, front-end frameworks (e.g. Bootstrap, Material, or Meteor) can make it easier for designers and developers to work together with a common design language for elements.
- You can organize skill workshops where people that are skilled at a particular task demonstrate how they perform it and help others perform it.
Our Findings
- When Scrum Teams have been affected by Zombie Scrum for a long time, they may have come to believe that nothing ever changes. You may even face understandable cynicism. If this is the case, start with the smallest possible improvements to show people that change is possible and worth the time spent making it happen.
- When the skills of team members are narrowly specialized, they may struggle to see how broadening their skills will benefit the team. They may also fear losing their uniquely visible contribution to the team. Make an effort to celebrate the successes of the team to
How Did it Go?
We’d love to hear how it went when you’ve tried this experiment. With your feedback, we can empirically improve experiments, add new ones, and remove what doesn’t work. Let us know in the comments how it went and/or fill in this short feedback form.
Looking for more experiments?
Aside from a deep exploration of what causes Zombie Scrum, our book contains over 40 other experiments (like this one) to try with your Scrum Team. Each of them is geared towards a particular area where Zombie Scrum often pops up. If you’re looking for more experiments, or if these posts are helpful to you, please consider buying a copy.
