Agile development teams are cross-functionally diverse and sufficient. They are comprised of team members that collectively have the skills to get the job done. But how do teams deal with the variability of the work they are asked to do from sprint to sprint? For example, what if in sprint one the user stories require a bit more UI work, whereas in sprint two they require a bit more database work? How do we deal with this variability?
There are at least three options we could consider:
- Recompose the team (swap in and out team members) each sprint to ensure we have the proper set of collective team skills to work on the high-priority items that needs to be done that sprint.
- During sprint planning, have team members purposefully select items from the product backlog to create a normalized set of work—work that requires roughly the same, consistent set of skills at the same capacity level so that the current team can get the job done.
- Staff development teams with people who have (or want to acquire) T-shaped skills.
Let’s briefly consider each option.
Recompose the Team as needed
Although recomposing teams is an option, it is not a very good option. First and foremost it violates a core principle that teams should be long-lived and its members should stay together as long as it is economically sensible to do so. The economics are very favorable for long-lived teams.
It takes real time and effort to transition a group of people into a highly functioning team whose members work collaboratively towards achieving a common goal. Team members know how to work together, and they have earned each other’s trust. In addition, the team has amassed important historical information, such as the team’s velocity and shared estimating history that would be compromised if we meaningfully change the team member composition.
Also, this option is often just not practical. Since the order of items in the product backlog can and does change, we may not know until just before sprint planning exactly which items the product owner would like to include in the next sprint. On short notice it just may not be possible to make team personnel changes.
Select a Normalized Set of Work Each Sprint
The option of selecting a normalized set of work is better than frequently recomposing a team. Still, it has one glaring drawback: The constraint of the development team’s skills influences the order in which product backlog items are worked on. This can result in a sub-optimization of project economics. In other words, the product backlog should be prioritized by business factors, not team skills constraints.
Choose Team Members with T-Shaped Skills
The best option is to form teams with people who have T-shaped skills. T-shaped skills is a metaphor used to describe a person with deep vertical skills in a specialized area (such as database design) as well as broad but not necessarily very deep skills in other relevant areas (such as testing and documentation).
I illustrate the concept of T-shaped skills with the following picture.
For example, John is an expert Oracle DBA. This is his specialty and where be prefers to do work. However, John can also work outside of his core specialty area by doing some testing and documentation work. John doesn’t have deep skills in testing and documentation like the people who specialize in testing and documentation do, but he has useful skills in these areas.
A team composed of people with T-shaped skills has the ability to swarm on a bottleneck of work in a given area and relieve the bottleneck so the team can be successful. Not everyone on the development team must be capable of working on every task. That is a lofty goal to have, but not realistic in domains that tend to require intense specialization (such as video game development). But, wouldn’t it be helpful if each team member could do some amount of work outside his or her specialty area? That way more than one person would be capable of doing each task (although perhaps not equally well or at the same speed).
So, staffing teams with people who have T-shaped skills provides us with a good solution to dealing with the variability of work that the team has to do sprint to sprint. Want more proof? The next section walks you through the math behind this solution.
Negative Covariance
There is a mathematical basis for why T-shaped skills works to offset variability in the nature of the work (variability in the demand). It is called negative covariance.
We often have performance that depends on the combined effect of two random variables. Sometimes we can make one of these random variables counterbalance the other, creating what is called a negative covariance. A negative covariance will reduce the total variance obtained when we combine two random variables.
Okay, that is a lot of statistics lingo, so let’s see if we can translate that into something useful to deal with the real-world issue of sprint-to-sprint variability in the type of work required to complete backlog items.
First let’s acknowledge that we cannot reduce or eliminate this variability in an economically sensible way. Meaning, each item in the product backlog requires specific skills to complete (we can’t change that). And, the order of the items in the product backlog should be based on business factors not the skills constraints of the development team; so from a skills perspective, the items are ordered randomly. To be clear on this last point, if we were pursuing option two mentioned at the start of this blog (trying to identify a normalized set of work for each sprint) then the product backlog items would not be ordered randomly, they would be ordered to ensure that each sprint’s workload could be completed with a consistent set of skills at the same capacity level.
Since we can’t eliminate or reduce (without economic compromises) the variability of the work required to complete product backlog items each sprint, our goal is to be resilient to this variability.
Having team members with T-shaped skills provides us a counterbalancing effect to reduce the overall variability. Basically the horizontal part of the “T” that enables people to perform work outside of their vertical specialty provides variable capacity to offset the effects of variable demand (a negative covariance).
In the book The Principles of Product Development Flow, Don Reinertsen discusses this concept (principle V10 in his book). According to Reinersten, “..in manufacturing, we might choose to cross-train workers from our assembly area to assist testers during periods of peak demand. Whenever the queue of work gets to a certain size, we shift more resources to the queue. This allows us to offset random increases in demand with compensating changes in capacity. Thus, the separate effects on the queue of changes in demand and capacity will have a negative covariance. This reduces the average queue size in the presence of variable demand. We can use this same approach by cross-training product development personnel to perform the tasks of adjacent processes.” (page 100).
In our case, people with T-Shaped skills equate to the “changes in capacity” that offset the “changes in demand” represented by the differing types and amounts of skills required to complete a collection of product backlog items.
Summary
Product backlog items are not born equal. Each may require differing types and amounts of skills to complete. We cannot eliminate this form of variability. Economically the best solution is to establish teams of people who have T-shaped skills so that a team can swarm onto the work that needs to be done—dynamically change its capacity to do work in a given area. Mathematically, the effect of offsetting one random variable (variability in the type of work needed each sprint) with another (team’s ability to vary its capacity to work in a given area) is called negative covariance. This negative covariance makes a team more resilient to the variability in the work it takes on each sprint and therefore more likely to get the job done.