Success with LeSS: Is it right for your project?

In the dynamic world of software development, where complexity and uncertainty are omnipresent, companies face a crucial challenge: How do they lead their projects to success?

Agile methods are used as a compass to guide teams through turbulent waters.

In this article, we share our experiences with Large-Scale Scrum (LeSS) in a customer project. We show the challenges we faced and how we overcame them. Before we get into the details, we want to develop a good understanding of LeSS (Large-Scale Scrum) and explore its additional features compared to traditional Scrum.

What is LeSS?

LeSS (Large Scale Scrum) is an agile framework for managing multiple Scrum teams[1]who work together on a product. The aim of LeSS is to simplify the application of Scrum principles in large companies through the use of defined rules and guidelines[2]. Depending on the company structure, two types of LeSS can be implemented in a company[3]:

Basic LeSS: with 2 to 8 teams
LeSS Huge: with more than 8 teams

These teams have the task of creating high-quality products in collaboration with other teams.

LeSS vs Scrum

LeSS still has many of the practices of One-Team Scrum. The following elements are also in LeSS[4] to find:

Product backlog
Product Owner
One Definition of Done for all teams
A potentially deliverable product increment at the end of each sprint.
There are several teams, but they all work together as one Scrum team
All teams work simultaneously in the same sprint rhythm

What is different with LeSS are the following points[5]:

In contrast to sprint planning as in One Team Scrum, LeSS has two sprint planning sessions. In the first Sprint Planning the Product Owner works together with all team members to make decisions about the distribution of the Product backlog items (where the "what" is discussed) and the second is then carried out in the teams, where the "how" is discussed. The Second Sprint Planning and the Daily Scrum are conducted independently by each team and can sometimes involve two or more teams for learning purposes. A member of team A can use the Daily Scrum team B in order to improve the exchange of information.
With LeSS there is an optional and short Overall Product Backlog Refinement (PBR) with a product owner and representatives from all teams. The aim is to define the items for the next detailed Single Team PBR to select. The Overall PBR offers the opportunity to improve coordination between the Product Owner and all teams. The Single Team PBR is analogous to the One Team Scrum PBR. With LeSS, however, there is also the option of a Multi Team PBR. Two or more teams are present in order to achieve a greater exchange of knowledge, understanding and transparency between the teams.
The Sprint Review is similar to the Scrum Sprint Review, but with several teams. A review bazaar is held for the product increment review phase, where different teams present their results at different locations and anyone interested can see the results.
Another meeting that is not part of the one-team scrum is the Overall Retrospective. It comprises the Product Ownerthe Scrum Master and Rotating representatives from each team. The aim here is to explore improvements to the overall system.

LeSS in a customer project

One of our customer projects for the development of an e-commerce store, in which we were employed as IT designers, was originally structured according to the Scrum framework. It consisted of a feature team made up of developers, IT designers and UX designers. As there was only one team, the IT designers had a certain amount of flexibility in their work. The project was then restructured according to the agile method LeSS, whereby they formed several feature teams. Each feature team consisted of developers, UX/UI designers, testers and IT designers.

During the overall refinement, representatives of the feature teams (IT designers and some developers) selected which user stories would be prioritized for the next refinement phase.

The next refinement phase took place in parallel in various virtual rooms. This was possible with the help of the tool Teemyco[6] possible. Each virtual room consisted of at least two, but also more teams. The prioritized user stories were distributed randomly across the virtual rooms.

During the sprint planning meeting, only the representatives of the individual teams were present and during the sprint reviews, some developers or members of the teams meet to present their progress.

Challenges

This restructuring led to various challenges for the team:

The project overview was no longer clear for some team members: Since LeSS is based on the principle that anyone can do anything, team members had to work on a little bit of each topic. They could not work on one topic from start to finish, which meant that they lost track of operational topics and priorities.

Knowledge management, communication and coordination problems between the teams: Around two to four refinements took place in parallel in virtual rooms, so the experts for certain topics were often not present where they were needed. The IT designers responsible for describing the user stories were assigned to a fixed feature team and this team had to follow them into the virtual rooms where the user story was presented. However, the topics of the user stories often did not match the expertise of either their feature team or the team present in the virtual room. This happened because the topics were not shared according to the expertise in the virtual rooms. This led to communication problems in the feature teams and the refinement was often very slow and silent.

Restructuring of the teams

In order to improve the working conditions in the project, a reorganization was carried out that required UX/UI and IT designers to work independently of the feature teams in the project due to their roles. This is important because the UX/UI designer must have an overview of the user journey and the IT designers can work on the various topics independently of the feature teams.

Each feature team was assigned a specific section of the store user journey. FOR EXAMPLE: Team A takes care of all functions related to the shopping cart and checkout, Team B takes care of the product detail pages, etc. Each section of the user journey has a series of epics that the feature teams had to work on. An IT designer was then responsible for an epic and worked on it in collaboration with the business analysts. The refinements took place in the individual feature teams and, if necessary, for example if one or more feature teams were working on overlapping topics, they could hold the refinement across feature teams. The advantage of this adaptation is that the refinements take place in smaller groups and this creates expert knowledge in the respective topics, as work is carried out on a topic from the beginning to the end of an epic.

Our assessment

Although LeSS is designed to facilitate the use of Scrum across multiple teams working on a single product, implementation is about more than adopting a framework; it is a journey that requires an awareness of context. Restructuring our client project based on LeSS brought with it knowledge management, communication and coordination issues. These challenges were overcome by further restructuring within the teams, with team members working on topics relevant to their expertise.

If you are considering applying LeSS to your next project, it is important to recognize the unique complexity of your project and understand the dynamics of your teams. The individual teams can also discuss with each other different solutions that they can use to improve their collaboration with the other teams.

Take on the challenges on your next LeSS journey - they pave the way for further development.

Get professional support for your IT project management!

Take advantage of the many years of experience and comprehensive know-how of doubleSlash's certified project managers. From project planning to successful implementation.