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

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

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

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

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

What is Product Backlog Refinement?

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

Below some example activities you can consider:

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

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

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

Why multi-team refinement?

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

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

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

How to do multi-team refinement?

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

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

Multi-team refinement formats

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

I work with the following 4 formats:

0. Full Roulette

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

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

1. Partial Roulette

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

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

2. Diverge and merge

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

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

3. Teach Back

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

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

Role of the Product Owner and Customers

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

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

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

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

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

In this blog I talk about how you could deal with the challenges of defining your product in a LeSS adoption.

Why do you need to define your product?

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

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

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

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

What is a product?

Most customers I work 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.

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

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

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

CRAIG LARMAN Q&A

You can see the video below:

CESARIO ABOUT LESS HUGE EXPERIMENTS

You can see the video below:

Back in the early days of Scrum, the Scrum Master role was exciting. The days of the pigs & chickens, the days when being a Scrum Master was considered dangerous.

In those times there was the saying

a dead Scrum Master is a useless Scrum Master 

And even today I still use that when selecting a Scrum Master to work with. 

If you never got fired as a Scrum Master then you probably did not show enough courage to achieve breakthrough improvements.

Scrum Master as a Sheep Dog

As a Scrum Master you would work with the Product Owner on value; coach management on organizational design; and work with the Development Team on self-organization and technical excellence. The Scrum Master would strive for the team to put the product into the hands of the customer every Sprint. It was natural to work on test automation, code quality and deployment. If the Scrum Master would catch a project manager sneaking in from the back, breaking the rules and disturbing the teams, the Scrum Master would go for a frontal confrontation, or as Brian Marick once said:

“the Scrum Master would rip out their throats”. 

The Scrum Master would ensure everyone remained moving in the right direction by challenging, facilitating, teaching, intervening and cajoling. 

Scrum Master as a Lap Dog

How times have changed.

The Scrum Master role I see these days is more that of a lapdog; just like the lapdogs that Paris Hilton carries around in her fancy bags

—sit down, roll over, good boy, have a biscuit—

The Scrum Masters I too often see, are nothing like a Sheep Dog. There are the part-time Scrum Masters: for example testers or programmers who next to their full-time job, also move some stickies around in JIRA during the Daily Scrum, and run a retrospective once in a while.  I see Scrum Masters that represent the teams at the Sprint Review; are the spokesperson of the team to management; Scrum Masters that drive Sprint Planning using JIRA (Agile is spelled differently these days, it is spelled J.I.R.A.) and Scrum Masters that order the Sprint Backlog. 

On top of that, there are Agile Coaches, Agile Coaches are everywhere. Where do all these Agile Coaches come from? and why do you need one? After all, an Agile coach basically does all the same things a good Scrum Master should do. Maybe an Agile coach is just a Scrum Master with presumed better overall skills and therefore wants a better daily rate. 

All this is removing the true spirit of the Scrum Master; the Scrum Master role is going from Sheep Dog to Lap Dog.

The feedback loop on Scrum itself

The Scrum Master is a change agent, a team builder, a servant leader, an innovator and inspires for greatness. So, please do not forget the true spirit of the Scrum Master. You as the Scrum Master, you are the feedback loop on Scrum itself.


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

Over the last weeks I’ve been working on a paper about the role of a Business Analysts within Large Scale Scrum, and I thought I’d write a little post on it too, here it goes.

On the website of the IIBA you can find their definition of a Business Analyst.

liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals

www.iiba.org

In a Large Scale Scrum organization this definition often results in Business Analysts working as a liaison between stakeholder and the teams. And this liaison role turns out not to be very effective at scale.

A business analyst is not the same as a Product Owner

We know that there is only 1 Product Owner for a product, see the Scrum Guide; but in Large Scale Scrum adoptions, you often see lots of Product Owners although only 1 product is being developed. You can expect to see that each Development Team has its own unique Product Owner (PO) and that a BA plays the PO role. This is an understandable and easy step to take for an organisation; all you have to do is change the role name from BA to PO.

All these BAs stay a liaison between the Development Teams and the customers. And the liaison role introduces unnecessary hand-off; documentation; information scatter; and poor customer understanding by the teams – see my paper Copy Paste Scaling for more details on this.

A BA can play the role of a PO if she has the right market understanding, skills and mandate; but it is generally a bad idea in Large Scale Scrum to have a separate BA play the role of PO for each Development Team. Instead keep it simple, have 1 PO and create true cross-functional teams. 

From recomending to developing

A BA with a responsibility for analysis alone does not work anymore and the reason is simple: Analysis is not something that adds customer value on its own; it is just one of the activities in the end-to-end value chain. So you would like to avoid locally optimising Business Analysis. Instead you would like a BA to be responsible for delivering working product and that they directly work on validation and implementation of the product.

These days it is essential to validate assumptions quickly. Answers to questions like:

  • Are we solving the right problem?;
  • are we solving the problem correctly?;
  • and does the solution add enough value to us?

 requires frequent feedback. 

Therefore, you would like to have a BA as one of the Development Team members, just like a programmer, tester or domain expert are too. Now, the BA can use its expertise, which is essential for success, more effective and help to optimize the whole of product development.

As a Development Team member the BA:

  • keeps a focus on the end result;
  • can see if ides actually work;
  • can adjust rapidly if ideas do not work;
  • can easily share his expertise with the rest of the Development Team;
  • and can take the lead during refinement sessions. 

So, if you want to optimise for speed, agility and learning, it is probably better to have a BA be part of your Development Team and not be a fake Product Owner.

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

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

Human resources

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

Continuous improvement

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

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

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

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

The model emerges

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

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