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.

On September 12 2019, we ( Nadine, Joris, Vaishal and Cesario ) provided the keynote at the LeSS conference in Munich. We shared the story about how we improved the Spotify inspired ING model with LeSS. My friend Rowan Bunning was present at the keynote and wrote a super nice summary of the talk. You can find his blog here.

The paper ‘Why Isn’t Your Current Approach to Scaling Agile Working?” written by Cesario Ramos co-authors with Kurt Bittner was recently published on InfoQ.

Having trouble scaling your agility? You’re not alone; even organizations who have agile success in isolated pockets have trouble scaling that agility to the broader organization. The challenges express themselves in familiar patterns. Do any of these look familiar?

  1. Your copy of another organization’s model doesn’t work
  2. Your organization’s design conflicts with the goal of agility
  3. You are trying to “copy and paste” what works for one team to all teams
  4. You are independently optimizing different parts of the organization
  5. You are under-invested in agile engineering practices

In this paper, we discuss common systemic challenges for scaling agility. We close with a comparison between the approach to these challenges by popular scaling frameworks.

You can read the complete paper at InfoQ here.

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.

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.

Conclusion

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.

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 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.

Endnote

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.”

References

  1. Larman, Craig; Vodde, Bas. Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn)) (p. 73). Pearson Education. Kindle Edition.
  2. https://blog.odd-e.com/yilv/2017/01/is-team-in-scrum-feature-team.html


( a.k.a. The Waterfall Game)

Goals of the game

The goal of this game is to understand how organisational design using component teams leads to the waterfall and unnecessary complexity. In this game, you experience how a typical scaling approach I call “Copy Paste Scaling” results in not so good things in organisations. 

Copy Paste Scaling is what I see most companies do. What they do is scaling by adding Scrum Teams and as a result, they have multiple Scrum Teams; instead of multiple team Scrum. And then need to add all kinds of extra complexity to their organisation.

Overview of the game

We are a product development group of a company called StickyArts. We develop graphics using only Sticky notes. 

Our product consists of several deep specialities. These skills need well-educated people with lots of experience working on the single speciality. Some companies have Java, Android, iOS, MainFrame, SAP, Billing, Legal etc as specialities. At our company, the specialities we have are Sticky notes of colour Blue, Red, Green, Orange and Yellow. 

The product that we need to create is the text “LeSS = Scrum”.

LeSS is Scrum backlog

In order to build our product, we work in teams of at most 5 people. The teams are organised into single function teams. So, there is 1 team per colour sticky note and we have a Red team, a Blue team etc. 

Needed supplies

  • 5 Teams of at least 3 people
  • 5 flip charts or A0s and wall space for the teams to work on.
  • 7 tables
  • 5 packs of different colour post-its.
  • Thick sharpies for each colour for the Analysis Team.
  • Caps or Hats; 1 Program Manager Cap, 5 Integration Team Caps, 5 Product Owner Caps, 2 Project Manager Caps.
  • 1 Printed Product Backlog, see below an example. (download here)
  • Printed decompositions of PBI letter ‘e’, see below for an example of letter ‘e’ ( download here ) 
  • The printed template for the letters ‘L’, ‘S’,  ‘S’,  ‘=’, ‘S’, ‘c’, ‘r’, ‘u’, ‘m’. Each letter on a separate A3 paper. These are needed for the Analysis team to do the decomposition (download here)
  • Game Rules that everyone in the room can see. 
  • Timer
  • WhiteBoard/Flipchart where you keep track or progress
  • StickArts.com Logo

Paper to handout for further reading after the game

WORKFLOW

The teams do the following steps in parallel but synchronized:

  • Start each Sprint with 1 min of Sprint Planning. ( how should we build our PBI? )
  • Then we have a 2 min development episode. The teams build their PBIs. ( Build it by using post-its. )
  • and end the Sprint with 2 min of retro where each team proposes an improvement.  ( what dynamics do we see and what can we do to improve? )

The facilitator of the game acts of the owner and has final say on organisational design and acceptance of the product. 

After each retro, the facilitator leads a discussion about the dynamics that are observed and the teams’ proposals for improvement. Out of the organisational design improvements, you choose 1 proposal and implement it.

PRODUCT BACKLOG (DOWNLOAD UPDATED HANDOUT HERE)

LeSS Game product backlog

EXAMPLE DECOMPOSITION OF LETTER ‘E’ (DOWNLOAD UPDATED PBL HERE)

LeSS Game letter e

FACILITATOR GUIDE

Step 0. SET-UP THE ROOM

VELOCITY-CHART

  • We are going to track the teams’ velocity to see progress each Sprint for each team, to use it for Sprint Planning and to track PBIs done.
  • Create a Velocity Chart for the 5 teams for 5 Sprints.

RULES – A0

Create on an A0 Paper the rules of the Game to that it is visible during the game.

  • A team only works its own speciality.
  • Sprint Planning 1 min
  • Sprint 2 min
  • Retro for improvement of the system 2 min
  • You cannot form other DEVELOPMENT teams. 
  • You can introduce other types of teams.
  • We Improve the system based on your feedback from the retro

PBL – A0

  • Glue the Product Backlog on a wall or door in priority order en explain the PBIs. The order of the PBL is from left to right: “LeSS = Scrum”. 
  • Explain the Product Backlog. It is ordered in Value and it already has estimates on it you see.

SPACE

  • Each team needs a flipchart or wall space with A0 papers and also their colour stick notes.
  • Table space for the Analysis Team as far away as possible from the development teams.
  • Table space for the Integration Team as far away as possible from the development teams.
  • Enough wall space for the end product ‘LeSS = Scrum”. 

Step 1. ORGANISE INTO DEVELOPMENT TEAMS 

So, first step: Let’s organise into DEVELOPMENT teams by management

  • For example: “You are 1, you are 2 you are 3 etc”
  • Explain: You are DEVELOPMENT team with all the skills from development, to testing to ship your speciality colours.

REMEMBER: You can only work within your own speciality and use your own colour sticky notes.

START SPRINTING

SPRINT 1

  • GOAL: Understand that there is a mess and propose to introduce an Analysis Team.
  • Give each team a PBI and then you can start Sprint Planning of 1 min.

EXPLAIN AGAIN: You can only work on your own speciality because otherwise, that would not be efficient 🙂 

Ask if there are any questions?

IF they say something like: this is stupid, we cannot complete a PBI because it required multiple components THEN say yes that is the result of component teams. SKIP Sprint 1 and ask the teams to come up with a proposal to fix it.

  • Set the timer for the Sprint
  • Start Sprint Planning for 1 min (optional).
  • Start development episode for 2 min
Sprint LeSS Game

At the end of the Sprint ask:

  • what is your velocity? Nice all worked very hard
  • how many PBIs are done? …. 🙂 
  • Update the Velocity Chart for each team. 

 Facilitate: 

  • “Interesting, we only created parts of PBIs, but the most important PBI also did not get done. 
  • Facilitate what they see happening around them. What dynamics they see etc. 
  • Point out the dynamics of local optimisation and creating wastes. 
  • Now ask: “I want the most important PBI to get done the next Sprint. And you are only allowed to work within your single speciality.”
  • And then ask: “Please have a 1 min retro and come up with a proposal for improvement”. 

 After their retrospective: 

  • Ask each team one at a time what their proposal is.
  • Facilitate the retro results so that they propose something like an Analysis Team. Once they propose such a thing you choose that proposal to be implemented. 
  • Each team will have 1 person that speaks on behalf of the team and will share the team proposal for improvement. You make them the ‘volunteers’ to be part of the Analysis Team as Team  Product Owner.
  • Invite them to leave their teams and become the Team Product Owner and take a seat at the Analysis Team tables. Give them their Analysis Team hats and hand them A3 papers and colour stick notes to work with.
  • Add Analysis Team to the Velocity Chart and start tracking their progress too.

SPRINT 2

GOAL: Understand that there is a bigger mess and that work needs to be integrated

Important: Let the teams throw away their work in the first Sprint because it did not work anyway. The teams start Sprint 2 clean.

  • Show the teams the decomposed letter ‘e’ so that they understand how it looks and what the Analysis Team needs to do.
  • Show the Analysis Team the PBL with the next PBIs that need to be decomposed.
  • Point out that each Team PO needs to decompose as much as possible for their OWN team.
  • Explain that in this Sprint the development teams will produce their part of the decomposed letter ‘e’ PBI while at the same time the Analysis Team will decompose as much PBI from the PBL as possible.
  • Hand out the prepared decompositions letter ‘e’ to each team. Each team gets only its own decomposition by colour.
  • Tell the analysis team that they need to work on the Product Backlog and decompose as many PBIs as possible for their own team. For example: The Team PO of the Blue team can pick the template for letter ‘L’ and then draw blue squares on the A3 paper on the right location. After all blue squares are on the exact location the decomposition of letter ‘L’ for the Blue team is done.
  • Set the timer for the Sprint
  • Start Sprint Planning for 1 min.
  • Start development episode for 2 min

At the end of the Sprint ask:

  • what is your velocity? Nice all worked very hard
  • how many PBIs are done? …. 🙂 
  • Update the Velocity Chart for each team. 

What happens is that a lot of work got done, but nothing is integrated. 

Second LeSS Sprint

Facilitate: 

  • Facilitate what they see happening around them. What dynamics they see etc.
  • “Please have a 1 min retro and come up with a proposal for improvement”

After the retrospective

  • Ask each team one at a time what their proposal is.
  • Facilitate the teams’ proposal and let them propose something like an Integration Team. Once they propose such a thing you choose that proposal to be implemented. The members that speak on behalf of the team are the ‘volunteers’ to be part of the Integration Team.
  • Invite them to the Integration Team tables and give them their Integration Team hats.
  • Explain that their task is to get the parts from the teams and integrate them into a DONE PBI on the wall. They will need to get the A0-papers from the teams and combine it into a single A0 with the complete PBI.
  • Point out the dynamics of Integration Teams, waterfall, handoff, delay, information scatter, not being able to work on highest value PBI and therefore optimising for ‘ass to chair time’ etc.

Note: Add Integration Team to the Velocity Chart and start tracking their progress too.

SPRINT 3 & 4

GOAL: Understand that there is even a bigger mess; that nothing really gets done and that work is being done out of order creation queues and coordination problems.

In this Sprint:

  • The Integration Team is integrating PBIs from the teams.
  • The Analysis team is analysing the next PBIs.
  • The Development Teams are developing their part of the PBIs.
  • Set the timer of the Sprint
  • Start Sprint Planning for 1 min.
  • Start development episode for 2 min

At the end of the Sprint ask:

  • what is your velocity? Nice all worked very hard
  • how many PBIs are done? …. 🙂 
  • Update the Velocity Chart for each team.

The waterfall is there…

Facilitate: 

  • Facilitate what they see happening around them. What dynamics they see etc.
  • Point out all the dynamics of Component Team and the effect of having to do waterfall.
  • A lot of PBI is being developed out of sync because they work of the PBIs do not distribute evenly across the teams. To manage this and ensure that the right pieces are integrated you need a solution.
  • “Please have a 1 min retro and come up with a proposal for improvement”

After the retrospective

  • Ask each team one at a time what their proposal is.
  • Facilitate so that the improvement proposal you choose is to introduce project managers to handle the coordination and keep track of the work. Give the project manager the Project Manager hat.

Fire all of them

  • Now, explain that you do not like this. 
  • You spent a lot of money and very little got done.
  • More and more people are added for coordination, integration, design, analysis who are not doing value work.
  • Facilitate discussion about the dynamics of adding special coordination roles like Project Managers.
  • Now, fire all people. “You are all fired…”
  • Rehire all of them and let them organise into feature teams.

Give each team a PBI and start a new Sprint. (The teams will likely finish a PBI on the wall by themselves.)

  • Set the timer of the Sprint
  • Set the timer of the Sprint
  • Start Sprint Planning for 1 min (mandatory).
  • Start development episode for 2 min
  • Update the velocity chart for each team.
  • Facilitate discussion about Feature teams and the dynamics.
  • Hold a retro for improvement.
  • Pick 1 improvement
LeSS Game Overview

Have final Sprint.

Facilitate Recap of the whole game by using a distributed retro technique where the teams come up with their most important learning or concepts. 

LESS HUGE EXTENSION

For LeSS Huge, with more than 25 people, you can introduce Areas. One Area does the ‘LeSS’ part and the other Area does the ‘Scrum’ part.

If you want to do “More” here is an additional PBL with More

Enjoy,

Cesario, Pascal 

Creative Commons License


The LeSS Dynamics Game by Cesario Ramos is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Based on a work at https://agilix.nl/blog/534-the-less-dynamics-game.

Some companies develop 1 product with 10s to 100s of people using Scrum. And they do that without adding any roles, events or processes to Scrum. They can do this because they use an organisational design that optimises for the right goals.

Design Goals

An organisation has a design, just like a truck or a Formula-1 car have a design too. A big truck is designed in such a way that it can efficiently move cargo from point A to point B. The efficiency usually comes at the price of long maintenance times. Changing the tyres e.g. is pretty hard work; it is usually done with a couple of people, requires lifting equipment and takes hours to complete.

The design of a Formula 1 car is optimised for speed and flexibility, and the car is not designed to keep working for a long time —1 race is enough. During a pitstop, more than 20 people work together and change the tyres really fast. All of the people have a specific task and spend most of their time waiting for others to complete their task. Working with this design makes it possible to change tyres much quicker than with the truck design — the world record was 1.92 seconds.

If you want to be able to change the tyres of a big truck in 1.92 seconds, you can try by using one of those Formula-1 pitstop teams. But that won’t work, you will just end up with new roles, new tools and a new process. The design of the big truck is simply not optimised for speed; if you want to change the tyres of a big truck in 1.92 seconds you have to redesign the truck.

Organization Design

A common organisational design is the Hierarchy. The Hierarchy optimises for a lot of things, but not for adaptability and speed.

John Kotter highlights some other importing goals of the Hierarchy.

”…the challenge is that, at both a philosophical and a practical level, the Hierarchy (with its management processes) opposes change. It strives to eliminate anomaly, standardize processes, solve short- term problems, and achieve stopwatch efficiency within its current mode of operating…” – John Kotter

Some more optimising goals of the Hierarchy are control and resource utilisation a.k.a. ‘ass to chair time’.

The Hierarchy leads organisations to be designed as single function groups. The groups are managed by single function managers and have key measures and targets to assess how well they are performing.

There are groups that specialise in a part of the business like for example contracting or billing. Next to that, you also see specialisation in technology like for example, Java, .NET, Oracle and so on. Furthermore, you can find groups specialising along functions like testing, architecture, security and project management.

The Optimising Goals of an Agile Organisational Design

There is nothing wrong with the Hierarchy as long as it’s optimising goals are in line with the goals you want to optimise for. But, if you want to become Agile you probably want to optimise for the following goals:

  • Shortest Lead time – The delivery time from idea to working product in the hands of the customers;
  • Adaptability – Being able to change direction fast and at low cost and
  • Learning – Learning about the customer needs and wants; learning about the product, the used process and organisational design.

And these goals are not in line with the goals of the Hierarchy.

Organisations who want to become Agile in the Hierarchy often try by introducing new roles, new ceremonies, new processes and artefacts; but it is very unlikely that they will succeed. At best, they will end up doing lots of Agile ceremonies, with new fancy names for the same old things, but will not become Agile. It is like bringing the Formula-1 pitstop team to change the tyres of your big truck in 1.92 seconds, it just won’t work! 

So, do not ask how to scale Agile across your Hierarchy.

Instead ask: How to redesign your organisation and become Agile?

To become Agile you need an organisational design that optimises for the right goals! This often means an organisational redesign with very broad impact. Below a few typical steps to take:

  • Design your organisation around your product so that it optimises for delivering a customer feature end-to-end without delay. You do not want to optimise on resource utilisation or ‘ass to chair time’.
  • Find a Product Owner that understands the market, has an entrepreneur mentality and give her the funding to lead the product lifecycle.
  • Develop teams that can produce end-to-end customer features (a.k.a. Scrum Teams) and use them as your main organisational building block.
  • Organise your teams, that work on 1 product, to work in a single iteration. And ask them to produce an integrated product increment every iteration so that you maintain a consistent view on progress.
  • Move to cross functional line managers working in a cross-functional organisation so that single function optimisation is discouraged.
  • Introduce a Human Operations system that also values team work and strives for the right competencies.

Find out more

As one of the ScrumPlop authors, I strongly recommend to read the pattern sequences we wrote. Furthermore, I recommend the LeSS publications and Nexus Guide for learning more about building your Agile organisation.

The first ever LeSS conference was held in Amsterdam on August 30 and 31. An amazing 186 participants from Australia, Japan, the USA, Finland, Singapore, Switzerland and many more joined us for 2 days of sharing, learning and self-management. 

We, the organisers, did not want it to be a commercial conference, in the sense that there would be booths and sponsors influencing the speaker list and so on. We wanted it to be about practitioners sharing real world insights about LeSS adoption. And about letting the world know that there is a way to Scale Scrum and keep its values. We also wanted people to experience LeSS in person.

For the practitioners, we introduced an Experience track with all kinds of case studies on LeSS and LeSS huge adoptions. 

For experiencing LeSS in person, we introduced an experiments track. We did 3 main experiments.

  1. Having a team based conference;
  2. Having a Open Space parallel to all other sessions;
  3. Forming into communities. 

Furthermore, we did not plan for breaks, only for lunch; did not have a program printed; and we did not have a single person who was in charge. I remember that the people of the venue were searching for the one person to make all decisions, but this person was not there. We all made decisions and leadership emerged.

It was fun for us, confusing for some and insightful for all.

Different kind of conference

So, the LeSS conference was a little bit different to a ‘traditional conference

Traditional conferencesLeSS conference
Program printed and stableProgram only online and changing.
Drinks, beer and wine costs extraDrinks, beer and wine included.
Price over Euro 1000Price Euro 250
Organisers guess what people need and create appropriate program with tracks and timelines.People need to decide for themselves and decide what works for them
People work as individualsPeople work in teams
Mainly consultants doing talksMainly practitioner doing talks
There is 1 person in the leadOrganisers use situational leadership
You expect to be entertained and sit backYou are encouraged to actively participate and take ownership of your learning.
Make moneyNeeded to add money out of pocket 🙁
1 t-shirt3 t-shirts

Team experiment results

The teams-based conference experiment is considered a success. We now know that we are going to repeat this at the next LeSS conference in London 2017. A lot of people told me that they really enjoyed working with the team; getting to know people and socialising was good, and especially the discussions after the sessions.

“…people in my team went to the same talk but had very different views on what was said…the discussions we had gave some great insights…”

Of-course not everybody enjoyed the team experiment, but then again you cannot please everybody all the time 🙂

Community experiment results

The community experiment is considered a success also. We now know that we are not repeating that one :). But I am actually happy with the results. A number of new LeSS communities started in Berlin, The Netherlands and also online using Slack and our LinkedIn group is growing rapidly. @Viktor is having a busy time accepting all the requests.

What’s next

We are already planning for the next LeSS conference in 2017; it will be in London. We are also already thinking about new experiments to do. So, if you have suggestions the coming year, please share them with us.

Oh, yes, we do not want to loose any money next year and will aim for break even.

Hope to see you in London next year.