My view on Large-Scale Scrum (LeSS)

I knew the problem before I knew the answer

From 2000 to 2007 I worked on the Radio Commander, a management system for large mobile networks. An internationally distributed system across three sites with more than 200 developers. I was a developer there, then a component owner, then a sub-project lead.

Inside the teams we already worked iteratively and with extensive test automation. Above that sat a way of steering the organization shaped by waterfall thinking. Over those years I watched committed and highly capable people struggle to produce a coherent overall result together.

Two stories from before

The correlation engine

A customer complained bitterly about the flood of alarms and error messages. During a thunderstorm the systems reported hundreds of faults, the lists filled the monitors, and finding the actual cause took a long time. The thunderstorm is just the vivid example. More generally, the failure of one network component produced many follow-up messages. Which one was the trigger?

The release was already planned. In fault management we still managed to free up capacity and build a rule-based correlation engine that filtered out correlating and unimportant alarms and cut the number of possible causes considerably.

Then the real problem started. We were fault management. The user interface and the test group were at another site. Both said they had other priorities and no capacity. From their point of view that was entirely correct. Nobody behaved badly.

The Radio Commander offered a way to attach scripts to managed objects in a context menu. For lists it even passed the selected entries to the script. I proposed building a solution that way, in PerlTk. Two conditions came back. The UI team required that the interface look exactly like the original UI. Test management required that it be a single file, a single script. To this day I am convinced those conditions were meant to kill the proposal.

I built a complete wizard that made it convenient to create and deploy a wide range of rules. The script ran to more than 3000 lines.

The customer was very happy. Others were too. The value did arrive.

The route there still cost the organization dearly. The architecture of the system was broken. The design of the script was reasonable in itself, but 3000 lines in one file is not good design. After go-live the UI team complained that error reports about this wizard were landing with them, and demanded after the fact that it be made visible that this was a different interface. Later they refused to take the script over. It went to a third team that had never worked on user interfaces. And testing turned out to require far more effort than assumed.

A script, it turns out, is not a valid way to cap effort.

The small bites

Our systems engineers were responsible for turning business requirements into technical work packages for us. We received a package, a short explanation, and then we got started.

On one occasion we clearly had not fully understood the intended solution. We found a much simpler and better way to meet the requirement. We were proud of it. We told nobody.

In the next release a small extension came along. It was feasible, but it needed a bit of trickery. We accommodated it with a small balcony in the code. In the release after that, everything caught up with us. The change now required could no longer be built at reasonable cost. We had to admit that our brilliant solution had become a real problem. It cost a great deal of rework and noticeably reduced the value we delivered in that release.

We did not know the target picture. We only ever received small bites. And we kept our knowledge to ourselves. Both sides did exactly what the structure asked of them.

Why I rarely need to tell these stories

In trainings and workshops I ask about the participants’ own experience first. On this topic so much of their own comes back that I usually never get to mine. That is the actual point. These are not special cases from telecommunications in the early 2000s. These are patterns that component-based organizations produce reliably.

What I found in 2007

In 2007 Nokia took over the Siemens network division. Before the merger was formally complete I joined a newly formed team in Munich. It worked with Scrum and Large-Scale Scrum. It was the organization in which Craig Larman and Bas Vodde were developing the ideas that later took the name LeSS.

What surprised me was, almost point for point, what had been missing before:

• Fast feedback cycles, and a build pipeline and automated tests aligned to customer value rather than to component boundaries
• Teams able to work on any topic instead of on their own slice
• Internal open source. Anyone could touch, change and extend any code, and no chaos followed
• Real collaboration between teams, and with requesters and management as well
• A high degree of decision-making with developers and teams
• The chance to work on the whole picture

As a developer it felt close to heaven. What I encountered there was not a method but a different work system. Over the following years I experienced and helped shape it as a developer, domain expert, Scrum Master, TDD coach and internal agile coach, long before I ever introduced it anywhere as a consultant.

What would have become of the correlation engine

The most interesting thing about this thought experiment is how unspectacular the answer is.

What LeSS is

LeSS is a systemic approach to product development, not a process model. It says less about what to do than about how an organization must be built so that it can produce customer value independently, quickly and with learning. The principles reach further than that and apply well beyond software development.

Two things I consider central, and I rarely see them understood.

LeSS shapes culture. The frequent cross-team events and the shared responsibility for one product are not process overhead. They are the mechanism through which a shared view of product, quality and collaboration comes into being at all.

Systems thinking and systems modeling are the techniques that carry an organization from local optimization to optimizing the whole. Without them any structure remains an assertion.

Owning rather than renting

One of the great ideas in LeSS is owning versus renting. People should be able to identify with the change and shape it themselves, rather than receive it.

I know of no approach that values the people affected as much as LeSS does. They design their own teams, they decide how they work, and the organization is not drawn up over their heads.

None of this makes it easy on us. Owning does not mean an organization announces that this is how we work now. It means we answer the why and the what for. Which problem does this change solve, what purpose does it serve, how will progress become visible? Only once those questions are answered can people genuinely shape the change, and disagree with it on good grounds where that is warranted.

Interestingly, the authors never named it that way. But it is there. And it stands in remarkable contrast to the reputation LeSS has for being hard and uncompromising. Both are true. LeSS is relentless about the subject matter and unusually respectful towards the people.

Five sentences I hear again and again

“LeSS is just another framework, like SAFe.”

LeSS consists of few rules and a great many questions. It specifically does not prescribe what coordination, planning and roles should look like in detail. It requires the organization to develop those answers itself. Anyone looking for a complete process description will find surprisingly little in LeSS.

“Far too rigid, it does not fit us.”

That impression comes from the few things LeSS states very clearly, such as one product, one product backlog, one product owner. Everything else is open and has to fit the context. What is rigid is not the framework, it is the consequences of those few commitments.

“LeSS only works if you rebuild the organization completely. We cannot do that, so it is not an option for us.”

The first part is true. Aligning the organization to customer value delivers the most, and without it this is not LeSS. The conclusion is not true. This is exactly what the Feature Team Adoption Map in LeSS is for. It makes visible where an organization stands today and which steps can take it towards feature teams. Management uses it to define the conditions for the necessary structural changes, while team members develop the measures by which they grow into them. More on this below and in my talk on the FTAM.

“Cross-functional teams do not work, they overwhelm the individual.”

It is the team that is cross-functional, not the person. A team collectively holds the capabilities needed to take a customer problem from analysis to a usable result. Nobody has to be able to do everything. We do encourage people to acquire more than one skill, and multi-skill learning is part of the approach. It is never a requirement.

“Our domain is far too complex for everyone to do everything.”

This is the same objection, and it still deserves its own answer, because it is meant seriously. The point is not that everyone can do everything. The point is that knowledge must not stay concentrated in a few heads. I use the Team Knowledge Model to make visible what knowledge exists, where it is missing and how it can be broadened deliberately. Knowledge distribution becomes something you can plan and observe instead of something you hope for.

And whatever a single team genuinely cannot cover is covered by an area, meaning up to eight teams working together on one part of the product. I have yet to see eight teams unable to deliver end-to-end value together.

Where I differ from the pure doctrine

Continuous integration matters more to me than technical excellence

LeSS holds technical excellence in very high regard, and rightly so. I still consider continuous integration of your own work results more important.

The first argument is logical. You can work with technical excellence on isolated branches and still prevent the continuous integration of the product. The reverse does not hold. Anyone who integrates continuously is forced to develop quality, testability, collaboration and technical excellence.

The second argument is practical. Non-technical colleagues also need to integrate their work into the whole as quickly as possible, and they often do not feel addressed by the phrase technical excellence.

Sometimes the intermediate step is the better first step

The royal road remains the structural change that aligns the organization to customer value. It delivers the most. If an organization does not do it, LeSS says plainly that this is then not LeSS. I think that is right, and I do not water it down.

And yet. Organizations can benefit from an intermediate step in which the relevant component teams are brought together in LeSS and the end-to-end perspective is created jointly in refinements and design sessions.

I have seen people rebel because they were now supposed to sit in a team with the idiots from the other components. The back story was years of a blame game in which everyone was busy making sure they were not the one at fault.

In a situation like that, real feature teams straight away are not the courageous step. They are the step that fails. It is better to keep the team structures at first. A safe home base from which you get to know the others and over time discover that they are not so bad after all. The move to real feature teams comes after that, and it comes more easily.

What stays difficult, even after years

The Feature Team Adoption Map is not easy to understand and harder still to use well. It is often misunderstood, and so many people avoid it. That means the potential LeSS offers for gradual and healthy organizational development goes unused. I spoke about it at the Global LeSS Conference in Madrid in September 2024, because it took me a long time to use it properly myself. The session and slides are publicly available.

Systems modeling is similar. The technique is simple and remarkably practical. Finding the right variables takes practice.

When I advise against adopting LeSS

It rarely happens that I advise against LeSS. That is mainly because I usually do not name LeSS with clients and do not offer it as such. I work on insight, on a shared understanding of the actual challenge, and on next steps the organization can carry. That can take a long time, and it usually works. Anyone who asks for the name gets it.

I would advise against it in three cases:

• When executives require a complete transformation plan up front. If you already know the answers, you do not need an empirical approach
• When the point is ticking off checklists rather than achieving real change
• When the organization is not doing product or service development in the sense of Scrum and Large-Scale Scrum

Evidence, and a conversation

Two pieces of my work are documented publicly as case studies. The Unified Sales Platform at BMW i, whose case study I own, and the large-scale change in autonomous driving, where I was initial lead coach.

If you were thinking about your own organization while reading this, that is a better reason for a conversation than any list of services. I have been a Certified LeSS Trainer since 2015, the first in the German-speaking world, and Craig Larman was my mentor on that path. What matters more to me is that I know the problems in question, because I had them myself.

If you would rather start with a course: the training and workshops are listed here with formats and details. Further articles and talks are listed under publications.