Large-Scale Scrum (LeSS)

Large Scale Scrum

Scaling Scrum addresses the questions/challenges that arise when applying Scrum (Agile) in a significant context: an organisation or project with multiple teams and possible multiple products. The scale can vary from a few teams to dozens of teams (e.g. a few hundred or even thousands of people). As such a framework for ‘Large scale,’ Scrum should scale indefinitely. The challenges/issues involved are cross-team coordination, organisational design, impediments resolution, backlog refinement and building one integrated product. Said, all the challenges you face in 1 team Scrum, but on a (much) large(r) scale.

The first advice given is: do not scale Scrum, do not multi-site! If you can create your software product with one team, go ahead and work with one team.

Large Scale Scrum (LeSS) can be called a ‘framework’ for scaling Scrum, but rather it defines a set of additional rules and guidelines. These rules are very much aligned with Scrum and feel very natural. LeSS does not introduce an extra detailed process layer on top of Scrum. In that perspective, LeSS is very straightforward and lightweight.

Large Scale Scrum = Scrum. This is rational and recognisable but does not take away the challenges. This is aligned with the vision of scaling Scrum by the official Scrum institutions: get basic Scrum right for your teams, scale only if necessary. Scale professional Scrum. Transparency is the key element to success. Unfortunately, most (large) organisations are very un-transparent in most things. A scaling Scrum framework remains a framework (not a one-size-fits-all solution) for complex product development. Teams will need to apply practices and methods and measure work empirically.

LeSS and LeSS Huge

  • LeSS: Up to eight teams
  • LeSS Huge: Up to a few thousand people on one product

LeSS clearly defines building one integrated product with 1 product backlog. Sprint planning part 1 happens with all teams (or with team representatives). The Sprint Review is for all teams to review the potentially shippable Product Increment together. The focus is on the whole product. An Overall Retrospective does not exist in standard Scrum. Its purpose is to retrospect the previous Sprint (s) from a product perspective cross-team.

LeSS Huge provides a set of rules for a setup with a lot of teams – the ‘tipping point’ is ~ 8 teams, but it rather depends on the feeling and workload of the product owner. Suppose the product owner cannot handle the workload anymore to own his backlog. In that case, LeSS Huge provides an answer by introducing ‘requirements areas’ (a set of customer-centric feature areas) with an additionally responsible product owner per requirement area.

Flip the system

A key takeaway is that top-level management support is required to transform an organisation to become influential in agile product/software development. As such, this is not new, but essentially – in the context of Large Scale Scrum – this implies the ‘go’ or ‘not-go’ decision.

A LeSS consultant talks to the management to discuss the required changes in organisational design and good engineering practices. If the management is not convinced or does not acknowledge the need for such changes, the LeSS adoption would be a ‘no-go’.

An adoption flips the organisational system for one particular product (or product group), not for the whole organisation. When the adoption of this 1 product is successful, you continue to spread to adopt the way of working to other organisation products.


A part of the course addresses the adoption and the preparation involved to adopt LeSS. The path to agility is a path of continuous improvement. There is no perfect time to start agility; rather, ‘initiation’ of the transformation to agility can begin at any time.

There are different views on when to start the first Sprint: you can start right away (knowing you will not be able to produce a potentially shippable product increment at the end of the first Sprint), but you deal with it empirically and transparently during your sprints.

On the other hand, you foresee a preparation period that involves activities to get started:

  1. Educate everyone (including management)
  2. Design cross-functional (feature) teams and create feature team adoption maps
  3. Define the 1 definition of done
  4. Make the product owner, an actual product owner
  5. Keep project managers away from the teams

The preparation includes the setup of any facilities, systems, etc. With good practice, you have a solid basis to produce working software (according to the definition of done) at the end of your 1st Sprint.

The course

The Certified LeSS Practitioner is a three-day course, quite interactive. Craig organises his course by explaining some content, immediately followed by an individual, team exercise or in-class example. We’ve exercised lots of mind mapping to recapitulate what we’ve just learned and an activity on causal-loop modelling. After the course, I’ve created my overall mindmap of the course contents, which I’ll use as a link to explore other topics. Both Ari Tikka and Ahmad Fahmy were present during the course. They have both experiences adopting LeSS (Ari in Nokia Networks and Ahmad in Bank of America Merill Lynch).

Craig takes time to address almost every question, or concern raised or parks it with consideration. He emphasises core Scrum and empirical process control very much (as he should).

Craig breaks the course in unequally time-boxed pauses and spices it up with miscellaneous valuable and useless stuff and quite a few bad Canadian jokes (no further spoilers mentioned here) J

Each participant received a copy of the scaling books + print-out of the slides (the slide deck is about 300 slides). Any particular multi-site or offshore agile development issues are part of the resources but not addressed in the course. Most large organisations have some offshore/nearshore development ongoing (or past this, after lots of misery) – it would have been exciting to get some more explanation or guidelines on this topic.


After completion of the course, you are a Certified LeSS Practioner. The Scrum Alliance also accredits the course as an added qualification on the topic of Scaling Scrum Fundamentals.


The site provides a lot of info on the framework. It’s much recommended to read the material on the site (it contains a lot): minimum minimorum of the LeSS rules, but mostly read the LeSS framework, principles, and structure.

Craig Larman and Bas Vodde are agilists with lots of experience in Scrum and scaling Scrum/Agile. Craig focuses on organisational redesign and systems thinking and serves as a consultant for large-scale Scrum and enterprise agile adoption.

Craig and Bas have authored the following main books on Scaling Lean and Agile development:

2010 – Practices for Scaling Lean and Agile Development – Craig Larman, Bas Vodde

2009 – Scaling Lean and Agile Development – Craig Larman, Bas Vodde

2015 – Large-Scale Scrum: More with LeSS, Craig Larman, Bas Vodde,

This article expresses my view regarding the Large Scale Scrum (LeSS) Practitioner course, given by Craig Larman – March 2015, Brussels. In case of any remarks or questions, don’t hesitate to reply.

My LeSS mindmap

(click for full-size image)

Mind map Large Scale Scrum (LeSS)
Mind map Large Scale Scrum (LeSS)

Scrum Scaled for Large Projects and Organizational Initiatives

“Lately, we have watched with amusement and then growing concerned as the methodologists have rolled mega processes they assert are the silver-bullets to scaling.”

Ken Schwaber

A growing concern, I must concur. I also experience how organisations are struggling and seeking how to scale Scrum. Recently, Gunther presented the issue at #atbru (Agile tour Brussels) in his talk “Empirical management explored”.

My observations:
* Organisations not yet able to decently organise Scrum at the team level should not embark on a journey to scale Scrum beyond that team level.
* If such organisations attempt to scale Scrum, they will scale dysfunctions.
* Organisations still stuck in the classic management paradigm are steer-less to get product creation organised incrementally and iteratively. These organisations mix Scrum with many waterfall practices (predictive long-term project planning, wild guesstimates, lack of transparency). On the way, they end up with a self-defined framework, mixing it all up.

The bottom line is:
* Invest wisely to get organised to transform your teams to Scrum
* Invest wisely to maximise Scrum at a team level, following with multiple teams and following with multiple products > this subsequent growing approach is the sound approach to scale
* Live and breathe the Scrum Stance and agile values
> Invest in people and teams
> Manage and plan based upon real metrics and evidence
> Focus on business value

Wat voornamelijk niet doen bij het vergroten van agile teams

How NOT to scale agile

“Scaling” agile betreft het schalen van agile groter dan het team niveau.

Tiago Garcez @tcgarcez gaf hierover een interessante sessie op #atbru 2014. Slides: “How NOT to scale agile”. Deze post is gebaseerd op zijn sessie.

Er werden redenen aangehaald dat agile niet zomaar geschaald hoeft te worden; en dat een aantal  praktijken in organisaties haaks staan op agile waarden.

1. Projecten

Projecten zijn per definitie eindig. Echter, verandering en transformatie naar een agile manier van denken en werken is niet eindig.

2. Resource planning

Resource planning optimaliseert het gebruik van resources. Typisch in een organisatie betekent dit dat mensen verschillende activiteiten uitvoeren voor meerdere projecten. Individuen worden ook vaak opnieuw ingepland op andere projecten, en in andere teams ondergebracht. Dit is nefast voor de productiviteit en de samenhorigheid van een team. Een medewerker in deze omstandigheden heeft last van context-switching en ziet niet het resultaat van zijn werk.

Bottom-line: investeer in teams en hou goed werkende teams stabiel.

3. Focus niet op efficiëntie

Maar focus op effectiviteit. Efficiëntie betekent optimalisatie (van resources). “Een resource die niet werkt is niet efficiënt“. Wat we nodig hebben zijn individuen die effectief zijn in hun activiteiten. Het over focussen op efficiëntie leidt in middelgrote tot grote organisaties tot nefaste effecten waarbij medewerkers niet de kans/tijd krijgen om zichzelf te ontplooien of om goede werkrelaties op te bouwen met collega’s.

4. Focus op de eindgebruiker

Vaak zien we projecten heel sterk focussen op de (interne) klant, en vergeet men wie de feitelijke eindgebruiker is. Met een juiste aanpak (lean UX, incrementele persona’s, herhaalde testing met eindgebruikers, …) en technieken kunnen we meer zeker zijn dat hetgeen wat we bouwen effectief nuttig zal zijn voor de eindgebruiker van het product (en niet enkel de interne klant: bv. het marketing departement, …).

5. Schaal geen incompetenties

De basis is belangrijk: get the basics right. Slechts als een team agile ademt, kan je bekijken hoe je kan uitvergroten over meerdere teams heen. Alle agile waarden zijn belangrijk, en niet enkel dat. Denk niet dat goede engineering praktijken er niet meer toe te doen. Expertise, vakmanschap en een agile samenwerking zijn de basis voor productiviteit en resultaat. Als je dit bereikt hebt in meerdere teams, kan je kijken hoe je dit kan schalen over de teams heen.

6. Geen traditionele carrière paden

Organisaties focussen heel erg op een carrière pad dat start bij een beginnende functie en vervolgens het individu promoveert tot een ‘hogere’ functie. Vb. van junior ontwikkelaar, naar senior ontwikkelaar, naar team manager, naar project manager. Of van business analist, naar manager. Van junior associate, naar senior associate, naar partner. What’s in a name?

Laat mensen doen waar ze goed in zijn. Verplicht hen niet om een bepaald carrière pad te bewandelen indien met ‘hogerop’ wil geraken zowel qua verloning als aanzien bij een hogere anciënniteit. Een ontwikkelaar die zijn werk met passie en expertise doet, kan dit met passie zijn hele carrière beoefenen – en waardeer hem daarvoor met een gepaste remuneratie. Idem dito voor alle andere rollen. Hou een carrière pad gezond en op maat van het individu.

Persoonlijk hou ik niet van senior functies. Senior kan duiden op de leeftijd, maar het gaat hem voornamelijk om de ervaring, kennis en aanpak.

7. Schaal geen processen

Schaal geen processen op een blindelingse manier. Het op grote schaal toepassen van een proces (zoals Scrum) zonder de agile waarden zal leiden tot een heel mechanische manier van werken. Investeer eerst in de teams, hun cultuur, hun doelstelling en het onderling vertrouwen.

8. Schaal niet indien niet nodig

Bekijk of dat het toepassen van agile op grote schaal onontbeerlijk is. Hebben we meerdere agile teams die succesvol en correct werken? Wat is de huidige norm van agile projecten? Kunnen we succesvol zijn in het realiseren van meerdere agile teams? Is het überhaupt nodig voor ons om teams te schalen?

9. Stop outsourcing omwille van foute redenen

Mijn suggestie: stop outsourcing omwille van foute redenen. Organisaties gaan vaak de mist in als men al hun activiteiten wilt outsourcen. Mijn inziens het pijnlijkste voorbeeld hiervan in het outsourcen van research. Een organisatie heeft er alle baat bij om research intern te verwezenlijken: behoud de kennis, train mensen in de technieken en stop niet met het (markt)onderzoek na oplevering van de studie.

Do not outsourch your research.

Scrum en scaling

Opinies verschillen. Huidig is over het scalen van Scrum volgende gedefinieerd:

  • Scaling Scrum
  • SAFe (Scaled Agile Framework)
  • LeSS (Large-Scale Scrum)
  • Andere frameworks…?