Scrum prescribes one person in the role of Product Owner (PO). Not multiple people, not a committee, just one person:

“The Product Owner is the sole person responsible for managing the Product Backlog.” (Scrum guide)

And when multiple teams work on a single product, the Scrum Guide says:

“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.” (Scrum guide)

I encounter many companies that fail to implement this specific Scrum guideline. Apparently, according to most companies, this is one of those things you need to tweak “to make Scrum work in your context”.

The apparent need for multiple PO’s

When companies need to scale up their development effort, they tend to copy complete Scrum teams, including the Product Owner. They soon find out that the PO role does not scale that well by multiplication. As they lose transparency over responsibilities, they try differentiating the PO role in various types of PO’s such as Feature Owners, Epic Owners, Component Owners and more. They are looking in the right direction to solve their problem but choose the path of complexity instead of simplification: When working with multiple teams on one product, you only need exactly one Product Owner. A product is a real product that satisfies a customer need and people want to pay money for it. 

In many cases I see that there is not a problem in handing over the authority and accountability for the whole product to one single person. However, people resist to having a single PO because they consider the concept to be unrealistic. They feel having multiple PO’s and multiple product backlogs is a necessity for various reasons: 
– The scrum guide says we need one PO per team, which means we must have multiple PO’s as we have multiple teams. (This is a myth; One Product Backlog means we need one Product Owner).
– The domain knowledge for a complex product like ours is too vast for one person to grasp.
– The workload to produce all user stories is too big and cannot be handled by one person. 
– There are too many meetings in Scrum for a single PO to attend.
– With multiple PO’s the PO-availability for teams can be provided at the required level.
– It is easier to have many PO’s as it avoids the fight over who should become the one real PO.
– We come from a situation where we thought we needed one PO per team. Now that they are working here, we cannot just send them away.
– This is space to fill in some silly argument you have heard in your organization.

Downsides of having multiple PO’s

Having many PO’s encourages micro management of teams. In a Product Owner per team situation, the PO becomes the person that spells out all the detailed specs (user stories). This setup leads to teams focusing on story readiness, negotiating the level of story detail instead of focusing on value creation. This is a well known pattern known as the “contract negotiation game”. Another effect is the growing absence of domain expertise in the teams. Domain knowledge is concentrated in the PO, which makes the team stick to executing tasks (opposed to solving customer problem), which re-enforces the need for more PO’s. The PO per team setup reduces opportunities for learning and self-organization. I normally suggest to make the PO’s part of the development teams they work with. They will get the opportunity to become multi-skilled development team member with a focus on analysis.

Many PO’s requires coordination and alignment. The PO’s decide in a PO team to agree who takes care of which items on the Product Backlog. The customer features are sliced and each PO gets their own sub-scope of the customer value in a Product Backlog. The work is sliced on arbitrary and artificial grounds, creating a coordination need to deliver an integrated product by the end of the sprint. Also, prioritization is decentralized and will lead to local optimization per backlog. This inevitably introduces asynchronous dependencies between teams, as some teams are “full” and cannot do certain work other Teams depend upon. Teams don’t have a whole product view and loose track of what is customer value. If the coordination need is high between PO’s, then probably the Product Backlog has not been sliced to optimize for minimal dependencies and the teams are not structured to serve that goal. Having only one PO managing a single Product Backlog for multiple teams creates the transparency required for proper empiricism.

Many PO’s bring unclear responsibility and ownership. One PO means that one person is accountable for the ROI on the product under development. With multiple Product Owners, accountability, responsibility and ownership are oblique. Management has a tough job getting a grip on Product development as there is no “single neck to wring”. Multiple PO’s stimulates part-time jobs,by adding the PO work to someone’s existing workload. This introduces a conflict of interest. With multiple people working part-time on one product the situation does not get any better. Volunteers come to the rescue, thinking “if nobody takes care of this, then I will” and change backlog item priority, add items or even create their own backlog, creating more complexity. In such cases I suggest to restore transparency by extending the Definition of Done gradually to include the work described in the additional backlogs or simply merge them into one single Product Backlog. 

What if it fails?

If your PO cannot handle the work involved managing the product:
– Being a PO is a difficult job and not everybody can do it. Hire someone else, or maybe you can fix it by sending the PO to a proper training.
– Reduce the number of features (user stories) in the backlog, they are probably too detailed. Aggregate specs to a low number (3 to 5 stories per team per sprint) to experiment with. 
– Stimulate “prioritization over clarification”. Reduce the level of detail at which the PO is dealing with features by explicitly bringing the clarification responsibility in the team. The PO can help by connecting the team to a stakeholder or customer. 
– Limit the planning horizon to no more than 2 to 3 sprints of work ahead, as preparing more work is likely to result in waste. If you are able to predictably specify your work more than 3 sprints ahead you maybe should not be doing Scrum as your product is not complex enough.
– Prevent the Product Backlog from spawning by extending the DoD, continuously reducing technical debt with merciless refactoring and strict bug policies.


The PO role is better not scaled by multiplying PO’s as this has many downsides. I encourage to have a single Product Backlog and a single PO being responsible for return on investment when developing one product. Having a single Product Owner creates transparency and enables proper empiricism. The concept of a single Product Owner in a scaled environment (multiple teams working on a single product) is challenging if you stick to the idea that the PO has to manage every detail. When scaling, try shifting the PO focus from clarification to prioritization. This will encourage the teams to better understand what needs to be created for the product. This approach is completely in line with backlog management described in the Scrum guide:

“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.” (Scrum Guide)

Do you want more of this? Join us in one of the upcoming PSM-1 trainings.

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 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 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 addresses 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 difference 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 a all-at-once approach that if often used for a smaller LeSS adoption. The other approach one is an incremental approach, using a Feature Team Adoption Map which is typically used in LeSS Huge adoptions. (See Feature Team Adoption Map Explained for more details)

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 organisational 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 antoher company integrating your product into their product);
  • Identify some typical needs these users want 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 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 find 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 severaly reduce adaptability at the compant 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.

When talking about LeSS adoptions, the Feature Team adoption map (FTAM) is often brought up as one of its powerful tools. Although FTAM is described in the LeSS book (1), and gets a great deal of attention in most LeSS practitioner classes, it plays a less important role in LeSS and LeSS Huge adoptions than we might suspect. However, it is a valuable tool that can be used for various purposes.

What is it?

I was not able to find a formal definition in the LeSS literature, but I think we are pretty close by saying: “The feature team adoption map is a graph that displays a team’s ability to deliver “done”, expressed as the potential technology work scope inside the team and the degree of cross-functionality in the team”.

The Definition of Done (DoD) shows the abilities of a team in terms of the activities required to deliver a potentially shippable product, which is the same as the team’s degree of cross-functionality. The FTAM extends this with the team’s knowledge of the product domain, which is the same as the team’s degree of cross-component ability. Stated in other words, the FTAM is an extension to the DoD, adding a second dimension (of product) to that concept.

The FTAM picture below is used in the LeSS book.

Feature Team Adoption Map in LeSS and LeSS Huge

Although the FTAM tool is described extensively in the LeSS literature, it not used in LeSS adoptions and only exceptionally in LeSS Huge adoptions. Let me clarify this.

In the LeSS book (1), the use of Feature team Adoption Maps is described in two guides:

  • “Guide: Feature Team adoption maps” (page 90)
  • “Guide: Transitioning to Feature Teams” (page 106)

The FTAM is not described in the LeSS rules, but in the guides. Guides in the LeSS book are defined as: “A moderate set of guides to effectively adopt the rules and for a subset of experiments; worth trying based on years of experience with LeSS. Guides contain tips. Usually helpful and are an area for continuous improvement; e.g. Three Adoption Principles.”

This implies using FTAMs might be helpful but it’s not mandatory when adopting LeSS.

smaller LeSS Framework

According to the guides, the FTAM can be used when adopting feature teams. Adopting feature teams is not uncommon in LeSS adoptions, as the LeSS Rules state that “the majority of the teams are customer-focused feature teams”. Creating an FTAM then:

  • helps in defining the scope of the feature teams,
  • helps to define the size of your LeSS adoption,
  • sets future improvement goals.

In practice, the FTAM is not commonly used in the smaller LeSS framework adoptions (in contrast to LeSS Huge framework). This is because LeSS adoptions are relatively small. The product diversity is small enough for everybody to understand “done” on both cross-functionality and product domain.

LeSS Huge

When adopting the LeSS Huge framework, the FTAM can be used:

  • to define the adoption context which will clarify the current degree of team specialization.
  • to support the incremental LeSS Huge adoption strategy of “gradually expanding scope”, in which the FTAM is used to mark the future scope expanding goals. However, the LeSS adoption principles suggest a preference for a narrow and deep approach, which the “gradually expanding scope” approach is not.

When can the Feature Team Adoption Map be used?

You will find great value in using this tool with the purpose of supporting:

Feature team adoptions:

Your organisation wants to move towards feature teams coming from component or functional teams. In large organisations the amount of variations in team abilities and software components might be overwhelming. Drawing maps will visualise how you can group your components into features, thus revealing the learning effort required by the teams and the impact the transition will have on your organisation.

Preparing LeSS Huge adoptions:

During the preparation phase of the creation of the initial Requirement Area(s), the FTAM serves as a useful thinking exercise to extract as many preparations as possible. It will help us get the most of the flip-needs visible; without the structured way of thinking through preparation needs for a flip we will definitely will miss out on some obvious things that are needed making the flip more difficult.

Growing towards perfection:

When your organisation is working with feature teams, your current DoD is likely to be imperfect, as with (almost) everything in life. There are always new activities that can be added to the abilities of the feature team to deliver closer to truly “done”. You can use this tool as a beacon to guide the teams’ growth towards perfection. In a company I worked we identified the activities of “creating user manual” and “making instruction video” as future cross-functional team activities.

How to create a Feature Team Adoption Map

The FTAM can be created when we want to transition to feature teams or when we want to monitor team growth towards perfection. On the vertical axis of a FTAM we plot the product, and on the horizontal axis we plot the Definition of Done (DoD). In the chapter “Getting started” the LeSS book describes step 1 (define product) and step 2 (define done). Combining the output of these steps into the feature team adoption map provides big context.

The Vertical Axis: Product

When creating a FTAM, we start with the product axis because the horizontal axis describes activities needed for “done” and that requires the context of a product. Yi lv explains this in his blog (2): “The definition of feature is dependent on the definition of product. The product bounds the feature, and the feature is end-to-end within the product.”. It is often difficult to find a common agreement on the product definition. In many cases the product definition is bent with components being defined as product, which leads to fake FTAM’s and messy setups.

The LeSS book (1) advises a procedure of asking restraining and expanding questions to identify the product elements. Expanding questions relate to “What is bigger than our current product that would satisfy the customer need?”. Answers to this question will be in line with product strategy and broaden the current product scope. A common misunderstanding here is that the product referred to is the LeSS product, while people think it’s the customer product. The LeSS product is the product as perceived by software development. Let’s take an insurance as an example. The paper you have at home on which you can read you are insured is the embodiment of the insurance product. The software needed to provide the insurance service is the LeSS product, which includes an app, website, insurance policy administration, settlement software etc.

Asking the restraining questions should provide better understanding of our product features. The goal of knowing these features is to identify which knowledge is needed in each of our future feature teams. The question we need to therefore ask ourselves is: “What is the feature that the customer desires in our product and what components does this feature consist of?”. To be able to answer these, we need a product backlog. Using features on the product backlog, we can trace back which components of our software landscape makeup that feature and group the components by the likelihood they need to be changed together when the feature needs change. This will reveal logical grouping of components into features and thus will show future team composition. While asking the restraining questions we will also discover which components will be excluded due to organisational constraints or lack of affinity.

The Horizontal Axis: Activity

For creating the horizontal axis, we enumerate all the activities a team needs to do to produce a potentially shippable product, i.e. the Definition of Done. When enumerating the activities, pay special attention to the testing activity. Testing as an activity is too broad and should be expanded to enumerate the different types of and different levels of testing (unit, integration, pen, performance, regression,…). Order the activities from small to bigger scope, in the order the teams normally do their work. Enumerate all activities needed to get the product in the hands of the customer. If your teams are not perfect yet, this will span multiple teams and possibly multiple departments.

An example

The FTAM picture published in the LeSS book is helpful to understand what a FTAM is, but it is not specific enough to learn how to create one.

This example below is a FTAM of an imaginary company that builds a CMS (content management software). The company has set their product expansion strategy to grow towards a product that covers the customer’s financial needs. The existing component teams are capable of changing a single component, for example Portal Front End (portal FE). There are other component teams working on the Portal Back End (portal BE).

The blue rectangle represents the teams’ current capabilities. These component teams test their solution for integration problems, before handing their code over to the integration department, responsible for staging, integrating and user acceptance testing. After that, the software is handed over to the release department, who will perform the remainder of tests and takes care of deploying to the production environment.

For this organisation to move towards feature teams, the future teams ideally need to specialise in the customer domain so they can tackle customer problems at product level: CMS-problems, which means fixing front-end and back-end code in portal, manager and platform components. Unfortunately this is not possible yet as this company is working with a near shore partner who is currently taking care of all portal component changes. To create perfect feature teams, all knowledge will need to be co-located and this is not possible in the short term. The new feature teams that will be created initially will be able to handle all software changes at system level: a portal, a manager and a platform team.

This is not ideal, but a good step into the desired perfection direction. The Product Owner verified the features in the Product Backlog to ensure that there are very few features that require changes in multiple systems (portal, manager and platform), i.e. there is low dependency.

The DoD for the new feature teams (the orange block) does not include user acceptance testing. The cross-functionality level of the new feature teams was set to the minimal set of capabilities (up until system test), as this is the level of Done that all new feature teams can deliver. Some future feature teams were already able to include the activity of user acceptance testing, but unfortunately not all teams were capable of doing so since there were not enough people with the right skills (yet).

An organisational constraint is present on the activities axis: after user acceptance testing, the software is handed over to the support department, responsible for penetration, performance and deployment. At this point in time, developers are not granted physical access to these environments due to existing security policies.

The Feature Team Adoption Map makes visible the current and future state of the feature teams’ capability to deliver “done” product. It may be difficult to create teams with full product scope and all activities covered as it would require a too much organizational change that could possibly incur business risk. In such case, these capabilities are excluded from the current scope of the teams, by which the FTAM serves as a visualisation of the perfection goal.


In this article I have tried to explain what a Feature Team Adoption Map is and how it can be used. Although this article might have helped you to better understand, creating one yourself is the best way to learn. I invite you to use the approach as described and try to create a FTAM of the teams in your organisation. Do not hesitate to share your findings.

Addendum: Guides

“Guide: Feature Team adoption maps”

“A feature-team adoption map is an important tool when you are adopting LeSS. It helps with the following decisions:

What is “all”?— A smaller LeSS framework adoption requires an all-at-once change to feature teams. Who is included in “all” depends on the scope of the feature teams.

Future improvement goals— The map can be used for setting future goals (…). These future goals frequently go hand in hand with the expansion of the Definition of Done. The map also shows the expected changes and their difficulty, as expanding beyond the current organizational boundary involves the hard work of “political” boundaries.

LeSS or LeSS Huge?— The scope of the feature teams influences the size of your adoption and can swing a LeSS group into adopting LeSS Huge instead. For example, a network-performance tool is a customer-centric product and its development-group size leads to the smaller LeSS Framework. However, when realizing it is always sold as an integrated part of a network management system changes the product scope and then is likely a LeSS Huge adoption.”

“Guide: Transitioning to Feature Teams”

“When adopting (smaller framework) LeSS, the transition to feature teams is all-at-once. But when adopting LeSS Huge, you can choose from several transition strategies. Which one is best? These simplistic steps help you determine the best strategy for your organization:

Determine Your Context: The transition to feature teams is influenced by several factors:

  • Size of the product group— (…)
  • Lifetime of the product— (…)
  • Degree of component and functional specialization— More specialization makes feature-team adoption a larger change. Use the feature-team adoption map to draw the current state of component/functional specialization.
  • Number of development sites— (…)

Determine your Transition Strategy: There are three broad transitioning strategies:

  • All-at-once— As also used in LeSS adoption. (…)
  • Gradually expand component team responsibility— You can plot the current state of your organization in a feature-team adoption map and mark future goals for expanding the scope of the teams. (…)
  • Parallel organization— In this strategy you keep the existing component team organization in place and gradually build a feature team organization next to it as a parallel organization.”


  1. Larman, Craig; Vodde, Bas. Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn)) (p. 73). Pearson Education. Kindle Edition.

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.


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.  


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.


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.


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.


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: 


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 .