The third blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Creating Agile Organizations by Cesario Ramos & Ilia Pavlichenko

What is a Product?

A commonly used definition of a product is “something that is made to be sold.” 

“A product is anything that can be offered to a market that might satisfy a want or need”—McGreal, Don; Jocham, Ralph. The Professional Product Owner

The product provides a way of making a profit—or another value, for instance, social impact in the case of not-for-profit organizations. We use this definition and augment that with the following product properties:

  • A product has users who are people.
  • A product provides features to those users that address their needs and problems.
  • A product has a business model; revenue stream, independent profit & loss (P&L), or return on investment (ROI).
  • A product is developed and sustained by a system of people, components, and processes.

Most customers we work with organize teams around smaller areas of functionality with no straightforward end-user, customer or value proposition. In these cases, you find that the teams are working on just a part of the real product. The part they are working on is often a component or a specific activity in the business process; they use a narrow product definition. When many teams work on a product-part (that they call a ‘product’) then that group likely experiences unnecessarily reduced agility and long end-user feedback loops (We described this in the first and second blog).

Broad v.s. Narrow Product Definitions

A broad product definition usually implies that the product spans lots of components and activities and provides solutions to the needs and problems of end-users. We prefer a broad product definition because that gives adaptability and short feedback loops. Why? There are several reasons:

  • Wide product definition encourages all teams to focus on one Product Backlog that consists of end-user product increments Therefore, teams get a whole product focus and can learn about many product areas. 
  • Wide product definition encourages teams to increase work across product parts which reduces inter-team dependencies and thus shortens the feedback loop.

In Figure 1.1 the CLD explains how the broadness of a product may affect the speed of delivery.

Product Definition Agile

Figure 1.1Broad product definition effect on end-user feedback loop. (copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Some product examples at our customers:

  • Small Medium Enterprises Banking
  • Media platform
  • Energy Trading System
  • Mortgage

Examples of product-parts:

  • Internal CRM system
  • Credit conveyor process
  • Opening accounts process
  • Website of a bank

Product Definition from Different Perspectives

The product definition that marketing uses might not be the same as the product definition used by the development group, which is perfectly okay. From a development perspective, the product definition is for optimizing adaptability to deliver value. From a marketing perspective, it might be beneficial to have a different product definition to address marketing goals like product identity and connecting with certain types of customers. For example, one of our banking customers has different kinds of loans with associated benefits and plans. These loans are presented as different products by marketing, but internally they are defined as a single broad product by the development group because if you look internally, the majority of functionality is similar for both products and they share the same architectural components and systems.

A Systems Approach To Your Product Definition.

A systems approach considers the whole first and then improves the parts only if it also improves the whole. The whole, in our case, is the product, and the parts are the teams, users and systems. Furthermore, Russel Ackoff points out that the performance of a system is not the sum of its parts, but the product of their interactions. Therefore, we first define the whole product with all its parts, and then we redesign to improve their interactions.

How To Define the Product

The product definition determines what organizational elements (people, components, processes, and systems) will be part of the first step in your transformation. Your product definition determines:

  • Who will be the Product Owner.
  • What work items are on the Product Backlog.
  • Who are the users of the product.
  • And also, which organizational parts like teams and departments you need to develop and run the product.

You can define your product using the following two steps:

Step 1. Identify the required organization elements to develop and sustain the product.

Step 2. Clarify the revenue streams.

Let us give a brief overview of these two steps

Step 1: Identify the Required Organizational Elements

You start with the elements—your component teams—you currently call products, activities, people, and processes in your group. You then study how the work works for your group to understand the types of dependencies that exist to develop, maintain, and sustain your product. 

The typical steps to achieve this are as follows:    

  1. Identify typical external end-users of your group. 
  2. Identify the needs these end-users want to be addressed or tasks they need to complete.
  3. Identify features for each of the users that they consume to address their needs or perform their jobs.
  4. 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)
  5. Next, you want to identify the organizational elements that are needed to produce the feature and satisfy the customer. You do that by studying how each feature flows through your organization into the hands of the customer. You start at the boundaries and work through the components, systems, people, and processes until completion. 

In our book, we show a few examples of facilitating product definition workshops.

Product Definition Workshop

Figure 1.2Organizational elements to produce the outcomes (copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Step 2: Clarify the Revenue Stream

A broad product definition should include revenue streams. Without it, the teams in the group will likely be disconnected from market concerns where the real value lies. Further, it probably divides decision making among various parties. Typically, one party—the business— is responsible for financials and requirements, while the other party—research & development— is accountable for delivering the product requirements on time and within the given budget. Each party will locally optimize for local concerns instead of adaptability

In this step we ask the question: Do the identified organizational elements generate revenue for the organization? Or are there missing parts to do so? The way we prefer is to find answers to the following questions:

  • How do the elements together generate organization impact? For example, is the product definition able to have usage fees? Asset sales? Subscription fees? Licensing? If not, what would need to be added to the product definition?
  • What business KPIs can you assign to the product definition? For example, can you assign it an increase in gross income? An increase in new customers? Customer satisfaction?

If you cannot give a meaningful answer to all of the questions above, then consider expanding your product definition. 

Product Definition Completed?

At this point, you identified a set of organizational elements that together produce value for end-users and have a revenue stream. 

The result typically includes many components, skills, and activities, and it can involve tens to hundreds of people in total. With such a large group, you may want to ask, “How can I create effective cross-functional teams that include all these capabilities?” In the case of more than around ten teams, we recommend organizing the teams among Value Areas that could be dynamic in size depending on how the Product Owner oversees the market changes. In the book A Scrum Book we defined a value area as: “A Value Area is a valuable product part that addresses the needs of a customer segment, but which has no useful value or identity apart from its inclusion in the product”.

In our next two blog posts we give an overview of:

  • Critical change management guidelines.
  • And how to launch your product group.

Second blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Many problems at the workplace are not the fault of the individual managers or teams. They are often the result of working in an organizational design(OD) that impedes rather than supports Agility. The OD determines, to a large extent, how people cooperate, the prevailing mental models, and how work gets done. To change all of this takes time and requires people to unlearn old lessons and relearn new ones that support Agility. 

An organization redesign includes re-thinking:

  • Structure: Which organizational units such as departments, groups and teams are required? How are work and responsibility divided among those units? 
  • Processes and Integration: How do the units and roles relate to each other and collaborate?
  • People: What team and employee skills and capabilities are needed?  

Working in a new design helps the people learn what is needed to build the new capabilities.

Some examples of how design decisions can facilitate the development of capabilities are:

  • For fast adaptation to customer insights, consider creating a short feedback delivery process that allows fast learning about the customer. Allow decision making by people who work closely with the customers.
  • For teams to take ownership of delivering customer value, consider designing autonomous teams that include all the necessary skills to finish their work independently of other groups.
  • For efficient product development flow, consider designing a reward system and career path that values people for developing multiple skills. Multi-skilled specialists reduce the bottlenecks in the delivery process.

Figure 1.1 shows that executing a business strategy requires specific capabilities, and these capabilities can be developed working in the appropriate OD.

Figure 1.1 From business strategy to organization design. ( Figure copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Contain Reciprocal Dependencies with the Product Group

James D. Thompson wrote that we should design the work by the intensity of interdependence and then introduce specific coordination techniques for each. 

There are three types of interdependence:

Pooled. Units are doing the same task in parallel or have a shared resource. Sales people often have pooled interdependence if they sell individually and combine their monthly sales numbers to get the overall result.

Sequential. Units rely on each other in predictable ways for the flow of information, work and decisions. In sequential interdependence, each unit completes its task before another in the sequence completes theirs. Classic example is an assembly line. A product must be fully assembled before it is wrapped, and wrapped before it is shipped. 

Reciprocal. Units are sequentially interdependent. In addition, they work back and forth and must adjust to each others’ actions as the situation changes unpredictably. 

The reciprocal interdependence resembles the dependencies between software development teams that work on a single product. These teams either have a mutual functional dependency—when a feature is divided into independent technical parts to be developed by different teams—or a mutual technical dependency when each team picks up a complete feature but works in the same software components and creates technical dependencies.

For reciprocal interdependence, it is recommended to manage the dependencies through constant information sharing and mutual adjustments. Figure 1.2 shows these three types of interdpendencies.

Figure 1.2 Three types of interdependencies. 

A study about the implications of these types of dependencies was published in the paper Quantifying coordination work as a function of the task uncertainty and interdependence by Ronald E. Giachetti et al. They concluded—as shown in the figure above— that

First, “…the experiments find no significant difference between pooled and sequential interdependence and the resulting coordination load…“. 

And second, “…coordination load increases significantly when interdependence changes from sequential to reciprocal…“. 

Working with reciprocal interdependencies takes twice as much time to coordinate compared to work with the other types of dependencies.

Figure 1.3 Coordination load as a function of interdependence and analysability (Adapted from Ronald E. Giachetti et al)

The key idea is to first design the organization to minimize reciprocal interdependencies between units that produce value. When you group the necessary functions and skills to produce value, coordination becomes easier, flow increases, and rework decreases. It also facilitates team accountability for a complete work item instead of just a part. The teams can now become autonomous and can manage their work. The organization can stop giving work packages to a team to execute and instead provide customer problems for a team to solve.

Redesign into a Product Group

In the book, The Toyota Way11, pp 304, Jeffrey Liker, Professor of Industrial and Operations Engineering at the University of Michigan, recommends organizing around product families. Each product family has a senior manager responsible for the product family and controls all the resources needed, including maintenance, engineering, and quality. Such can go fast because it contains all work dependencies, but it can also quickly relocate resources to areas of highest demand. An Agile organization benefits from the same capabilities and might use a product group that is defined by:

  • Its purpose or function within the organization
  • The organization elements required to achieve its purpose or function such as cross-functional teams, shared functions, systems, roles, accountabilities and responsibilities
  • The senior manager that leads the product group. It is a person with a deep understanding of the product and process.
  • A market-focus and/or profit & loss responsibility
  • Product decision-making autonomy

Avoid Designing the Product Group from the Inside Out.

An inside-out design is based on an internal business process or the system architecture.

Let us provide two examples of design from the inside-out: 

  • One of our customers develops a trading system, and the process of registration, trading, and billing consist of 23 process steps. How did they design their structure? They had 17 teams, and each team worked on one or two business process steps, even though a feature largely required multiple business process steps to deliver value to a customer.
  • Another customer developed material analysis systems. The system architecture consisted of components like Motion Control, Data Extraction, Data Analysis, and many more. How did they structure themselves? They had one or more teams per architectural component, although 80% of customer features required changes in most components together. 

Such designs make it hard to adapt to customer value; instead, they concentrate locally, optimizing the individual teams’ performance. 

Prefer Designing the Product Group from the Outside In

To design the product group from the outside-in:

  1. Start with the customer problems that need to be solved.
  2. Study how solving those problems for your customer works in your organization.
  3. Determine which organization elements such as units, processes, and people are needed to create customer value.
  4. Combine them into a product group.

Our next blog discusses how you can define your product group. 

First, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko.

​What does it mean to be Agile on a large scale?

According to Craig Larman, a renowned consultant, reducing switching costs by learning is resisted most by any organization. Speed of delivery can be quickly “sold” to management. But speed is by far insufficient to be Agile at the organizational level. Instead, the biggest issue in becoming Adaptable is narrowly specialized teams that stem from the lack of team and management investment in team learning.

Below is an example of how narrow team specialization hinders adaptability as scale.

Once, we consulted a product company building a portal with an innovative fintech system that processed payments among hundreds of countries. The organizational design consisted of several feature teams that could deliver usable increments to the market every couple of weeks. Even though teams were feature teams, they specialized around tiny business domains to “maximize focus and thus speed of delivery”. All teams could only pick up items corresponding to their business knowledge. Suddenly, when a crash happened in the market, one of the teams got overloaded with the number of changes they had to deal with. 

Figure 1 below illustrates the trap that the organization got into. On the left of the figure, you can see that each team specializes in a narrow domain. ( e.g. Grey team can only work on Grey backlog items ) On the right side, you can see that the highest value work exceeds the capacity of the black team, and no other team can help.

Figure 1 Changes overloading the narrow specialized black team. ( Figure copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

The organization turned out to be fragile, unable to absorb significant change.

Optimize for Adaptability

Imagine a product group with six cross-functional teams, see figure 2. Each team can pick up any feature that comes into the product group, which means that all teams in the product group can always work on the most critical work. Also, imagine that all teams optimize for delivering a feature in short cycles (e.g. two weeks) from an idea into the hands of the end-user. This means that they have fast feedback for learning. As a final step, imagine that the teams split large work items into small items, to work on each cycle. 

Figure 2 Product group optimized for adaptability. (Figure copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Such a product group has the conditions to be maximum Agile. Why? Consider the following 3 reasons:

  • All cross-functional teams can pick up the most important work, so the product group can react to the work that comes in with 100% of the teams. Contrast this with specialized teams in the figure 1.1 that have a limited work scope comprising their area of expertise. When the most crucial work exceeds the capacity of the specialist teams, no other team can help, and therefore the product group can not adapt and focus on the highest value work.
  • A big piece of work, for example, a project in a traditional project organization, is split into small items of end-user value. Now, instead of assuming that the whole big item is “required”, the teams only deliver the high-value items in short iterations and ditch the low-value ones altogether. Large items convey lots of information, are made full of assumptions and therefore carry high risks. So, the product group does not focus on the question: “How can we deliver all the “requirements” in this big item?” but instead answers the question: “what is preventing us from achieving the intended outcome?”. It avoids fixed work scope and re-plans for the highest value every cycle.
  • The group learns from short feedback loops and puts that learning back into the plan on what to work on next. Hereby reacting to changing conditions as more is learned and discovered.

The 3 main concerns to create Adaptability at scale

Creating such a product group requires certain capabilities to be in place. For example, the teams need to have the skills to work across all product domains, technical components, applications, and tools. This implies minimizing costs when switching between jobs and getting the work done as effective as required; how to do that? There are three main concerns to address:

1. Minimize switching costs from moving from one work item to another, because teams don’t have all the parts or information. These include learning costs, cognitive costs, and the cost of a team stopping existing work and starting new work.

2. Minimize transaction cost: the cost of overhead activities. In Lean, these are activities that are either necessary but non-value-adding waste (temporarily necessary waste) or unnecessary activities that could be eliminated (pure waste). In Agile software development, transaction costs are in activities other than software design, programming, and verification, including communication, coordination, and repeating manual activities like manual deployment or testing. The critical point is that your software must be soft enough to change it quickly, at a low cost, and validate if it delivers what is expected. The way to lower the transaction costs on software development is to use appropriate engineering practices, including effective automation of the build and test process and eventually automation of the delivery pipeline, and these are just a start. 

3. Flow Efficiency over Resource Efficiency. The final concern is the learning speed of the product group: the ability of fast delivery to create short feedback combined with the quality of measuring to decide what is most important to work on next. In software development, for resource efficiency, it is more important to ensure each team always has a feature to work on. For flow efficiency, it is more important that a feature is always being worked on. So, in resource efficiency, the work is likely queued before each team to always keep them busy. Whereas, for flow efficiency, the goal is for teams to be ready to pick up the highest value work. This implies teams are expected to learn to understand to work effectively on multiple areas of the larger product.

So, for Adaptability at scale, an organization needs more than fast delivery. It also requires a design that promotes broad learning to change direction effectively; without it, you get local team improvement at best.

The latest revision of the Scrum guide removed the Development Team role with the intention to remove the “us vs. them” dynamic. In this paper Cesario Ramos and Ahmad Fahmy discuss its possible implications.

You can find the paper by Cesario Ramos and Ahmad Fahmy on InfoQ

In this talk, Cesario shares some Agile Organization Design principles. You can use these principles to have a more informed discussion in your agile transformation.

See also the upcoming book Coaching Agile Organizations.

This article is about how we improved on the Dutch Bank Spotify inspired model in a tribe.

We work with over 20  teams on our Business Lending product.

We develop our product across 3 sites, with dispersed teams. Each team contains business, IT and operations skills. In this configuration we deliver valuable product for our customers every 2 weeks. We did this by amongst others, adopting LeSS principles to further optimise our Spotify inspired way of working.

So, how did we transform? Read the complete case study.

In this little blog I share some tips for multi-team Product Backlog refinement.

What is Product Backlog Refinement?

Product Backlog Refinement (PBR) is an activity that Scrum Teams regularly do to clarify potential upcoming Product Backlog Items (PBI). In single team Scrum, typically the Scrum Team gets together for one or more workshops during a Sprint to create and maintain a Refined Product Backlog

Below some example activities you can consider:

  • Understanding what is the right problem to solve: The Product Owner tells a coherent set of stories with a goal and links them back to the business objective. The team discusses “why we are doing this?”, “how do we know we are solving the right problem?”. Some teams use story-maps, impact-maps, Speedboat, Me and My Shadow, or the 5 Whys. 
  • Splitting big items for discussion and learning
  • Estimating items for learning and alignment
  • Understanding Customer needs: The team discusses “Why does the user want this?”, “Are we solving the problem right?”. Some teams use a Storyboard (before/after) and Pain Gain maps.
  • Clarify Items: Some teams use Specification By Example and create acceptance tests for the user stories; use story narratives with Gherkin specifications, flow tables and/or decisions tables.
  • Define Exploratory Test Charters: Identify risks to target; Identify which features need manual testing. Some teams use exploratory test charter for each and use exploratory testing tours to test as a team.
  • Create initial designs: Modelling at whiteboard, design sketches,…

( see our paper in Testing Experience magazine for some more examples ) 

Teams that work together on a single product can benefit from doing multi-team refinement. But how can you do refinement with multiple teams at the same time? And why should you?

Why multi-team refinement?

Multi-team PBR is when all members of all teams refine PBIs together without yet deciding which team will implement which item.

Below you can find some benefits that multi-team refinement can give you: (there are many more benefits, but that would make this blog too long)

  • Adaptability at the product level. Why? because all teams understand all PBIs on the Product Backlog, instead of each team understanding only ‘their’ PBIs ( a subset ) of the Product Backlog. If all teams understand all PBIs then the PO can put any PBIs she seems most valuable at the top without being constraint to the PBIs a particular team understands.
  • Improved self-coordination: Why? because the teams maintain a broad understanding of the whole product and the upcoming PBIs, and therefore are more likely to know of “dependencies” between PBIs.
  • Transparant measure of progress at the product level. Why? because all teams participate in estimating all PBIs and therefore there is one common velocity at the product level, instead of a distinct velocity per team that needs to be combined into a total.

How to do multi-team refinement?

The activities for single team refinement can also be used with multi-team refinement; the biggest change is in the facilitation of large groups.

I like to create new groups from the teams that participate in a refinement session instead of using the regular teams. So, let’s say that there are four teams A, B, C and D. Then at refinement, I ask the teams to form four new groups, each group consisting of a person from team A, B, C and D. Why? With groups consisting of members from each team, all PBIs are refined by at least one person of every team. This creates a shared ownership and broad understanding about the PBIs.

Multi-team refinement formats

When I work with teams, I show the teams 4 ways of doing multi-team refinement so that the teams can then choose the way they like most to continue with and improve.

I work with the following 4 formats:

0. Full Roulette

Each group picks a PBI for refinement and start refining at their station. After a timebox -I like 15 min timeboxes- all groups move to the next station and continue refining where the other group left off; this is continued until the PBIs are refined or the workshop timebox expires. The groups can use whatever technique the like for refinement. 

The full roulette results in good refinements because the groups feel pressure to leave their work clear and understandable as possible for the next group.

1. Partial Roulette

Just like Full Roulette, but instead of the whole group moving to another stations, 1 person stays at the station. This person then teaches the new group what was discussed before they continue with refinement.

I use this approach in the beginning because is that it is easy to start with. After the teams have experienced this Partial Roulette, I encourage them to try Full Roulette.

2. Diverge and merge

In this approach, the groups do a diverge-merge action after each timebox. One person stays at each station and becomes the teacher. Then all groups send a person to each of the other stations. So, let’s say you gave groups A, B, C and D. Then 1 person from group A stays at the station to teach back and 1 other person visits group B, another group C and another group D.After the teach back, the persons return to their original group and share their learnings. Any puzzles, questions are then discussed as a group.

I have worked with this technique with up-to 35 people or so.

3. Teach Back

Each group picks a PBI and refines it. After the timebox is over, each group teaches their work so far back to the other teams and have a Q&A discussion. 

This technique works not so good with a large number of teams, because the teach backs easily take too for long for big groups, and its harder to have a focused discussion with lots of people.

Role of the Product Owner and Customers

During the refinement sessions the Product Owner (PO) and customers play an important role. The Product Owner has to be prepared and understand what is needed from the business perspective. The PO will discuss overall topics at for example a Storymap and also participate in each group when requested. 

You also would like the end-customers or people closest to the end-customers like sales, helpdesk etc to participate in detailed refinement sessions.

The approach I like the most and have seen be most effective is the Full Roulette. If you decide to try any of the above approaches, I would enjoy hearing from you how it worked out.

LeSS Trainer panel discussion at the LeSS conference New York 2018, is publisched on InfoQ.

The LeSS trainers answer various questions from the audiance, and ofcourse there is a joke from Craig, I got a chance to talk about Copy Paste Scaling too 🙂

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.


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.

On July 10 we had our 5th LeSS Recap Day. This time it was in Amsterdam and we had Craig Larman as special guest.

We started with a talk by Cesario Ramos. Cesario talked about some LeSS Huge experiments he has been working on the in the financial industry.

Craig did a 90 min Q&S session about LeSS. The questions range from basic understanding to more advnced topics like management theory and chaning large organizations.


You can see the video below:


You can see the video below: