Sooner or later every organization that has had success working with Scrum in small projects will ask the question: Can this agile model be used for larger projects? And if so, what’s the best way to scale Scrum? In the last few years, frameworks for scaling agile management methods have gained a lot of attention. For a while now, the Scaled Agile Framework SAFe from Dean Leffingwell et al. (2011) [1] has been the center of discussion at professional media outlets and conventions. My subjective impression, however, is that Large Scale Scrum, LeSS for short, from Craig Larman and Bas Vodde (2008) [2] is gaining ground.
What is LeSS?
To put it simply, LeSS is Scrum applied to multiple teams working together on the same product. There are two frameworks behind LeSS:
- one for up to 8 teams, which is also called LeSS
- and another for more than 8 teams, called LeSS HUGE
LeSS comprises four components:
- Rules for implementation
- Guides for adopting rules
- Experiments according to the motto “experimentation makes you smart”
- Principles that offer a basis for making decisions about how to best implement LeSS in special project contexts
In this entry, I won’t discuss the theoretical basis of LeSS ([2] is an excellent source for that). Instead, I want to focus on the question:
How does LeSS work?
The answer is – more or less just like Scrum for one team:
- The roles – Product Owner, Scrum Master, Team – are the same.
- According to the principle of having a single whole product focus, there is only one (single!) product owner and exactly one product backlog, regardless of how many teams are working on the project.
- The product owner refines the product back log and prioritizes the entries – when necessary with support from team representatives .
- There’s one sprint for all teams or, seen from another perspective, all teams work simultaneously.
- Teams are cross-functionally assembled Feature Teams and are self-organizing.
- The code belongs to all teams.
- A build comprises the work of all teams.
- Teams orient themselves according to a common definition of done.
- At the end of a sprint, teams deliver one potentially deliverable Product Increment.
How is LeSS different from Scrum with one team?
An essential difference becomes clear with sprint planning. If several teams are working on the same project task, this necessarily effects Sprint Planning One and Two.
Specifically, planning sprint one not only determines – as in Scrum for one team – WHAT is to be done in the next sprint, but also WHO – that is, which team – is going to work on the entries in the product backlog. The product owner should involve representatives of all teams in this decision.
Subsequently, each individual team plans sprint two for itself. In this step the HOW of implementation is discussed. Here initial design decisions are made. For this reason, it makes sense for teams working on related issues to exchange ideas during planning for sprint two.
If you want to (or have to!) ensure traceability for the steps from refining backlog entries up to implemented user stories, or if you want to keep an overview of the current status of epics and user stories and employ comparable metrics for all teams, using the same tool for everyone involved can be helpful.
objectiF RPM supports agile projects with several teams according to LeSS. Here I’ll show you how it works.
Agile Projects with the LeSS Framework in objectiF RPM
Before I demonstrate what the planning process in objectiF RPM looks like, I’d like to show you in the video below how easy it is to add a new team to a project and to set up a working environment with all necessary analyses, documents, dashboards, metrics and backlogs. The key to this increase in productivity lies in using objectiF RPM’s pattern feature.
Set up an agile project with multiple teams according to LeSS in objectiF RPM
And here is a demonstration of Sprint Planning One and Two.
Product backlog to team sprint backlogs: planning projects with LeSS in objectiF RPM
The trial edition of objectiF RPM, which you can download here, includes all the features demonstrated in this entry. Take a look!
Sources:
[1] Christoph Mathis: SAFe – Das Scaled Agile Framework, dpunkt.verlag 2016
[2] Craig Larman, Bas Vodde: Large-Scale Scrum, dpunkt.verlag 2017