Scaling beyond frameworks

Agile on a large scale is too often seen as a choice between two frameworks: SAFe or LeSS. Occasionally, a third (phantom) framework comes along: Spotify.

The decision between LeSS and SAFe is largely a make-or-buy decision, the Spotify framework is simply a misunderstanding.

Let me explain.

Buy = SAFe

The Scaled Agile Framework has as its great strength its Big Picture. Thus, it can suggest that everything is quite simple, you just have to roll out. That’s also its biggest weakness: the Big Picture. It can lead to a trap. It’s tempting for the inexperienced to think they can kick off a great agile transition just because they can interpret the icons.

Make = LeSS

LeSS starts completely different: At the beginning an understanding of interrelationships (systemic thinking) is prescribed, then in principle the Scrum rules are re-explained (“every team needs exactly one PO, but nobody said that a PO can only have one team”). And – the biggest strength: LeSS offers an excellent construction kit of practices. The biggest weakness with LeSS is its claim to absoluteness. It makes the claim that you can (and even must) replace organizational structures with it. This is where I get lost: large organizations need more formal structures, even though I share the assessment that they are very often dysfunctional and need to be profoundly changed.

Unfortunately, beginners are completely overwhelmed with it. (from SAFe, too, by the way – but the reality shock sets in later).

Spotify: a snapshot on Beyond Scrum.

What became known as the Spotify framework is a brilliant account of an intermediate state in Agile implementation at Spotify by Henrik Kniberg. Spotify had started with Scrum and has continued to evolve its practices. At one point they then renamed the roles to avoid conflict with the connotations from the original Scrum.

It was never intended to freeze the model or even use it as a blueprint for other organizations.

Beyond Frameworks

However, Spotify has set a benchmark: how to continuously evolve practices – starting from a framework.

The only thing that can lead to understanding: go deeper. Start with the Needs and Pains of the organization and then put together the principles and practices that will help solve them. I see a few elements that are needed for long term development:

  1. Deepen system understanding and work with a deeper insight into interrelationships.
  2. Collect pains and needs, analyze the situation and distil conditions for success from it
  3. Conduct experiments with known practices and gain experience: what is valuable, what can be ignored, what should be avoided
  4. Leadership: Developing authenticity, role and style
  5. Transformation = Orientation + Transition + Evolution: planning ahead that and how you need to constantly evolve the solution

I’ll be looking at some of these points in more detail in the near future.

On Key

The VSM Quick Guide: the model

The introduction to the series on Jon Walker’s VSM quick guide. It describes the simplified VSM vocabulary as used in the rest of the steps.