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:

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: 

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 blog, I talk about how you could deal with the challenges of defining your product in a LeSS adoption.

Why do you need to define your product?

In a LeSS adoption, you need to have a product definition because your product definition determines what organisational elements (people; components; processes and systems) will be part of the adoption. Your product definition determines:

  • Who will be the Product Owner;
  • What items are on the Product Backlog;
  • Who are the users of the Product;
  • and also which people you need to develop and run the Product.

For example. Let’s say you define your product as “the backend”, then your “product owner” is probably a technical person who understands the backend, and the items on the Product Backlog are likely very technical like for example “extend domain model with …”, and the “users” are other development teams.

On the other hand, if you define your product as “Business Loans”, then your Product Owner is probably a business person who understands the market of business loans, the Product Backlog will have features like “Express loan offers to small businesses”, and the users are paying customers.

What is a product?

Most customers I work with have been scaling Scrum using what I call Copy Paste Scaling and introduced narrow product definitions and lots of other problems because of that. I then have to make the teams aware, that what they are actually working on is just a part of the real product. The part the teams are working on is known in LeSS as a component.

In LeSS, we prefer that the Product is defined as broad as practical because that will give you adaptability and speed. In LeSS adoptions, this usually means that the Product spans lots of components. Also, we want the Product to provide solutions to the needs and problems of end-users. And, in the case of commercial companies, the Product must provide a way of making a profit.

When working with my customers I define a product as having the following properties:

  • It has users who are people;
  • It provides Features to those users that address their needs and problems;
  • It has a business model; (independent P&L)
  • It is developed and run by a system of people, components, and processes.

So, if you are working as a team or Product Owner on something that does not have 1 or more of the above properties, then you are probably not working on a product. Of course, there will be exceptions to the rule, it is just that I have not seen any commercial product until today that does not have these properties. 

Internal and external product definition

The product definition that marketing uses might not be the same as the internal product definition used by the LeSS product group; and that is perfectly okay!

Marketing might differentiate their product definition to create product identity and connect with certain types of customers. For example, in one of my banking customers, they have different kinds of credit cards with associated benefits, plans, etc. These credit cards are presented as different products by marketing, but internally they are defined as a single broad product by the LeSS group. Another example could be the different smartphone models (product family), as they are defined as separate products for the end consumers. Internally the smartphones probably share a lot of their (software) development components and might be defined as a single Product.

So, from the LeSS development perspective, the product definition is for optimizing adaptability, speed, and learning. From a marketing perspective, it might be beneficial to have a different product definition. 

Where does the product definition fit in your LeSS adoption?

LeSS adoptions are mostly about moving a product group from teams that focus on a small part of the whole product, to teams that have a whole product focus. At the start, the teams usually already work in an agile approach like Scrum, but the group wants to take the next step and fix their problems. ( See Scale Your Product Not Your Scrum ).

LeSS has some approaches for moving teams to a whole product focus. One approach is an all-at-once approach that is often used for a smaller LeSS adoption. The other approach is an incremental approach, using a Feature Team Adoption Map which is typically used in LeSS Huge adoptions.

In both adoption approaches you basically follow the steps below:

  1. Define your Product 
  2. Define the activities needed to have a perfect Definition of Done. ( Once you know the Product components and Definition of Done activities, you also identified the people needed to ship the product. )
  3. Let the people self-organise into Feature Teams that can cover most Product components and Done activities. 
  4. Determine how to deal with the Product parts and Done items that are not taken on immediately after the flip, if any.

Below you can find a detailed explanation of step: Define your Product.

Defining your product?

Step 1: Study how the work works

You want to study how the work works for your group so that you understand what organizational elements you need to develop, maintain, and run your product. The steps I take are:

  • Start with the things you currently call “products” (components), the people and processes you have currently in your group;
  • Identify some typical end-users of your system (could be people from another company integrating your product into their product);
  • Identify some typical needs these users want to be addressed;
  • Identify some features for each of the users that they consume to address their needs;
  • Identify the boundaries through which the users consume the features to satisfy their needs/problems etc. (for example a Browser, App, API, Connector, or Helpdesk)

Follow each of these features from boundaries through the components, people, and processes that are needed to provide the feature and satisfy the customer. Some components or other organisational elements get touched a lot of times by different features or by different users’ needs. When this happens, it is highly likely that there is a reason for that, and the reason is that these organisational elements are probably part of the same Product and not a “product” on their own. 

You will notice that your Product will be defined broader and broader, which is good if you want to optimise for adaptability, speed, and learning. It is also very useful to use the expanding questions / restraining questions as described in the guide Define Your Product of the LeSS book.

The end result will be the set of components, people and processes that define the product. 

Once you understand what organisational elements are needed to develop, maintain, and run your product, you need to define what organisational elements you want to start with. Also, the identified organisational elements could involve 100s of people and that means you probably want to use an incremental approach and divide the Product into Value Areas. But where to start?

A helpful tool to figure this out is to use a Component Heat Map.

Step 2: Component Heat Map

Now that you have your Product defined you can study your work even further. Have a look at the features you want to develop in the coming months and plot them against the components that are touched when you develop the Features. When you track the number of times a component is touched by the features, you get a sense of which components are used the most. You can say that, the more a component is used the more it lights up, hence you create a Component Heat Map.

The components that heat up the most indicate the work you have most of, and this information is very useful in LeSS (Huge) adoptions. The information helps the Feature Teams to select the order in which components are adopted. You want to optimize for that work you have most of, so the components that you need most should go first!

Also, the Component Heat Map will have various Hot Spots as you can see in the graphic above. In LeSS Huge, these Hot Spots could point to Value Areas in your Product that you can use to identify your LeSS Huge Requirement Areas.

There are more ways to identify your Requirements Areas. In LeSS a Requirement Area is defined from the customer’s perspective. Another approach to finding your areas is to ask your customers to group PBIs from their perspective.

Warning

Please remember that smaller Products are preferred, but they have to be real products.  An exception is when you have many small independent products, because then the negative dynamics of local optimisation can severely reduce adaptability at the company level. See Value Stream Fork for more details.

So far, for now, I have to go to watch a football game.

In future blogs, I will write about steps 2, 3, and four of your LeSS adoption.

I was talking to a company that is implementing the Spotify model and needed some help. They wanted to know the difference between LeSS and their Spotify model. We first discussed what LeSS is. I told them that LeSS is an organisational design that optimises for shortest lead time, flexibility and learning. What single team Scrum does for a 1 team, LeSS does for whole development organisations.

This answer started an interesting discussion on the difference between between their Spotify model and LeSS. I am not an expert on Spotify model but I understood enough about their implementation to have a good discussion. I briefly summarised the 3 main points of our discussion below:

Human resources

A possible difference between their Spotify implementation and LeSS is that they have ‘chapter leads’ that have HR responsibility over people in their chapter. So for example they can have a Testing chapter with a lead that has HR responsibility of the testers in that center of excellence; this is a single function organisational element. In LeSS we try to not have such a single function organisational structure. Instead, cross-functional managers that have HR responsibility over cross-functional teams are preferred; this promotes multifunctional-learning and therefor flexibility of your organisation.

Continuous improvement

Another point is that LeSS is based on Empirical Process Control; there is no model to copy. Copying a model from another organisation is dangerous as contexts differ and it is highly likely that it won’t provide the benefits in another context. The most value is not in copying the model itself, but in the journey of discovering a model that works for you, and all the learning that follows from that.

But even worse is that copying a model will not lead to a feeling of ownership. Ownership is promoted when people create something themselves, and if people feel ownership it is more likely that they will improve it; hence it is a precondition for continuous improvement by the people doing the work. Just copying what other people do, makes it harder to feel ownership. It will be more like renting and that makes a difference. I treat my rented cars different then the cars I own 🙂

Also, from the perspective of continuous improvement it might not be such a great idea to reach for an end state that you can actually reach; because you might actually get there 🙂 And then what?, what happens when you have implemented the model? are you then done? mission accomplished?

This company understands that and they take continious improvement very seriously.

The model emerges

So, deciding to implement a model a-priori as the end solution is like providing the answer before knowing the question. To me this is kind of silly; don’t do that. Instead you can start with the simplest process that works. And then you build it up using Empirical Process Control and a framework that makes transparent to all what to improve; that framework is called Scrum. We like to say that it is better to build your method up instead of tailoring it down. So you add stuff as the need for it emerges.

From what I understood they are doing that and doing it successfully.

In this little blog I want to share a simple canvas that I use to kick-off agile adoption and answer the following questions:

  • How to co-create an Agile adoption plan with clients?
  • How to get started with an Agile adoption?
  • How to ensure progress during the adoption?

Where to start

A way to start an adoption is to do preparation and planning. But before I can start, my clients expect me to write an adoption plan. Do you also have to write Agile adoption plans…? Over the years I wrote quite some adoption plans for my customers. All those plans turned out to evolve around the same topics over and over again. In the adoption plans I answered questions like

  • What is the objective of the adoption?
  • How do you know you are making progress?
  • Which Agile engineering practices do you need?
  • How do you start?
  • What is the role of management?
  • What organisational design changes are needed?

and more … After writing quite a few adoption plans I got tired of writing them. To make things easier for myself, I summarised the main adoption topics and main questions in a canvas. Eventually this canvas writing thing got out of control and resulted in a book called EMERGENT, which covers the canvas and more things on Agile adoption.

Overview of the Agile Adoption Canvas.

I use the canvas with my clients to co-create and grow their adoption plans. As a group, you move through all of the building blocks to create an initial plan. You start with the business objectives and end with Expert Coaching. Below a quick summary of the canvas building blocks.

BUSINESS OBJECTIVES – BUILDING BLOCK

What are our business objectives? Why are we doing this?

A common purpose of an adoption is to become a learning organisation. And for most people that is too broad and vague. It is better to find something more concrete that engages people. We know that people engage when there are clear and supported objectives to strive towards. Therefore, I like to determine and communicate the objectives of the adoption initiative. Below are some objectives I have experienced with my customers.

  • Reduce release cycles to deliver new features faster
  • Reduce cost by producing the same with less people
  • Increase agility to react faster to market changes
  • Increase employee engagement & job satisfaction
  • Increase revenue
  • Increase customer satisfaction

For change to happen and to survive the resistance that will emerge you can use a change vision; and a vision story to communicate that vision. A vision story that goes from where the company was, to where the company is now, and finally to where the company needs to be in the future.  

MEASURES – BUILDING BLOCK

How do we measure progress towards our objectives? Are we moving in the right direction?

Engagement of people is fuelled when there is frequent and clear feedback on progress towards the objectives. The measures building block is about constructing the feedback indicators. In the measures building block, you define how the company is going to assess success, measure progress towards the business objectives and learn. The EBMgt measures are a good starting point.

LEAN LEADERSHIP BUILDING BLOCK

How does management lead the transformation? What organisational re-design is needed? 

In the Lean leadership building block you address organisational re-design for optimising learning, flexibility and shortest lead time.

  • What is it about the company’s working agreements, policies and organizational structure that has to change?
  • What is it that you need to do to be able to move to Lean leaders ,coach people and to manage knowledge creation?
  • What are the changes that need to occur for people to focus on creating customer value and see high performing teams as a key asset?

Culture is about the way we do things here; and we know that culture follows organisational structure. Change is about learning; and we know that learning starts when there is a change in organisational structure. Therefore, assess your current structure and way of managing and decide what organisational redesign is needed.

CUSTOMER DELIGHT – BUILDING BLOCK

How do we co-create our innovative solutions? Are we building the right thing?

The Customer Delight building block describes how you are going to engage with your employees and your customers to understand their needs and build the right product and the right Agile process.

  • What do you need to do so the employees feel comfortable to innovate their ways of working and the company can learn how to be Agile?
  • How are you going to collaborate with your customers to get innovative insights and create the right solutions for their problems?

You can understand your employees and customers by co-creation and collaboration using for example serious games.

AGILE DEVELOPMENT – BUILDING BLOCK

Do we build the thing right?

For a change to take place you need to be very explicit and concrete about what practices people can to do in order to change their way of working. Clear examples and tips about how other peers are successful is a great enabler for change. The Agile development building block is about providing these examples. It is about the practices you can use to shorten the validation cycle. Only through technical excellence and developing high quality product can you achieve the necessary quality and productivity improvements. The Agile practices differ from industry to industry. You can find a list of Agile practices for software development in the Agile Alliance Guide to Agile Practices at url: http://guide.agilealliance.org 

EXPERT COACHING – BULDING BLOCK

What coaching and mentoring support do you need?

This building block describes what help you could need to run the change initiative. What internal or external coaching or mentoring do you need?

Supporting workshops and practices

For each building block there are a number of workshops, practices and principles to help you. I will discuss some workshops formats in upcoming blog posts.

Scaling Scrum & Agile has become a very popular topic over the last ten years. You can tell by the number of papers, talks, trainings and certification programs around it. Agile has become its own industry, as more and more enterprises want the benefits that Agile can promise.

Over the last twenty years we have been rather successful at getting Scrum to work with single Scrum Teams. Nowadays, we want to use Scrum with tens or even hundreds of teams, and an overly simplified approach to scaling might introduce big problems. 

Read the full article .