In this article, we shall investigate why the learning and development of multi-functional specialists in Scrum is the core of organizational Agility and value optimization. Many Development Teams are not collaborating as real teams, but as a collection of narrow specialists focused on "their" tasks (QA, Backend, iOS, Android). That leads to an ever-increasing number of explicit and implicit backlogs, "dependencies," extensive Work-In-Progress (WIP), queues, and unsatisfactory lead times. How does it affect organizational Agility and what to do about it?
Making People Busy is Not the Goal
Recently I observed a few teams in a large service company during an extended enterprise Go See effort. I attended various Scrum Events, followed teams collaborating daily, noticed how they dealt with conflicts, and much more. We have done it for a very sound reason - to uncover the underlying system structures and come up with deep interventions. What immediately caught my attention was the focus on resource utilization during Sprint Planning. Some of the phrases that caught my attention:
- "Do we have enough work for the designer in this Sprint?"
- "Seems like testers are already filled up with work."
- "Can we pull another item for our iOS developer to make her busy?"
The fundamental issue in complex environments is that work never distributes evenly for a cross-functional team in a Sprint. My observation has been during the years that lots of teams do not respect the order of the Product Backlog because it means facing a painful skill gap.
Respecting the Product Backlog order means facing a skill gap
Implicit Backlogs
When the Scrum Team preserves the goal of making people busy, it has multiple implicit backlogs, not one. The typical phrase that you can hear is, "I will do this feature because I am familiar with X technology." The Product Owner is forced to change the order of the Product Backlog to make people busy in Sprint. Thus, the team doesn't work on the most critical features from a customer perspective and sub-optimizes the value delivery. Let's have a look at this from a Systems Thinking view (shown in Figure 1).
We obtained the first balancing loop "B1: Making people busy". The more perceived skill gap to develop the most critical features from a customer perspective, the more team stress, the more pressure to increase the number of implicit backlogs ("these are my features, those are yours"). That makes developers locally efficient at the cost of sub-optimizing the whole.
Developers are efficient at the cost of sub-optimizing the whole.
Pay attention to the mental models:
- "I don't know this stuff. I'm not a 'XXX' developer."
- "It's the best and most efficient when everyone is busy and doing 'his/her work'"
This dynamic doesn't happen on a single team level only. When a knowledge gap becomes really large, then new teams with separate backlogs emerge. Let's investigate this dynamic further.
More Backlogs Imply More Work-In-Progress (WIP)
One company of a friend of mine started as a small startup a few years ago. Five people were sitting in the same room, working on one product. They worked as a real Scrum Team swarming all day long. They were nimble and agile in those days. Everyone was engaged in the most crucial work, regardless of the primary specialization. What happened after several years? The company grew over time, and the number of backlogs increased dramatically. The company ended up having 13 "Product Backlogs": iOS Backlog, Android Backlog, UI/UX backlog, and many more. Homogeneous teams were composed of narrow specialists that worked very efficiently from their perspective. The average Work-In-Progress (WIP) of the whole system significantly increased because developers were focused on starting and finishing their own work in the local backlogs. This amplified the lead time and caused organizational stress. The product organization wasn't able to deliver value to the market early. Management reacted to the organizational stress predictably. They asked people to work harder. That led to even more backlogs, more Work-In-Progress (WIP), and more organizational stress. Period. The above-mentioned dynamics is shown in Figure 2:
Pay attention to the mental model:
- "People don't work hard enough."
The system diagram illustrates how focusing on making people busy impacts the speed of delivering value early in the long-term. More backlogs also mean more dependencies and reduced value delivered. Let's investigate it in the next section.
More Backlogs Implies Dependencies and Reduced Value
When an organization introduces more backlogs, then teams become less cross-functional. That inevitably leads to dependencies (shown in Figure 3).
The organization starts managing the dependencies instead of eliminating them. The more dependencies, the less probability that an end-2-end customer-centric feature will be "Done" in a Sprint. Dependencies affect the lead time, which in turn introduces a new form of organizational stress. Furthermore, teams working through multiple backlogs even do not realize that they are not working on the most critical pieces of work from a customer perspective.
Multiple teams working in multiple backlogs are do not realize that they are not working on the most critical pieces of work from a customer perspective.
Why? Let me illustrate this concept with a short story. In 2019 I worked with a product group, "OK Alfa!" that contained three features teams then. They were developing a complex banking solution. It turned out that by the time I joined them, they already kicked off 3 cross-functional feature teams that had separate backlogs. I asked the "Product Owners" and "Chief Product Owner" to create a single Product Backlog instead. You can see it in the picture below:
It became evident that work did not distribute evenly in a single Product Backlog until they examined it in one queue. The colors of the stickies represent different parts of the product from the customer's perspective (red, yellow, orange). Having three backlogs meant that teams were sub-optimizing the whole and working on the less critical features. If we look at the resulting system diagram, we can see three reinforcing loops R2, R3, R4 that create a "Fixes That Backfire" archetype with B1 (shown in Figure 4):
The central theme of the pattern "Fixes That Backfire" is that people take a reasonable measure to remedy an unwanted situation. Still, after the 'fix,' the problem comes back—sometimes in a different form—more robust than before. Taking more of the same actions just worsens the situation. The more backlogs, the more problem, the longer the lead time, the more organizational stress.
Now let's see how to redesign the system to optimize value in contrast to making people busy.
Optimizing Value Implies One Backlog and Multi-Functional Learning
As I mentioned before, the fundamental problem in a complex environment is the uneven distribution of work.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value (The Scrum Guide).
You can consider optimizing value strategy in the context of two steps:
- Create a single customer-centric Product Backlog that reflects the most important features from a customer perspective. Of course, those features are our speculations on what we think is the most valuable.
- Ask the team(s) to respect, in general, the order of the customer-centric Product Backlog in development.
Working from a single queue of requirements, unfortunately, creates a painful gap in knowledge. The more skill gap, the more need for the developers to help others and acquire new skills. But in a while, this strategy pays off and leads to the development of multi-functional specialists and Agility. Look at Figure 6:
Pay attention to the mental models:
- "We need to respect the order of the Product Backlog."
- "People may learn and acquire new skills over time'"
- "Agility requires multilearning."
The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive (The Scrum Guide).
Frankly, there is nothing new in the concept of multi-functional specialists and cross-functional learning. The origins of Scrum come from "The New New Product Development Game" paper, with multilearning being one of the main characteristics of effective teams. Multi-functional specialists were introduced in Toyota a long time ago by Taichi Ohno.
In 1947, we arranged machines in parallel lines or in an L shape and tried having one worker operate three or four machines along the processing route. We encountered strong resistance among the production workers, however, even though there was no increase in work or hours. Our craftsmen did not like the new arrangement that required them to function as multi-skilled operators. They did not like changing from “one operator, one machine” to a system of “one operator, many machines in different processes.” (Taiichi Ohno, The Toyota Production System, 1988)
I often hear the argument: “We understand the idea behind that. But still, a deep specialist will be more effective and knowledgeable than a cross-trained one”. And I agree with the argument. But we do not train people to create an efficient resource. Instead, we create a team capable of dealing with bottlenecks.
We do not train people to create an efficient resource. Instead, we create a team capable of dealing with bottlenecks.
Remember, when the system is heavily loaded, even a small change in capacity can lead to a significant difference in cycle time. In “Managing the Design Factory" Donald G. Reinertsen writes:
This ability of autonomous teams to align resources to bottlenecks is extremely important because it minimizes queues in the development process. Since these bottlenecks can shift rapidly and unpredictably during a program, the flexibility of team members to work outside of speciality is a critical tool for dealing with such bottlenecks (Donald G. Reinertsen, Managing the Design Factory).
Dealing with a Culture of Narrow Specialists
Unfortunately, many teams prefer applying fixes and follow the resource utilization strategy. This approach is not a good idea if we want to optimize the whole. Unfortunately, the quick fix of increasing the number of backlogs has a side effect that weakens the system's natural ability to implement the more fundamental correction. When a Scrum Team adopts the resource utilization strategy and has been there for some time - a culture of narrow specialists is born. It takes a lot of effort, leadership support, and patience to overcome the resistance and apply the fundamental solution instead. If we look at the final system diagram, we can see the reinforcing loop R5 that corresponds to the culture of narrow specialists:
Pay attention to the mental model:
- “This is weird. Multi-functional people do not exist. It’s a myth”.
Therefore, with the help of system diagrams, we investigated the implications of learning disability in teams. Quick fixes have long-term consequences. The act of increasing the number of explicit or implicit backlogs spawns lots of problems: intensive Work-In-Progress, queues, long lead times, organizational stress, less value delivered. The first solution is multi-functional learning.
Multi-Functional Learning is the Heart of Agility
How to Enable Learning and Increase Agility
There are many options to deal with the situation when the Scrum Team(s) are used to work in "make people busy" mode. Here are some of them:
- Point out the tendency of the Scrum Team to focus on resource utilization instead of increasing Agility.
- Conduct a system modeling workshop and let people have their insights regarding the "making everyone busy" strategy and consequences associated with it. Use the system diagrams presented in this article for inspiration.
- Create an awareness that people are working on the less critical stuff from a customer perspective by creating a single queue of requirements. When possible, use the "cold turkey" strategy and move to a single Product Backlog overnight.
- Gradually reduce the number of backlogs over time if there is a painful knowledge gap.
- Point out that in Scrum Product Backlog is ordered. You can use a simple rule, which means that in general, the items at the top should be "Done" before the team proceeds to less important ones.
- Establish a Perfection Vision that would take precedence over responding to the pressure of local optimization.
- Use the Competency Matrix for inspecting and adapting the team's cross-functionality. Update it regularly.
- Create an agreement on how the team(s) would deal with the knowledge gap. For instance, it could consist of several points: a) help your teammates; b) remove technical debt; c) learn something valuable; d) start a new work (last and worst option).
- Try implementing the pattern "Swarming: One-Piece Continuous Flow." The best Development Teams I have collaborated with, worked using three modes: pair-programming, mob-programming, and swarming continuously.
- Try to change HR-practices to enable the development of multi-functional specialists in an organization.
- Try to use Scrum Pattern sequences to increase teams' cross-functionality and flexibility.
In the next article, we shall dive deep in tips and tricks to enable multi-functional learning and increase Agility.
Takeaway
In complex environments, work never distributes evenly in Sprints. When developers are working on the customer-centric Product Backlog Items, they experience a knowledge gap. There are two primary responses to this challenge. The first is following the path of resource utilization and increasing the number of implicit or explicit backlogs. Developers become efficient individually at the cost of sub-optimizing the system. The first solution is respecting the order of one Product Backlog by helping others and multi-functional learning. Over time this strategy creates a flexible team. You train people to deal with bottlenecks and increase Agility. The culture of narrow specialists stays in the way of multi-functional learning. There are many ways to help to preserve the long-term strategy. Among other approaches are working in three preferred modes: pairing, mob-programming, and swarming continuously.