De investering voor deze training is Euro 2495, – ex BTW en Euro 2095, – ex BTW voor vroege vogels tot 1 maand voor de start. De prijzen zijn inclusief trainingsmateriaal en voor alle dagen lunch en koffie, drankjes en versnaperingen gedurende de dag.

Meer informatie over deze training

De investering voor deze training is Euro 2495, – ex BTW en Euro 2095, – ex BTW voor vroege vogels tot 1 maand voor de start. De prijzen zijn inclusief trainingsmateriaal en voor alle dagen lunch en koffie, drankjes en versnaperingen gedurende de dag.

Meer informatie over deze training

De investering voor deze training is Euro 2495, – ex BTW en Euro 2095, – ex BTW voor vroege vogels tot 1 maand voor de start. De prijzen zijn inclusief trainingsmateriaal en voor alle dagen lunch en koffie, drankjes en versnaperingen gedurende de dag.

Meer informatie over deze training

Professional Scrum MasterDe investering voor deze training is Euro 1695,- ex BTW and Euro 1485,- ex BTW voor vroege vogels, tot 1 maand voor aanvang van de training. De prijzen voor deze training zijn inclusief materialen en voor alle dagen lunch, koffie en drankjes en hapjes gedurende de dag.

De investering voor deze Certified LeSS training is Euro 2495, – ex BTW en Euro 2095, – ex BTW voor vroege vogels tot 1 maand voor de start. De prijzen zijn inclusief trainingsmateriaal en voor alle dagen lunch en koffie, drankjes en versnaperingen gedurende de dag.

Meer informatie over deze training

De investering voor deze Certified LeSS training is Euro 2495, – ex BTW en Euro 2095, – ex BTW voor vroege vogels tot 1 maand voor de start. De prijzen zijn inclusief trainingsmateriaal en voor alle dagen lunch en koffie, drankjes en versnaperingen gedurende de dag.

Meer informatie over deze training

Professional Scrum MasterDe investering voor deze training is Euro 1695,- ex BTW and Euro 1485,- ex BTW voor vroege vogels, tot 1 maand voor aanvang van de training. De prijzen voor deze training zijn inclusief materialen en voor alle dagen lunch, koffie en drankjes en hapjes gedurende de dag.

This is a description of the workshop I did at the LeSS Conference in Amsterdam.

You can use this workshop to have a thorough discussion about your new LeSS group or to repair an existing LeSS adoption.

For a general workshop, you can use the starting situation I wrote about in my Copy Paste Scaling articles that you can find here and another one there. I now call it the MeSS, then your goal is to go from MeSS to LeSS.

In the context of your organization, you start with your current situation.

Step 1

In this step, you generate a list of problems that you want to address.

The question to answer is, What should be removed from the MeSS ( or from your current situation ) to get to LeSS?

  • With your group generate a list of problems that you would need to address in your LeSS organization. You can use liberating structures if you have many people in the room.
  • Write each problem or improvement on a Post-Its. I like to ask people to write it in the form: “How do you …”
  • Use affinity mapping to remove duplicates and create a common understanding of the problems.

Step 2

In this step, you are going to discover which LeSS Pattern cards, if any, could be helpful.

Place the LeSS Cards front down on the table.

  • Choose a problem to work on.
  • Each person picks 4 LeSS cards from the deck.
  • Each player selects a card(s) from his hand, if any, that describes the problem and plays that card on the table.
  • The group then discusses the potential LeSS Patterns that could be useful in addressing that specific problem.
  • When agreed, place the pattern cards under the matching problem. If you have multiple cards that solve the problem place the cards in a sequence.
  • Each person refills their hand to 4 cards. If the new cards solve the current problem, you place the card, discuss and refill your hand again.
  • Then repeat with the next problem.

Step 3

In this third and last step, you discuss the sequences that you created and decide which pattern you want to apply.

A sequence is your best guess on how to improve the organization at the moment in time. When you adopt a pattern, you will learn if it works or not. If it works, you keep it; if not, you backtrack and try another. The basic process is as follows:

  1. Choose the pattern that will most strengthen your LeSS group.
  2. Apply the pattern.
  3. Assess if it indeed solves your problem at the end of the Sprint, then recognize your new context and choose the next pattern that you want to try.
  4. If not, undo the pattern and try another at Step 2 instead.

Keep an experimental mindset, be ready to learn and adjust, and understand that there is no “best” sequence. A sequence shows a path, but the teams have to do the walking and discover how to implement it.

The LeSS Pattern Cards

I created the LeSS Pattern cards for free use by the LeSS community. Just drop me an email if you want to obtain a deck. I will send you a printed deck.

This blog is part of a series of previews from my upcoming book Coaching Agile Organisations

In the first part of this blog series, I explained how to identify the organizational elements to include in your product definition. In this blog, I explain how you can refine your product definition to organize into effective cross-functional teams.

Some elements are more equal than others.

Below you can see a simplified view of the organizational elements at one of my customers.

We discovered that some organizational elements are required more than others to develop product features. The more often a particular element is required, the stronger the dependency. We visualised the strength of the dependencies with a heat map—see the figure below for a anonymised simplified example. 

The y-axis shows product features. The x-axis shows the organizational elements. A green area indicates an element that is needed to deliver the feature.

The elements that heat up the most indicate the strength of the dependency—these are the hotspots. Note that the WEB element is needed in 28% of the time to develop product features, the APP 20% of the time, while Legal is required only 7%.

NOTE: Avoid focusing too much on the percentages, this is not an exact science but rather a guide to help you move forward. Next to percentages I also successfully used different scales to estimate the strength of the dependencies like: Seldom, Now and Then, Frequent.

When all the teams can pick up any work that comes in and deliver it completely to done, you have maximum adaptability. That would mean that each team has the skills to cover the whole heat map. Unfortunately, this was not the case for us. There were just too many technologies and domain knowledge for the teams to comprehend. Also, there is value in team specialisation. The solution was for teams to specialise in the customer domain first, and then to learn about the other product domains as needed.

Learning can take many months or even years, and in the meantime, we needed to determine how to start. Which organisational elements should the teams cover first and which shall we add later? This decision depends upon the strength and type of the dependencies.

Find the balance between adaptability and speed 

When a team can work on all components but only one feature, a team covers a complete row, as drawn in the figure below. Such a team has no external dependencies; hence they probably deliver fast. On the other hand, when a team covers all features but only one component, a team covers a complete column in the heatmap. Such a team can work on all feature-parts; hence they can adapt to all work that comes in, but cannot deliver end-to-end. 

Therefore, the size of the heat map area that a team covers strongly determines its

  • feature delivery speed
  • flexibility to pick up work from the product backlog.

Our challenge was to find the optimal balance between speed and adaptability in our 11 team context, and that depended upon several variables:

  • The teams’ cognitive capacity. When teams specialise in a customer domain they can still work on customer features without needing to understand the other customer domains of the product.
  • The type of dependencies between the elements. This helps the teams determine which organizational elements to cover first and which later.

Specialise in the Customer Domain

Our product was a large insurance system. We used interviews and questionnaires to determine where users spend most of their time when using the product. It turned out that there were a couple of main groups of users. (For this blog, I just use the 2 groups Claims and Evaluation. and call them red and yellow.) Some users mostly used the red-colored features—red area— while the other group primarily used the yellow-colored features—yellow area. The orange features are used by both sets of users—they overlap or intersect both red and yellow areas. 

The red and yellow areas let the teams specialize in a customer domain—see Requirement Areas in LeSS (less.works) and Value Area Scrum pattern (scrumbook.org). This reduces the cognitive demand on the teams.

The next step was to find the most significant heat map area that the teams could cover. 

The type of dependencies between the elements

We used the following rules to decide which elements to include from the beginning and which to add later.

  • Rule 1 – Contain reciprocal dependencies within one Value Area: The work of one team is input for another team and vice-versa, and there is uncertainty about how to accomplish the task, which makes frequent alignment necessary
  • Rule 2 – Ensure sequential dependencies between Value Areas with iterative planning: A team is dependent upon the work done by another team. Applicable to work with low uncertainty and predictable work.
  • Rule 3 – Manage pooled dependencies across Teams and Value Areas with simple coordination rules: For example, the sharing of a single test environment, or dependency of a person with a scarce skill.

Below you can see an example result for the red Value Area.

The Web, App, Siebel, Portal components are used often together and their interdependencies are reciprocal. The teams in the red area decided that they woud need to cover at least these elements.

Furthermore, you can see that the area has a pooled interdependency with Legal, and that it is a relatively strong dependency. of 14% The weakest interdependency is with Sales Force. We choose not to include Sales Force initially and only add it when the teams mastered the other elements. Legal was also not included because it was a pooled dependency.

The yellow Value Area below has a different set of dependencies.

The teams decided that they needed to cover at least the APP, Sales Force, Siebel and WEB components

For this area, Legal is not needed at all. And there is a weak sequential dependency on Portal. We decided to not include Portal in the first step. In the exceptional case that a feature needed a change in Portal the teams would coordinate with the red-area to get it done. We also used these as opportunities to learn more about Portal.

How to handle the features in the intersecting orange area? A solution is to decide based on the feature itself.

For example, F10 could be picked up by either the red or yellow area. F18 require only APP and can be picked up by the yellow area. The only complicated feature is F11. It requires Sales Force and Portal which neither the red or yellow area possess. So, how to handle this one? Well…., remember the golden rule of Scrum Mastership: “Always ask the team.”

Final Result

The product definition includes all elements, but we choose to not include Legal skills in any of the teams from the start. Why? Because it is a pooled and weak dependency. Also, the teams felt they were not yet able to cover more skills right from the start. Instead, Legal became the next activity to include in their Definition Of Done.

In the unfrequent case when a feature requiring Legal skills would appear on top of the Product Backlog, we would plan for that by working together with Legal in refinement events and during the Sprint.

At Sprint Planning, the team that selected that feature would then coordinate to work together with someone from Legal to get the feature done. Preferably, the Legal person(s) would also use the opportunity to teach the team so that they understood a little bit more about Legal at the end of the Sprint. When a team keeps selecting to work on features with a Legal part, eventually they learn enough to add Legal to their Definition Of Done. Bas Vodde calls this accidental specialization.

NOTE Not all teams need to know everything about all element in the Product Definition right from the start. Teams can have their own speciality as long as all teams as a group can pick up all element from the top of the Product Backlog.

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.