Mind map Large Scale Scrum (LeSS)

Large-Scale Scrum (LeSS)

Large Scale Scrum

Scaling Scrum addresses the questions/challenges which arise when applying Scrum (Agile) in a large context: an organisation or project with multiple teams, 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 be able to scale indefinitely. The challenges/issues involved are: cross-team coordination, organisational design, impediments resolution, backlog refinement and building one integrated product. Simply said, all the challenge 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 1 team, go ahead and work with 1 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 additional detailed process layer on top of Scrum. In that perspective, LeSS is very straightforward and lightweight.

Large Scale Scrum = Scrum. This is rational and very recognizable, but obviously 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 succeed. Unfortunately most (large) organisations are very un-transparent in most of all the things they do. As with Scrum, a scaling Scrum framework remains a framework (not a one-size-fits-all solution) for complex product development, in which teams will need to apply practices and methods and measure work in an empirical way.

LeSS and LeSS Huge

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

LeSS clearly defines to build 1 integrated product, with 1 product backlog. Sprint planning part 1 happens with all teams (or with team representatives). The Sprint Review is for all of the teams to review the one 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 on 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. If the product owner cannot handle anymore the workload to own his backlog, LeSS Huge provides an answer by introducing ‘requirements areas’ (a set of customer-centric feature areas) with an additional responsible product owner per requirement area.

Flip the system

A key take-away is the fact that support of top-level management is absolute required to be able to transform an organisation to become effective 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 goes in and talks to the management to discuss the required changes in organisational design and the need for good engineering practices. If the management is not convinced or does not acknowledge the need for such changes – basically the LeSS adoption would be a ‘no-go’.

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


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

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 in an empirical and transparent way during your sprints.

On the other hand, you foresee a preparation period which 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 as well the setup of any facilities, systems, etc. With a good preparation, 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 3 day course, quite interactive. Craig organizes his course by explaining some content, immediately follow 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 exercise on causal-loop modelling. After the course, I’ve created my own overall mindmap of the course contents, which I’ll use as link to explore further topics. Both Ari Tikka and Ahmad Fahmy were present during the course. They have both experience with adopting LeSS (Ari in Nokia Networks, and Ahmad in Bank of America Merill Lynch).

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

Craig breaks the course in unequally time-boxed pauses, and spices it up with miscellaneous useful 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 issues regarding multi-site or offshore agile development are part of the resources, but not addressed in the course. Most large organisations have some kind of offshore/nearshore development on-going (or past this, after lots of misery) – it would have been very interesting to get some more explanation or guidelines on this topic.


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


The site http://less.works 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 the LeSS rules, but mostly read as well the LeSS framework, principles, and structure.

Craig Larman and Bas Vodde are agilists with lots of experience in Scrum and scaling Scrum/Agile. Craig has a focus on organisational re-design and systems thinking and he servers as consultant for large-scale Scrum and enterprise agile adoption.

Craig and Bas have authored 2 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

There’s an upcoming book 2015 – Large-Scale Scrum: More with LeSS, Craig Larman, Bas Vodde, which will contain a structured explanation on LeSS as a framework for Large Scale Scrum. I expect this book to be much aligned with the content of the website and the content of the course, presumably filled with examples and extra guidelines.

This article expresses my personal 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-sized image)

Mind map Large Scale Scrum (LeSS)

Mind map Large Scale Scrum (LeSS)


Daily (stand-up) status meeting = GIFTS

Daily (stand-up) status meeting = GIFTS

Een dagelijkse status meeting maakt inherent deel uit van het Scrum framework. Ook zonder toepassing van Scrum, is een dagelijkse status meeting heel nuttig. Andere benamingen voor de status meeting zijn: “huddle meeting”, of kortweg: “daily”, of “stand-up”. In het Scrum framework is de officiële benaming: “Daily Scrum

De objectieven van een dergelijke dagelijkse meeting zijn het bespreken van:

  • De stand van zaken van het werk
  • Verbetering van het team
  • Communicatie in het team bevorderen

Kenmerken van een dergelijke meeting:

  • Frequentie: dagelijks (dat is de gewoonte)
  • Tijdstip: wat past voor iedereen in het team (op zich in het tijdstip niet zo belangrijk, dit kan elk moment van de dag – zolang iedereen aanwezig kan zijn)
  • Duur: maximum 15 minuten is een goede duur tijd. Het is belangrijk dat de deelnemers niet afdwalen naar het vertellen van een verhaal, of het bespreken van oplossingen. Te lange conversaties of het langdradig vertellen, moet men op een vriendelijke manier een halt toe roepen. Het verduidelijken van een vraag of onderwerp kan natuurlijk wel. Het feit dat mensen blijven rechtstaan, zorgt er voor dat er blijvende aandacht is en de voorziene tijd beter respecteert. Een facilitator kan in het oog houden dat de meeting telkens tijdig start en eindigt.
  • Locatie: zo dicht mogelijk bij de locatie van het team (indien er mensen op afstand participeren – kies een vergader locatie met de noodzakelijke communicatie middelen: tele-conferencing, video conferencing)
  • Wie neemt er deel? Iedereen van het team. Iedereen is verondersteld spreken. Een facilitator kan in het oog houden dat iedereen aanwezig is in de meeting. Een facilitator kan aanduiden wie er spreekt, of we passen een sequentiële spreekvolgorde toe, of een random spreekvolgorde (vb. door een balletje rond te gooien). Een random spreekvolgorde verhoogt de aandacht van de aanwezigen 🙂 en maakt het leuker.

Er zijn vele interessante technieken – tips & tricks om een dagelijkse status meeting levendig te houden; een interessant artikel hierover is dit: “It’s not just standing up

Een volgend acroniem is leuk om de essentie van een dagelijkse status meeting te vertellen:


Good start

De meeting is een goed begin voor het team – een goed begin van de dag – uiteraard als de meeting ’s morgens plaatsvindt :-). De meeting mag geen dagelijkse sleur worden of het aframmelen van de status. De meeting dient energie te geven! Een boost om de dag te beginnen en nieuw inzichten in te behandelen problemen of taken.


De doelstelling is verbetering. Verbetering van het werk dat het team levert, verbetering van het functioneren van het team zelf. Het zeggen van problemen, zonder effectief naar oplossingen te zoeken heeft weinig meerwaarde.


Focus op het werk, niet zozeer de mensen. De doelstelling is om de status van het werk te (gedane werk / werk nog te doen) bespreken, niet te focussen op de activiteiten van elk individu.


De status meeting is een meeting voor het team om zichzelf te informeren en beter te organiseren, het is absoluut geen rapporteringsmeeting! Vermijd dat een manager de meeting als een rapporteringstool gebruikt.


We bespreken de status van het werk en eventuele problemen of belangrijke zaken. Dit wordt typisch gedaan door het beantwoorden van 3 vragen per individu:

  1. Wat heb ik gisteren gedaan?
  2. Wat wil ik vandaag doen?
  3. Wat zijn de problemen die ik heb die me belemmeren om mijn werk te doen / taken af te handelen?

Een suggestie is om team members eerst de 3e vraag i.v.m. problemen te laten beantwoorden – zodanig dat hier voldoende aandacht aan gegeven wordt.

Visueel board

Een aanrader (must-have) is een board om zaken visueel bij te houden. In zijn eenvoudigste vorm maken we een “improvement board”, die de besproken problemen lijst. Vervolgens dient het board om bij elke status meeting de problemen te herhalen en te zien of er voortgang is voor een oplossing.

Een andere vorm is een planning / taken board. In dit geval zal het board alle taken weergeven met hun huidige status en eventuele problemen.

Voor het opmaken van een taken board, verwijs ik naar dit artikel met voorbeeld.

Scrum Scaled for Large Projects and Organizational Initiatives

Ken Schwaber’s point of view on scaling Scrum. With a smile I’ve read Ken’s comment: “Lately, we have watched with amusement and then growing concern as the methodologists have rolled megaprocesses they assert are the silver-bullets to scaling.”

Growing concern, I must concur. As well, I 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 organize Scrum at team level, should not embark on a journey to scale Scrum beyond that team level.
* If such organisations do attempt to scale Scrum, they will scale dysfunctions.
* Organisations still stuck in the classic management paradigm are steer-less seeking to get product creation organised in an incremental and iterative way, still mixing it with many waterfall practices (predictive long-term project planning, absurd 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 organized to transform your teams to Scrum
* Invest wisely to maximize Scrum at team level, and next with multiple teams, and next 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

Scrum Scaled for Large Projects and Organizational Initiatives