This chapter is from the book
This chapter is from the book
This chapter is from the book
Increase Cross-Functionality with a Skill Matrix
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 that you must have at least two experts for every kind of skill on 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 (see Figure 8.4).
)
Effort/Impact Ratio
Effort |
|
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, it is also good for morale. |
Steps
To try this experiment, do the following:
With your team, map the skills you need during a typical Sprint. Together, create a matrix on a flip chart 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 plus signs (+, ++, and +++).
When you’re done with the matrix, ask “What do you notice about how the skills on 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 flip chart.
Ask “What does this mean for our work as a team? Where should we focus our improvements?” Let people reflect on this question individually, then in pairs for a few minutes, and then 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 then capture the biggest insights on the flip chart. 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 such as 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 on your team.
You can add people to your team who already have skills that you need. Although a seemingly obvious solution, adding skilled people 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 both people find better ways to support each other. For example, pairing developers who typically work on the front end with developers who work on the back end makes it easier for them to support each other when bottlenecks occur.
You can use approaches such as “Specification by Example”5 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 who 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 emphasize the collective outcomes over individual contributions.