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, etc). This leads to an ever-increasing number of explicit and implicit backlogs, “dependencies”, more 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 is never distributed evenly for a cross-functional team in a Sprint. Over the years, my observation has been that many 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 keeps 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 take a look at this from a Systems Thinking perspective (see 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’s 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 at a single team level only. When the knowledge gap becomes really large, then new teams with separate backlogs emerge. Let’s investigate this dynamic further.

More Backlogs Implies 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? As the company grew, the number of backlogs increased dramatically. They ended up with 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 increased significantly because developers were focused on starting and finishing their own work in their 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 this stress in a predictable way; they asked people to work harder. This led to even more backlogs, more Work-In-Progress (WIP), and more organizational stress. The abovementioned dynamic 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 which also impacts value delivery. Let’s investigate this in the next section.

More Backlogs Implies Dependencies and Reduced Value

When an organization introduces more backlogs, the teams become less cross-functional. This inevitably leads to dependencies (shown in Figure 3). 

The organization starts managing dependencies instead of eliminating them. The more dependencies, the smaller the probability that an end-to-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 from multiple backlogs do not even realize that they are not working on the most critical pieces from a customer’s perspective.

Multiple teams working from multiple backlogs do not realize that they are not working on the most critical pieces from a customer’s perspective

Why? Let me illustrate this concept with a short story. In 2019 I started working with a product group that was developing a complex banking solution. When I joined them, they already had three cross-functional feature teams working from three separate backlogs. I asked the “Product Owners” and the “Chief Product Owner” to create a single Product Backlog instead. You can see the result below:

It wasn’t evident that work was not distributed evenly until they examined it in one queue. The colors of the stickies represent different parts of the product from the customer’s perspective. Having three backlogs meant that teams were sub-optimizing the whole while working on 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 make a reasonable attempt to remedy an unwanted situation. Still, after the ‘fix’, the problem comes back—sometimes in a different form—often more prominently than before. Doing more of the same actions just worsens the situation. More backlogs lead to a bigger problem, longer lead times, and more organizational stress. 

Now let’s see how to redesign the system to optimize value delivery instead of making people busy.

Optimizing Value Implies One Backlog and Multi-Functional Learning

As I mentioned before, the fundamental problem in a complex environment is an 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 the customer’s perspective. Of course, those features are our speculations of what we think is the most valuable.
• Ask the team(s) to respect, in general, the order of the customer-centric Product Backlog. 

Unfortunately, working from a single queue of requirements creates a painful gap in knowledge. The bigger the skill gap, the bigger the need for developers to help others to acquire new skills. But this strategy pays off after some time and leads to the development of multi-functional specialists and Agility. Look at Figure 6:

Pay attention to the following 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.

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. The quick fix of increasing the number of backlogs has a side effect that weakens the system’s natural ability to implement a more fundamental correction. When a Scrum Team adopts the resource utilization strategy and keeps doing it for some time, it creates a culture of narrow specialists. It takes a lot of effort, leadership support, and patience to overcome the resistance to change from the team and to apply the fundamental solution instead. If we look at the final system diagram, we can see the reinforcing loop R6 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: more Work-In-Progress, more queues, longer lead times, organizational stress, less delivered value. The fundamental solution is multi-functional learning.

Multi-Functional Learning is the Heart of Agility

How to Enable Learning and Increase Agility

There are many options for dealing with the situation when the Scrum Team(s) are used to work in the “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 the consequences associated with it. Use the system diagrams presented in this article for inspiration.
• Create an awareness that people are working on less critical stuff from the customer’s 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, the Product Backlog is ordered. You can use a simple rule 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 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 deeper into tips and tricks for enabling multi-functional learning and increasing Agility.

Takeaway

In complex environments, work is never distributed evenly in Sprints. When developers are working on customer-centric Product Backlog Items, they experience a knowledge gap. There are two primary responses to this challenge. The first is to follow the path of resource utilization and to increase the number of implicit or explicit backlogs. Developers become individually more efficient but at the cost of sub-optimizing the whole system. The solution is to respect the order of one Product Backlog by helping others and embracing multi-functional learning. Over time this strategy creates a flexible team. You train people to deal with bottlenecks. The culture of narrow specialists stays in the way of multi-functional learning. There are many ways to fight this culture and to preserve the long-term strategy. Getting teams to work continuously in pairing, mob-programming and swarming modes is one of the most effective approaches for this.

When Scrum Teams discuss too many problems during the Retrospective they may lose focus. That results in shallow decisions that barely scratch the surface. Teams are disappointed and lose faith in the Sprint Retrospective. Let’s see how to improve the event with the Scrum Patterns.

Too Many Improvements Uphold New Challenges

I want to share a story of the Scrum Team I have been working with as a Scrum Master long time ago.

There were too many problems the Scrum Team had accounted for. And there was a pressure to cover all of them during the Retrospective timebox. Therefore, the time spent per item was not enough to conduct in-depth analysis and investigate the underlying causes. Not surprisingly, the quality and depth of the improvement experiments were low. The problems did not go away and stayed over many Sprints. In fact, the number of challenges increased as the chronic disability to improve was a problem itself. From Systems Thinking perspective the Scrum Team got into the vicious cycle (see in Figure 1).

Decreased Team Commitment

There was also one more issue. Discussing too many problems and improvements did not generate enough commitment for the team during the Retrospective. There was not enough time for the team to achieve consensus. Therefore, the actions and follow-through suffered from lack of collective energy and were not implemented. That is how the second vicious loop was created (see in Figure 2).

It turned out through the years that I was not the only Scrum Master who made these mistakes. Let’s see how Scrum Patterns might help to improve the situation.

Improving Sprint Retrospective With Scrum Patterns

The Scrum Patterns are typical solutions that were applied to the well known problems around the globe in different organizations and teams. A pattern is an instruction to shape something we build to increase the “Wholeness of the Whole”. Let’s see how we can improve the wholeness of the Sprint Retrospective. If you are not familiar with the Scrum Patterns yet, the following articles may guide you:

• Scrum Patterns – Putting Scrum Into Practice
• How to Select Scrum Patterns
• Planning an Adoption With Scrum Patterns 

In Figure 3 you can see one of many possible sequences that could be created with Scrum Patterns.

I will put a short description of each of the selected patterns below:

• One Step at a Time. Attempt one improvement at a time, incrementally.
• Impediment List. Make all non-trivial issues visible with an Impediment List; raise them up to the right people in the organization for resolution.
• Involve the Managers. Sustain a management function that can act from a position of power to initiate, and take responsibility for, radical changes in the organization, and deal with impediments that may be too weighty for the ScrumMaster or Product Owner in the Scrum Team.
• Scrumming the Scrum. Identify the single most important impediment at the Sprint Retrospective and remove it before the end of the next Sprint.
• Testable Improvements. Write improvement plans in terms of specific concrete actions (not goals) that the team can measure objectively to assess whether the team is applying the process change. 
• Kaizen Pulse. Alternate periods of controlled velocity with spikes of process improvement.
• Happiness Metric. Drive the improvement process with a single, small improvement at a time, chosen through team consensus. Pose a question to the team that helps it reflect on which of the alternatives on the table will best tap into their collective passion or sense of engagement, and use the answer to choose the kaizen that will most energize the team.

Remember that there are no “wrong” or “right” pattern sequences. Occasionally a pattern or a sequence doesn’t work as expected, and it makes sense to try another one or to try patterns in a different order. Follow the principle to refine the largest “wholes” first and then proceed to the smaller ones.

How would you use Scrum Patterns to improve the Sprint Retrospective? 🙂

How to start an Agile transformation? What are the initial steps? In this article I explain how transformations could be planned using Scrum Patterns and systems thinking.

Study Organizational Context

Any collaboration with an enterprise starts with an immersion in organizational context using Gemba Walks and Go See approach. Observing how teams work, collaborate and conduct their regular events is crucial in understanding patterns of behavior that exist in an organization. Why is that important? System structures reside behind the patterns of behavior and they are the main focus of Scrum Master intervention. Go See results are usually collected in a report that includes observations, description of the discovered system structures, and recommendations.

Take a look at the excerpt from one of the Go See reports:

The product group consists of 16 Scrum teams. They are component teams made narrow specialists who work in “their” components. There are 16 “Product Backlogs” and 16 “Product Owners”. Customer features usually involve a large number of components. Work at the product level is not evenly distributed across all teams, so some of them are overloaded, while others are forced to make themselves busy with less important work. Features are eventually delivered to the market in 5-10 Sprints. Features usually span over multiple Sprints due to dependencies between teams.

How to start a transformation if the final goal is creating an adaptive organization? Before answering the question, let’s get back to the basics of systems thinking.

Car as a System

A car is a deterministic system consisting of three parts: a body, a chassis, and an engine. If we look at the chassis gear then it, in turn, includes smaller systems: a frame, suspensions, axles and wheels. 

Larger systems contain smaller ones and cannot function properly without them. It can be said that smaller systems “improve” or “refine” the larger systems that they are part of.

In order for the minimum version of the car (MVP) to move and fulfill its functions, the interaction of the body, chassis and engine is necessary. You can refine the car with the golden rims, but this will be a less important improvement from systems thinking perspective. Without an engine, the car will not budge.

Scrum as a “Product Organization” And a “Value Stream”

Scrum can be viewed as two interconnected systems or two “wholes”. The first one is the product organization. It establishes the relationships between people and teams. For example, the Scrum Team and Stable Teams are the patterns from the product organization language.

Picture from “A Scrum Book”

The second “whole” is the value stream that structures time. For example, Product Backlog and Product Backlog Items are patterns that are commonly used in order to achieve a product Vision.

Picture from “A Scrum Book”

Both systems are highly dependent on each other. In practice, it is worth simultaneously build both “wholes” to maximize the benefits of Scrum. Two forms of Scrum, as in the case of a machine, form a system of nested patterns. They visualize the relationships between patterns and suggest the order in which they should be applied. 

The general principle is refining larger system first and focusing on the smaller ones later.

Product Organization Pattern Language

The product organization language starts with four sequential patterns: The Mist, The Spirit of the Game, Fertile Soil and Conway’s Law. Then it diverges into parallel nodes (patterns): MetaScrum, Involve the Managers, Scrum Team, Birds of a Feather. 

If you look at the product organization language you may notice that it incorporates five levels of nested patterns, if we count from the Conway’s Law level. Each pattern is a system and is a part of the larger system. Let’s investigate the Happiness Metric metric: 

• Happiness Metric is the part of Product Pride;
• Product Pride is the part of Sprint Retrospective;
• Sprint Retrospective is the part of Scrum Team;
• Scrum Team is the part of Conway’s Law.

The greatest impact at the product organization level can be achieved when we focus first on improving larger system, and only then improving the smaller ones. Maybe Happiness Metric is not the first pattern to start with when transforming an organization. If you don’t have cross-functional (Cross-Functional Team pattern) Scrum Teams and management support (Involve the Managers pattern) maybe you should focus on something more critical first.

Planning an Adoption

Let’s get back to the excerpt from the Go See report. Teams are organized around architectural components, functions, and internal business processes and are so called component teams. This structure and its associated patterns of behavior and trends (dependency management, long release cycles) can be solved by the pattern Conway’s Law, which implies transition to product teams and the creation of an adaptive organization.

Conway’s Law pattern in short:

• Problem: effective communication and feedback are at the heart of effective complex system development, and the organization structure should be optimized for the most crucial paths of communication. 
• Solution: organize the workforce into Small Teams of more or less five people, partitioned according to the most important concerns for the creation of value by the enterprise. Supplement this structure with a small number of cross-cutting structures for secondary but important concerns, never forgetting that these structures are only optimizations in what is otherwise an open environment of unconstrained cooperation. 

What other patterns could be helpful in transition to product teams as Conway’s Law states? Thoroughly investigating the product organization language you could come with the following start-up pattern sequence: 

In order to create an adaptive organization you choose the Conway’s Law pattern first. Then it’s critical to get management support and thus you Involve the Managers. After that you create the overall Product Backlog, analyze it and define the Value Areas. Next step could be creating the best possible Cross-Functional Teams и starting up the Birds of a Feather. And this is just the beginning of the transformation journey.

Avoid Local Optimizations Whenever Possible

Recently I had a telephone conversation with the managers of one foreign bank. The initial request was to support the launched Scrum Teams and mentor Scrum Masters. The simplest thing that could be done was to negotiate the price and fill up their request. But it would be incorrect and unethical from my side to propose a solution without understanding the underlying issue. An express assessment that followed showed that what managers asked would be a local optimization. Agile transformation in the bank had much more serious challenges. Supporting teams and mentoring Scrum Masters would not be the best possible solution from systems thinking perspective. 

Scrum Values Create a Breeding Ground For Systemic Optimizations

Adhering to Scrum Values (Fertile Soil pattern) creates a breeding ground for the creation of the product organization. Scrum Master guides and leads by employing Scrum Values.

The job of the Scrum Master is to propose systemic solutions that solve the fundamental problems of the organization. Avoid local optimizations whenever possible. In order to do this, the Scrum Master relies on the Scrum Values. This is a touch job, but demonstrating courage and openness continuously, the Scrum Master creates the crucial transparency for everyone involved in the transformation. Thus, it becomes the basement for future changes.

Main Ideas

• Scrum can be viewed as two interconnected wholes: one looks at structure (“product organization”), the other looks at time (“value stream”).
• The general principle is to refine a larger system first and focusing on the smaller ones later.
• Adhering to Scrum Values (Fertile Soil pattern) creates a breeding ground for the product organization.
• The job of the Scrum Master is to propose systemic solutions that solve fundamental problems.

In this article, we will be sharing an example of organizational coaching, in which we successfully applied the Systems Thinking approach. We were working with a service organization and found fundamental solutions to several chronic problems. We believe that effective organizational coaching is not possible without Systems Thinking.

Why Systems Thinking

Large organizations are complex social systems. Although the causes and effects are not obvious, possible solutions are found in the most unexpected places.

Systems Thinking recognizes mental models and structures in work and in everyday life. It reveals the reasons for chronic problems in complex organizational contexts. It is an important thinking approach for creating a general picture of reality, by means of engaging individuals with different viewpoints. 

In one service organization

Recently, we worked with a group of Scrum Masters in a large service organization. During multiple interviews, we asked how much time they spent on organizational coaching. The Scrum Masters gave evasive answers while agreeing that it was an important part of their job. They complained of a major lack of time. In their words, team activities were absorbing all of their time. 

The company understood the importance of full time Scrum Master role. Each Scrum Master was working with only one team. We became fascinated by their lack of time for organizational coaching, and conducted investigation. Now we are going to share the results with you.

The language of systems diagrams

In this article, we’ll be employing systemic diagrams. They depict the stories of people’s behavior patterns and help observe the whole system. Causal-Loop Diagrams (CLD) are one of the most widespread tools in Systems Thinking. The main elements of the diagrams are:

• Variables (behavior, condition);
• Cause-and-effect relationships (direct and opposite);
• Reinforcing and balancing loops (indicated by “R” and “B” respectively); 
• Time delay;
• Quick fixes and non-fundamental solutions (QF);
• A strong deterministic cause-and-effect relationship (the bold arrow);
• A short-term cause-and-effect relationship (“short-term”);
• Mental models (the cloud icon) that stay behind the cause-and-effect relationships.

Now that you are familiar with the language of systems diagrams, let’s have a look at the results of the investigation.

The team’s dependence on the Scrum Master

We observed how the Scrum Masters were working with their teams and discovered that the teams were highly dependent upon them. For example, the Scrum Masters conducted all the Daily Scrums, even though the teams had been working together for more than a year and could have learned to do this themselves (see ScrumMaster Incognito pattern). A Daily Scrum is an event that is for the Development Team. The Scrum Master’s (see Scrum Master pattern) job is to teach their team to conduct it effectively within a timebox.

The teams were also unable to independently facilitate other Scrum events. There was also no discussion regarding how to address impediments or internal conflicts. The Scrum Master was required to participate in everything. 

A Scrum Master has two options: to get involved and solve the issue/problem themselves, or coach their team, making it more self-managed and autonomous (see Autonomous Team pattern). 

The teams and the management regarded the Scrum Masters’ roles as being exclusively to serve their team. The mental model that we came across in many of our interviews was that “Scrum Master is a team level role.” If we visualize the story in the form of a diagram, then we obtain a “Shifting the Burden” system archetype, which explains the dependence on the Scrum Masters. As a result, we get two balancing loops and one reinforcing loop. 

• B1 (quick fix): the less ability for the team to handle their own challenges the more the Scrum Master’s services are required, the more often the Scrum Master tends to get directly involved, and the problem temporarily goes away.
• B2 (fundamental solution): the less ability for the team to handle their own challenges the more the Scrum Master’s services are required, the more often he or she makes decisions in favor of coaching the team. In time, the team becomes more independent and shows high levels of self-organization and independence. Thus, it increases the ability of the team to handle challenges themselves.
• R1 (dependence on the Scrum Master): the more frequently the Scrum Master chooses to get directly involved, the more the team will come to depend upon him or her, and the less likely it is that the Scrum Master will be able to apply fundamental solution B2.

Organizational impediments uphold new challenges

Since the Scrum Masters have been entirely absorbed by the “operational stuff” on the team level, they have not been devoting time to organization coaching. But organizational dysfunctions were still present. They were the reason for many of the team’s challenges, with which the Scrum Masters subsequently had to deal locally. 

Examples of dysfunction might be multiple dependencies between teams due to narrow product definition, coordination between teams, insufficient Product Owner authority, handoffs, and so on. Needless to say, organizational dysfunctions were decreasing the ability of the team to handle challenges themselves. By visualizing this on a system diagram, we obtain reinforcing loop R2:

• R2: the less ability of the team the more the Scrum Master’s services are required, and the more direct involvement occurs on the part of the Scrum Master, the less time he or she devotes to the organization and to the elimination of organizational dysfunction, which in itself decreases the ability of the team.

An organization’s dependence on external consultants

The organization’s management was employing the Go See approach. Organizational dysfunctions were on their radar. But since, in the management’s mental model, the Scrum Masters were not suited to working with organizational impediments, for many years the company had engaged external consultants to work with top managers and organization. The consultants did not work in tandem with the Scrum Masters and did not develop them (see Scrum (Master) Coach pattern). Thus, in time, dependence upon external consulting arose. Let’s indicate this on our system diagram with the three loops, B3, B4, and R3, which depict the second archetype, “Shifting the Burden”:

• B3 (quick fix): the more organizational impediments there are, the more the company needs to engage external expertise without mentoring Scrum Masters, which temporarily clears up the issue.
• B4 (fundamental solution): the more effort to develop Scrum Masters, in time, the more they are capable of coaching the organization themselves.
• R3 (dependence): the organization is dependent upon external consultants, and a mental model is formed, in which Scrum Masters are not capable of removing organizational impediments.

Combining two archetypes we get the resulting system diagram:

Three steps for change

The investigation we conducted and the resulting system diagram would have been impossible without the three steps for change, which we practice during organizational coaching. It seems that there is nothing simpler than conducting an honest and independent audit and subsequently presenting the results. In practice, however, it is very likely that there will be resistance, since it is difficult for people to accept reality and take responsibility. Evolution has taught us to avoid conflict and social confrontation.

The first step: interviews with the individuals and Go See. 

We had dozens of conversations with Scrum Masters, team members, and top managers. We were present at various Scrum Events (Sprint Planning, Daily Scrums, etc.) We painstakingly noted down any repeating patterns (anything that happens more than three times) in behavior and looked for the system structures that were supporting them. In other words, we delved deeply into the context.

The second step: teaching system thinking and the basic archetypes. 

We conducted several Systems Thinking workshops for everyone we had interviewed. Why was that important? The issue is that we do not recommend you compiling a system diagram yourself and imposing it on people. There is a big difference between the insights that people obtain as a result of creating model themselves and by the one-way transmission of information by an external consultant.

The third step: creating a system diagram and solutions.

After the staff had been taught the basics of Systems Thinking, we gathered them in one room to create a system diagram. We also brought in and presented the most important variables.

The world of large organizations is made ever more complex by politics. Occasionally, the most important question that came into the minds of those in the room was: “whose fault is it?” We therefore created a safe environment, by getting the message across that in social systems there is no blame. 

If you are part of the system, then you are also part of the problem. In a system, everyone is right, but only partially.

By working in small groups, we came up with several versions of the diagram, each of which shed light on the real picture in a different way. The final result of the workshop was the final system diagram that is presented above. Those who took part in the workshop agreed that it depicted precisely their organization. “That’s us,” said one, with a sigh. When people create a picture of reality together, and then a common solution, then they are significantly more inclined to support it. 

Here are the systemic solutions that came out of the workshop:

• The Scrum Masters are starting to coach their teams in conducting events, resolving conflicts, problem-solving, and facilitation. This is no simple matter, when you consider the teams’ reluctance to do so because of the established mental models. It is important to do this gradually, giving teams the opportunity to make mistakes, but not subjecting them to excessive stress.
• Scrum Masters are beginning to work in tandem with external consultants in order to learn to work at the organization level and with top management.
• The company’s management is communicating to the whole organization the message that the role of a Scrum Master is not limited to the teams only.

Key points

• A Scrum Masters always have two options: to get involved and solve the issue/problem themselves, or coach the teams, making them more self-managed;
• It is a myth that Scrum Master only works at a team level;
• One of the essential services of a Scrum Master is a service to organization;
• Systems Thinking is an important approach for creating a picture of current reality, by means of engaging individuals with different viewpoints;
• Bring the whole system into a room;
• Establish an atmosphere of trust;
• Create a system diagram together and come with a systemic improvement experiment.

In this article, I will discuss the dangerous dynamic that can arise when a Product Owner, Scrum Master, or the management of an organization focuses a Development Team on velocity.

What does velocity refer to?

The concept of velocity signifies:

The speed at which a Development Team converts Product Backlog Items into a Product Increment that is RELEASABLE.

Pay particular attention to the highlighted word. Feature velocity is applicable when a Development Team can deliver an Increment that is releasable at least once per Sprint. In this case, Done = DoD = releasable. Awesome!

But even in this case velocity does not show:

• Whether the client’s problem was resolved.
• Whether team is working on the highest priority problems.
• Amount of value delivered.
• Level of client satisfaction.

Velocity only shows that the team was busy with something.

But is this an accurate measure of the success of the products and services? Do the clients value products based on how busy company’s staff are?

To put it another way, Velocity reflects the volume of a Development Team’s output. Unfortunately, this is not enough for the creation of successful products and services.

The feature velocity of component teams = 0

Component teams have the most stable feature velocity. Because it always equals zero. Component teams are by definition not able to convert Product Backlog Items into value for a client. At a minimum they need integration with other component teams.

When a team has Undone work

In my opinion, the most dangerous dynamic arises in cases where a Development Team is not capable of generating a Product Increment that is releasable each Sprint. This means that Done = DoD + Undone and team optimizes just the part of the whole flow.

Let us examine a system diagram that shows the link between the strength of DoD and organizational agility.

The stronger the DoD, the smaller Undone work in the Sprint. Undone work limits the team regarding the number of potential releases, and, as a result, also regarding the amount of feedback that can be received from the market. The more feedback, the more decisions can be made by the Product Owner on the re-ordering of a Product Backlog. That could be called organizational agility — being able to quickly change the direction of a Product’s development. This may prompt a Scrum Team to undertake additional improvements to create an even stronger and more exhaustive DoD.

By strengthening the DoD, velocity decreases and becomes real

How is the strengthening of a DoD reflected in velocity? The velocity will decrease at least in the short term. But this is not a problem if the goal is flow optimization (shortest Lead Time), learning and agility. Velocity decreases and becomes more real!

But how likely is it that a Development Team would strengthen the DoD, if they know that team effectiveness is evaluated according to the velocity?

My answer is unlikely. Focus on velocity keeps the team away from strengthening their DoD. As a result, that inhibits feedback from market, learning and agility.

Focusing on velocity inhibits organizational agility.

When I was a young and an inexperienced Scrum Master many years ago, I focused my teams on velocity excessively, which reduced their agility and increased the amount of Undone work. Nowadays, my advice to Scrum Masters who are just starting out goes something like this:

Forget about velocity, if your team cannot produce an increment that is releasable at least every Sprint. Focus on strengthening your DoD first.

What should we measure then?

I recommend focusing on metrics that show the ability to deliver actual value to the market and satisfy client’s needs. For example, Scrum.org has developed framework Evidence-Based Management, and is offering a range of metrics that shows:

• A team’s ability to create value in the long term
• The speed at which value is generated (Time 2 Market).
• How much actual value is delivered to the market.

In conclusion

I would like to repeat once more the fundamental idea that I want to convey with this article. The basic idea of a Scrum is to create an increment that is releasable at least every Sprint. If your team is already at that stage, then the concept of velocity is useful and genuinely demonstrates the speed at which a team converts Product Backlog Item elements into an increment. If not, please focus on strengthening Definition of Done (DoD) and flow optimization.

The Article’s Main Ideas

• Velocity denotes the speed at which a Development Team converts Product Backlog Items into a Product Increment that is releasable.
• Velocity does not show whether clients’ problems are being resolved, nor whether value is being delivered, as reflects volume of output.
• Velocity only shows that a team was busy with something.
• The feature velocity of component teams is always zero.
• When team focuses on velocity and has Undone, it is unlikely they would strengthen the DoD.
• Focusing on velocity inhibits organizational agility.
• Focus on the value that is actually delivered to the market.

Scrum ON!