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.

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.


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

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

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

Where to start

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

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

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

Overview of the Agile Adoption Canvas.

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

BUSINESS OBJECTIVES – BUILDING BLOCK

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

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

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

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

MEASURES – BUILDING BLOCK

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

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

LEAN LEADERSHIP BUILDING BLOCK

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

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

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

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

CUSTOMER DELIGHT – BUILDING BLOCK

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

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

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

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

AGILE DEVELOPMENT – BUILDING BLOCK

Do we build the thing right?

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

EXPERT COACHING – BULDING BLOCK

What coaching and mentoring support do you need?

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

Supporting workshops and practices

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

These days scaling Scrum is a hot topic. How can I use Scrum to deliver a big product with multiple teams? The most common approach I see at my customers is scaling Scrum by adding more Scrum teams with a Product Owner and Scrum Master per team.

Scaling using Copy-Paste

Scaling is about increasing in size. I’ve been told that fire departments scale their operations depending on the severity of the fire. Depending on the scenario, they increase the size of the trucks that join the fight, the number of trucks, the number of people and the coordination and communication process as needed. This approach is what I call Copy–Paste scaling. You ‘copy’ the trucks and people needed and ‘paste’ them to form a larger group while adding extra processes for communication and coordination.

When you apply this scaling approach to Scrum this means increasing capacity by copying and pasting Scrum Teams in your development group. You add Product Owners, Product Backlogs, Scrum Masters and Development Teams. To support and coordinate this growth, organizations typically augment with special roles such as ‘feature owners’. They also add extra layers of coordination, e.g. ‘release train management’, extra processes e.g. ‘integration test phases’ and even additional artifacts e.g. ‘value stream backlogs’. Unfortunately, this approach results in diminished team-customer collaboration, leading teams to focus on delivering components in isolation, instead of an integrated potentially shippable product. And now you are slowing down rather than speeding up.

The Copy-Paste approach to scaling Scrum gets you into trouble rather quickly because of three main reasons:

  • Scrum and Agile are based on essential values, principles and practices and just adding more people does nothing about using those at scale.
  • Developing software is creative work not production work. Therefore, adding people does not necessarily increase productivity.
  • The ability of teams to independently produce valuable and bug-free product every Sprint is essential. Copy-Paste scaling does nothing about improving the required engineering practices.

An example at one of my customer sites.

One of my customers operates in the energy trading business and their development group is distributed across three sites. They initially started with a few teams, but quickly scaled up to thirteen teams over a couple of months due to market demands.

Figure 1: The added overhead of Copy-Paste Scaling. (E.g. The Green Feature is developed out of sync introducing sequential development.)

The development group supports a business process that consists of roughly thirteen steps. Naturally, following a copy-paste scaling approach, they formed thirteen Scrum Teams for those thirteen steps. Each team had its own fake Product Backlog, Scrum Master and fake Product Owner. Each team worked on a single step of the business process, even though a feature largely required multiple business process steps in order to deliver value to a customer. Therefore, the teams did not optimize for adding customer value but rather for producing lots of code.

As a result, the teams and “Product Owners” needed extensive planning and coordination in order to align their work and deliver an integrated product. Additionally this model also introduced delay in testing and customer validation; hence more defects, information scatter of a feature across teams and opaque measures of progress. The result was low productivity, high defect rates and unhappy customers.

What to do?

With large products, there are generally a lot of users. These users typically get value by working in a single area of the product. When there are many such Value Areas in your product, often you find the necessary deep understanding of all those areas cannot be maintained within a single Scrum Team. Therefore, you should scale your Scrum organization along customer domains or Value Areas.

When you specialize your teams along Value Areas as seen from the customer perspective, the teams can focus on a subset of the customers. Therefore, each team needs to understand one customer domain only, while still able to deliver complete features that the Product Owner can sell. Therefore, you only need 1 Product Owner and 1 Product Backlog and no added organisational complexity. You have multiple team Scrum instead of multiple Scrum teams. 

You can read more about this in the paper Scale Your Product Not Your Scrum and the Scrum pattern Value Areas.