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 is added: Spotify.

The decision between LeSS and SAFe is in large part 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 need to roll out. That’s also its biggest weakness: the big picture. It can lead to a trap. It tempts the inexperienced to think they can kick off a major agile transition just because they can interpret the icons.

Make = LeSS

LeSS starts quite differently: 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 greatest weakness in 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 by this. (from SAFe, too, by the way – but the reality shock sets in later).

Spotify: a snapshot on Beyond Scrum

What has become 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 continuously developed 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 deeper insight into interrelationships.
2. Collect pains and needs, analyze the situation and distill conditions for success from them
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: plan ahead that and how you need to constantly evolve the solution.

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