Meine Sicht auf Large-Scale Scrum (LeSS)

Ich kannte das Problem, bevor ich die Antwort kannte

Von 2000 bis 2007 arbeitete ich am Radio Commander, einem Managementsystem für große Mobilfunknetze. Ein international verteiltes System an drei Standorten, über 200 Entwickler. Ich war dort Entwickler, Komponentenverantwortlicher und Teilprojektleiter.

Wir arbeiteten in den Teams bereits iterativ und mit umfangreicher Testautomatisierung. Darüber lag eine Steuerung, die vom Wasserfalldenken geprägt war. Ich habe dort über Jahre erlebt, wie engagierte und fachlich starke Menschen trotzdem Schwierigkeiten hatten, gemeinsam ein stimmiges Gesamtergebnis zu erzeugen.

Zwei Geschichten von vorher

Die Correlation Engine

Ein Kunde beschwerte sich massiv über die Flut an Alarm- und Fehlermeldungen. Bei einem Gewitter meldeten die Systeme hunderte Fehler, die Listen liefen auf den Monitoren voll, und es dauerte lange, die eigentliche Ursache zu finden. Das Gewitter ist nur das anschauliche Beispiel. Allgemein erzeugte der Ausfall einer Netzkomponente viele Folgemeldungen. Welche war die auslösende?

Der Release war verplant. Wir im Fehlermanagement konnten uns trotzdem Kapazität freischaufeln und eine regelbasierte Correlation Engine bauen, die korrelierende und unwichtige Alarme herausfilterte und die Zahl möglicher Ursachen deutlich reduzierte.

Dann begann das eigentliche Problem. Wir waren das Fehlermanagement. Die Oberfläche und der Test lagen an einem anderen Standort. Beide sagten, sie hätten andere Prioritäten und keine Kapazität. Aus ihrer Sicht war das völlig richtig. Niemand verhielt sich falsch.

Der Radio Commander bot die Möglichkeit, Skripte an Managed Objects in ein Kontextmenü zu hängen. Bei Listen wurden sogar die ausgewählten Einträge an das Skript übergeben. Ich schlug vor, damit in PerlTk eine Lösung zu bauen. Daraufhin kamen zwei Bedingungen. Das UI-Team forderte, die Oberfläche müsse exakt aussehen wie die Original-UI. Das Testmanagement forderte, es dürfe nur eine einzige Datei sein, ein einziges Skript. Ich bin bis heute überzeugt, dass diese Bedingungen den Vorschlag zu Fall bringen sollten.

Ich baute einen vollständigen Wizard, mit dem sich sehr unterschiedliche Regeln komfortabel erstellen und ausrollen ließen. Das Skript hatte über 3000 Zeilen.

Der Kunde war sehr zufrieden. Andere ebenfalls. Der Wert kam also an.

Der Weg dorthin hat die Organisation trotzdem teuer zu stehen bekommen. Die Architektur des Systems war gebrochen. Das Design des Skripts war für sich genommen in Ordnung, aber 3000 Zeilen in einer Datei sind kein gutes Design. Nach dem Livegang beschwerte sich das UI-Team, dass Fehlermeldungen zu diesem Wizard bei ihnen aufliefen, und forderte nachträglich, es müsse erkennbar sein, dass es sich um eine andere Oberfläche handelt. Später weigerte es sich, das Skript zu übernehmen. Es ging an ein drittes Team, das mit Oberflächen ursprünglich nichts zu tun hatte. Und im Test musste erheblich mehr geprüft werden als angenommen.

Ein Skript ist eben keine gültige Begrenzung von Aufwand.

Die Häppchen

Unsere Systems Engineers hatten die Aufgabe, fachliche Anforderungen in technische Arbeitspakete für uns zu überführen. Wir bekamen ein Paket, eine kurze Erklärung, und dann ging es los.

Einmal hatten wir die vorgesehene Lösung offenbar nicht ganz verstanden. Wir fanden für die Anforderung einen deutlich einfacheren und besseren Weg. Darauf waren wir stolz. Informiert haben wir niemanden.

Im nächsten Release kam eine kleine Erweiterung. Sie war machbar, aber schon mit etwas Tricksen. Wir haben sie mit einem kleinen Balkon im Code untergebracht. Im Release darauf kam der Knall. Die nun geforderte Änderung war mit vertretbarem Aufwand nicht mehr umsetzbar. Wir mussten eingestehen, dass unsere geniale Lösung von damals inzwischen ein echtes Problem war. Das kostete viel Nacharbeit und verkleinerte die Wertschöpfung dieses Release deutlich.

Wir kannten das Zielbild nicht. Wir bekamen immer nur kleine Häppchen. Und wir haben unser Wissen für uns behalten. Beide Seiten haben genau das getan, was die Struktur von ihnen verlangte.

Warum ich diese Geschichten selten erzählen muss

Ich frage in Trainings und Workshops zuerst nach den Erfahrungen der Teilnehmenden. Zu diesem Thema kommt dann so viel Eigenes, dass ich meine Geschichten meistens gar nicht brauche. Das ist die eigentliche Nachricht: Das sind keine Sonderfälle aus der Telekommunikation der frühen 2000er Jahre. Das sind Muster, die in Komponentenorganisationen zuverlässig entstehen.

Was ich 2007 vorfand

2007 übernahm Nokia die Netzwerksparte von Siemens. Noch vor dem offiziellen Zusammenschluss kam ich in ein neu aufgebautes Team in München. Dort wurde mit Scrum und Large-Scale Scrum gearbeitet. Es war die Organisation, in der Craig Larman und Bas Vodde die Ansätze entwickelten, die später den Namen LeSS bekamen.

Was mich überrascht hat, war fast Punkt für Punkt das, was mir vorher gefehlt hatte:

• Schnelle Feedbackzyklen und eine Build-Pipeline samt automatisierten Tests, die am Kundenwert ausgerichtet waren und nicht an Komponentengrenzen
• Teams, die an allen Themen arbeiten konnten, statt an ihrem Stück
• Internal Open Source. Jeder durfte jeden Code anfassen, ändern und erweitern, ohne dass Chaos entstand
• Echte Zusammenarbeit zwischen den Teams, aber auch mit Anforderern und Management
• Ein hoher Grad an Entscheidungen bei Entwicklern und Teams
• Die Möglichkeit, am Gesamtbild zu arbeiten

Als Entwickler fühlte sich das für mich fast wie der Himmel auf Erden an. Ich habe dort nicht eine Methode kennengelernt, sondern ein anderes Arbeitssystem. Über die folgenden Jahre habe ich es als Entwickler, Domain-Experte, Scrum Master, TDD Coach und interner Agile Coach aus verschiedenen Perspektiven erlebt und mitgestaltet, lange bevor ich es je bei einem Kunden eingeführt habe.

Was aus der Correlation Engine geworden wäre

Der interessanteste Teil dieser Überlegung ist, wie unspektakulär die Antwort ausfällt.

Was LeSS ist

LeSS ist ein systemischer Ansatz für die Produktentwicklung, kein Vorgehensmodell. Es beschreibt weniger, was man tun soll, als vielmehr die Frage, wie eine Organisation gebaut sein muss, damit sie Kundenwert eigenständig, schnell und lernend hervorbringen kann. Die Prinzipien lassen sich darüber hinaus anwenden, auch auf Bereiche, die nichts mit Softwareentwicklung zu tun haben.

Zwei Dinge halte ich für zentral und sehe sie selten verstanden.

LeSS ist kulturbildend. Die häufigen teamübergreifenden Veranstaltungen und die gemeinsame Verantwortung für ein Produkt sind nicht Prozessaufwand, sondern der Mechanismus, über den eine gemeinsame Sicht auf Produkt, Qualität und Zusammenarbeit überhaupt erst entsteht.

Systems Thinking und Systems Modelling sind die Techniken, mit denen der Weg von lokaler Optimierung zur Optimierung des Gesamtsystems gelingt. Ohne sie bleibt jede Struktur eine Behauptung.

Owning statt Renting

Eine der großen Ideen in LeSS ist Owning versus Renting. Menschen sollen sich mit der Veränderung identifizieren können und sie mitgestalten, statt sie zu bekommen.

Ich kenne keinen Ansatz, der die betroffenen Menschen so wertschätzt wie LeSS. Die Betroffenen gestalten ihre Teams selbst, sie entscheiden über ihre Arbeitsweise, und die Organisation wird nicht über ihre Köpfe hinweg entworfen.

Leicht machen wir es uns damit nicht. Owning heißt nicht, dass eine Organisation einfach verkündet, so werde jetzt gearbeitet. Es heißt, dass wir das Warum und das Wozu beantworten. Welches Problem löst diese Veränderung, welchen Zweck verfolgt sie, woran wird Fortschritt erkennbar? Erst wenn diese Fragen beantwortet sind, können Menschen die Veränderung ernsthaft mitgestalten und ihr an den richtigen Stellen auch begründet widersprechen.

Interessanterweise haben die Autoren das nie so benannt. Aber es ist da. Und es steht in bemerkenswertem Kontrast zum Ruf von LeSS, hart und kompromisslos zu sein. Beides stimmt. LeSS ist unerbittlich in der Sache und ungewöhnlich respektvoll gegenüber den Menschen.

Fünf Sätze, die ich immer wieder höre

„LeSS ist auch nur ein Framework wie SAFe.“

LeSS besteht aus wenigen Regeln und sehr vielen Fragen. Es schreibt gerade nicht vor, wie Koordination, Planung und Rollen im Detail auszusehen haben, sondern verlangt, dass die Organisation diese Antworten selbst entwickelt. Wer eine vollständige Prozessbeschreibung sucht, findet in LeSS erstaunlich wenig.

„Viel zu starr, das passt für uns nicht.“

Der Eindruck entsteht, weil LeSS wenige Dinge sehr klar sagt, etwa dass es ein Produkt, ein Product Backlog und einen Product Owner gibt. Alles andere ist offen und muss zum Kontext passen. Starr ist nicht das Framework, starr ist die Konsequenz aus diesen wenigen Festlegungen.

„LeSS funktioniert nur, wenn man die Organisation konsequent umbaut. Das können wir nicht, also kommt es für uns nicht in Frage.“

Der erste Teil stimmt. Die Ausrichtung der Organisation am Kundenwert bringt am meisten, und ohne sie ist es nicht LeSS. Der Schluss stimmt nicht. Genau für diesen Weg gibt es in LeSS die Feature Team Adoption Map. Sie macht sichtbar, wo eine Organisation heute steht, und aus welchen Schritten sie sich in Richtung Feature Teams entwickeln kann. Das Management legt damit die Bedingungen für die notwendigen strukturellen Veränderungen fest, und die Teammitglieder entwickeln selbst die Maßnahmen, mit denen sie dort hineinwachsen. Mehr dazu weiter unten und in meinem Vortrag über die FTAM.

„Crossfunktionale Teams funktionieren nicht, das überfordert den Einzelnen.“

Cross-funktional ist das Team, nicht die einzelne Person. Ein Team verfügt gemeinsam über die Fähigkeiten, die es braucht, um ein Kundenproblem von der Analyse bis zum nutzbaren Ergebnis zu lösen. Niemand muss alles können. Wir ermutigen die Menschen durchaus, mehrere Kompetenzen zu erwerben, Multi-Skill Learning gehört dazu. Ein Zwang ist es nicht.

„Unser Thema ist viel zu komplex, als dass jeder alles kann.“

Das ist derselbe Einwand, und er verdient trotzdem eine eigene Antwort, weil er ernst gemeint ist. Es geht nicht darum, dass alle alles können, sondern darum, dass Wissen nicht auf einzelne Köpfe konzentriert bleibt. Ich mache dafür mit dem Team Knowledge Model sichtbar, welches Wissen vorhanden ist, wo es fehlt und wie es sich gezielt verbreitern lässt. Wissensverteilung wird damit zu einer Aufgabe, die man planen und beobachten kann, statt zu einer Hoffnung.

Und was ein einzelnes Team tatsächlich nicht abdecken kann, deckt eine Area ab, also bis zu acht Teams, die gemeinsam an einem Bereich des Produkts arbeiten. Dass acht Teams zusammen keinen Ende-zu-Ende-Wert liefern können, habe ich noch nicht erlebt.

Wo ich anders denke als die reine Lehre

Kontinuierliche Integration steht für mich über technischer Exzellenz

LeSS hebt technische Exzellenz sehr hoch, und das ist richtig und wichtig. Ich halte die kontinuierliche Integration der eigenen Arbeitsergebnisse trotzdem für wichtiger.

Das erste Argument ist logisch. Man kann technisch exzellent auf isolierten Branches arbeiten und dennoch die kontinuierliche Integration des Produkts verhindern. Umgekehrt geht es nicht. Wer konsequent kontinuierlich integriert, muss Qualität, Testbarkeit, Zusammenarbeit und technische Exzellenz entwickeln.

Das zweite Argument ist praktischer Natur. Auch nicht technische Kolleginnen und Kollegen müssen ihre Arbeitsergebnisse so schnell wie möglich in das Gesamtsystem integrieren. Von technischer Exzellenz fühlen sie sich oft nicht angesprochen.

Manchmal ist der Zwischenschritt der bessere erste Schritt

Der Königsweg bleibt der organisatorische Umbau zur Ausrichtung am Kundenwert. Er bringt am meisten. Wenn eine Organisation das nicht tut, sagt LeSS klar, dass das dann nicht LeSS ist. Ich halte das für richtig, und ich verwässere es nicht.

Und trotzdem: Organisationen können von einem Zwischenschritt profitieren, bei dem die relevanten Komponententeams in LeSS zusammengebracht werden und die Ende-zu-Ende-Perspektive gemeinsam in Refinements und Design Sessions hergestellt wird.

Ich habe erlebt, dass Mitarbeitende rebelliert haben, weil sie nun mit den Idioten aus den anderen Komponenten in einem Team sitzen sollten. Die Vorgeschichte war ein jahrelanges Blame Game, in dem alle damit beschäftigt waren, nicht selbst schuld zu sein.

In einer solchen Lage sind echte Feature Teams sofort nicht der mutige Schritt, sondern der, der scheitert. Dann ist es besser, die Teamstrukturen zunächst zu erhalten. Ein sicherer Teamplatz, von dem aus man die anderen kennenlernt und über die Zeit feststellt, dass die gar nicht so verkehrt sind. Der Schritt zu echten Feature Teams kommt danach, und er kommt dann leichter.

Was auch nach Jahren schwierig bleibt

Die Feature Team Adoption Map ist nicht leicht zu verstehen und noch schwerer richtig einzusetzen. Sie wird oft missverstanden, und deshalb schrecken viele davor zurück. Damit bleibt genau das Potenzial ungenutzt, das LeSS für eine schrittweise und gesunde Organisationsentwicklung bietet. Ich habe darüber im September 2024 auf der Global LeSS Conference in Madrid gesprochen, weil ich selbst lange gebraucht habe, sie richtig einzusetzen. Der Vortrag samt Folien ist öffentlich zugänglich.

Systems Modelling ist ähnlich. Die Technik ist einfach und ausgesprochen praktikabel. Die richtigen Variablen zu finden, braucht Übung.

Wann ich von einer LeSS Einführung abrate

Dass ich von LeSS abrate, kommt selten vor. Das liegt vor allem daran, dass ich LeSS bei Kunden meistens gar nicht benenne und nicht anbiete. Ich arbeite an Einsicht, an gemeinsamem Verständnis der tatsächlichen Herausforderung und an tragfähigen nächsten Schritten. Das kann lange dauern und gelingt in der Regel. Wer nach dem Namen fragt, bekommt ihn.

Abraten würde ich in drei Fällen:

• Wenn Executives einen vollständigen Transformationsplan im Voraus verlangen. Wer die Antworten bereits kennt, braucht keinen empirischen Ansatz
• Wenn es mehr darum geht, Checklisten abzuhaken, als tatsächlich etwas zu verändern
• Wenn es in der Organisation gar nicht um Produkt- oder Serviceentwicklung im Sinne von Scrum und Large-Scale Scrum geht

Belege und Gespräch

Zwei meiner Arbeiten sind als Fallstudien öffentlich dokumentiert. Die Unified Sales Platform bei BMW i, deren Fallstudie ich verantworte, und die großskalierte Veränderung im Bereich autonomes Fahren, bei der ich Initial Lead Coach war.

Wenn Sie beim Lesen an Ihre eigene Organisation gedacht haben, ist das der bessere Anlass für ein Gespräch als jede Leistungsbeschreibung. Ich bin seit 2015 Certified LeSS Trainer, der erste im deutschsprachigen Raum, und mein Mentor auf diesem Weg war Craig Larman. Wichtiger ist mir, dass ich die Probleme kenne, um die es geht, weil ich sie selbst hatte.

Wer lieber mit einem Training beginnt: die Trainings und Workshops stehen mit allen Formaten und Eckdaten hier. Weitere Artikel und Vorträge finden Sie in den Publikationen.