This page is shown in English as no translation to Ukrainian is available.

Why LeSS?

Traditional sequential-lifecycle development doesn’t work well. It doesn’t work well for either small or large product development efforts. Since 2001, Agile development and Scrum in particular have revolutionized software development, but when asked how to apply Agile development to large groups many people say “don’t” or “just use a small team” or “do Scrum at the team level.” None of those answers is particularly useful, and while it is true that it is best to avoid adding people to your development effort, it is also true that large scale product development isn’t going away so we need to discover ways to do it well.

We (Craig and Bas) have been involved in software development for a long time in all sorts of roles in traditional sequential-lifecycle development, Unified Process, CMMi and others. None felt right. Scrum, on the other hand, felt right for single-team development. So, the question then became “How can we scale Scrum without losing its strength?”

LeSS is Scrum scaled

What is the strength of Scrum? That is not an easy question to answer. Of course, the concepts and principles behind Scrum, such as Transparency, Empirical Process Control, Iterative development, and Self-managing teams are critical. Those principles have been around for quite a while, however, so their inclusion does not explain Scrum’s success. After much discussion, we have concluded:

Scrum hits the sweet spot between abstract principles and concrete practices.

Thus, in order to keep Large-scale Scrum as Scrum, we’ll need to find a similar balance, so that we will be able to say:

For large groups, LeSS hits the sweet spot between defined concrete elements and empirical process control.

This leads to some decisions:

  • LeSS needs to be simple
    When scaling, there is a tendency to add roles, artifacts, processes, etc. This should be avoided so that a process can empirically be created by the product group. Most other scaling frameworks fall into the trap of providing a defined process. In LeSS we want to avoid that trap.
  • LeSS is Scrum Scaled
    Rather than having Scrum as a building block for a scaled framework, we need to look at Scrum and for each element ask “Why is it there?” followed by “If we have more than one team, how can we achieve the same purpose on a larger scale?”
  • Scaled up instead of tailored down
    A common concept for process development is to define a universal, overarching framework and then contextually tailor it down. This does not work well because people often assume everything is needed in their particular context. This assumption often leads to the creation of bloated processes. LeSS should be kept to the minimum. We acknowledge that scaling will require “more” but instead of “polluting” LeSS with optional elements, we have separated out a different framework LeSS Huge.

LeSS overview

The way we look at LeSS is best described in the below picture:

LeSS uses experiments

In our first two books, Scaling Agile and Lean Development and Practices for Scaling Agile and Lean Development, we framed large-scale Scrum as a set of experiments with the principle:

There are no such things as best practices. There are only practices that are good within a certain context.

Thus, the books are full of experiments that we have done. Certain things we recommend you try, certain things we recommend you avoid, and others we caution will work in some contexts but are terrible in others. This worked well and we have received a lot of positive feedback about this approach.

We also got feedback from people who were a bit confused. They needed more to hold on to… something less context-specific … some rules. Based on this feedback, we reflected and returned to the Shu Ha Ri model of learning:

shuhari.png

This model shows the different stages that learners go through when learning new concepts:

  • Shu—Follow rules to learn basics
  • Ha—Break rules and discover context
  • Ri—Mastery and find your own way

We realized that our previous scaling work did not provide anything on the shu level, which caused difficulty and confusion for people who had just started agile development in large product groups. This became even more obvious when other, more predictive scaling approaches started offering beginner level advice. Hence…

LeSS as a framework

LeSS is more than a set of principles and experiments. It also provides a framework with rules. The LeSS Rules define what is LeSS (and what isn’t) and they provide a concrete framework for applying LeSS. Within the LeSS Framework, product groups can apply the experiments and discover what works best for them at a certain moment.

This is also the basis of the third LeSS book, simply called Large-Scale Scrum. In this book, LeSS is defined as:

  • LeSS Rules that provide the LeSS framework (and the LeSS Huge framework for larger product groups)
  • Guides for adopting LeSS
  • Experiments from the first two books.

This way ensures that LeSS is simple and stays true to the Scrum nature. Yet, like Scrum, LeSS provides enough concrete practices to start and enough flexibility and power to scale.