Blog

LeSS (less.works) wurde gegen 2014 von Bas Vodde und Craig Larman als eine Antwort auf die immer lauter werdenden Rufe nach der Skalierung agiler Praktiken erschaffen.

LeSS bietet somit einen Ansatz wie man es schaffen kann mit mehr als 11 Personen agil zu arbeiten ohne eine komplett neue Art der Wertschaffung verwenden zu müssen sondern vielmehr Scrum „natürlich“ zu skalieren.

Inhalt:

• LeSS – Framework
• LeSS – Prinzipien
• LeSS – Herleitung

LeSS – Framework

Das LeSS-Framework orientiert sich stark am Scrum Flow und dessen Artefakte, Rollen und Rituale.

Ein Sprint beginnt in LeSS normalerweise in einem gemeinsamen Sprint Planning I. In diesem stellt ein Product Owner ein priorisiertes Product Backlog und dessen Inhalt von oben nach unten vor. Die verschiedenen Teams (im Standard bis zu 8 Teams) ziehen sich diese Product Backlog Items in ihren Sprint. Dabei ist es ratsam, ein breites Wissen zu fördern und keine Spezialisierung in die Teams zu bringen. So kann es mehreren Teams in LeSS gelingen stets das Backlog von oben nach unten abzuarbeiten.
Auf diese Weise bekommt jedes Unterteam mit, welches Team im aktuellen Sprint welche Inhalte hat um auch während des Sprints einen optimalen Austausch zu ermöglichen.

Nach dem gemeinsamen Planning I sammeln sich die Teams dann in den „kleinen“ Teams zum Sprint Planning II. Hier wird scrumüblich das Sprintboard mit den richtigen Tasks befüllt und das Team tauscht sich über die im Sprint zu leistende Arbeit aus.

Danach beginnt eine größtenteils normale Iteration bzw. Sprint mit den aus Scrum bekannten Daily Scrums der jeweiligen Teams.
Während des Sprints organisieren die Teams auch die Arbeit der kommenden Sprints in Form von Refinements im Team oder übergreifend mit anderen Teams.

Am Ende des Sprints folgt dann das Review. Für die Moderation eines Reviews in LeSS gibt es verschiedene Möglichkeiten. Eine gern genutzte Möglichkeit hierbei ist die Veranstaltung als Marktplatz zu organisieren. Die einzelnen Teams steigen hier in einer begrenzten Zeit an ihrem „Marktstand“ die Ergebnisse des Sprints und ermöglichen es anderen Teams und vor allen den Stakeholdern/Kunden die neusten Entwicklungen und das neuste Produktinkrement zu begutachten.

Aus dem Feedback der Kunden und den Erfahrungen der einzelnen Teammitglieder organisiert das Team im Anschluss eine Retrospektive um ihre Effektivität der kommenden Sprints zu verbessern.

Um auch im gesamten LeSS Konstrukt Verbesserungen zu erzielen empfiehlt es sich im Anschluss eine gemeinsame Retrospektive zu veranstalten um übergreifende Verbesserungen angehen zu können.

Auf die Retrospektive folgt danach der nächste Sprint beginnend mit dem Sprint Planning 1.

LeSS – Prinzipien

LeSS besteht natürlich nicht nur aus einem Framework, sondern bringt zu dem einige Experimente, Guides (Best Practices) und Prinzipien mit sich.

Die Prinzipien auf denen LeSS beruht helfen Teams dabei, zu verstehen wie man mit Problemen umgehen muss, für welche LeSS nicht sofort eine Lehrbuchantwort geben kann. Hier einige Beispiele:

• Whole Product Focus – Den Fokus nicht nur auf das eigene aktuelle Themengebiet zu konzentrieren
• Transparency – Um den Kundennutzen optimieren zu können, ist es wichtig offen und ehrlich mit allen Geschehnissen umzugehen um auch hier Verbesserungen durchsetzen zu können
• Continous Improvement Towards Perfection – Auch wenn man den Status der „Perfektion“ nie erreichen wird, sind Teams in LeSS dazu angehalten sich diesen Nordstern als Ziel vorzuhalten und sich Diesem kontinuierlich zu nähern.

Die Experimente bilden eine wichtige Denkweise für agile Teams in LeSS. Hierin geht es nicht nur darum verschiedene Experimente auszuprobieren, sondern auch direkt zu akzeptieren, dass nicht alle Experimente erfolgreich sein werden. Vielmehr geht es darum Fehlschläge zu akzeptieren und diese als Teil der Teamweiterentwicklung anzusehen.
Einige Experimente kann man im Buch „Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum (Agile Software Development Series)“ nachlesen und für eigene Teams anzuwenden.

Die Guides hingegen bilden eine Gruppierung von Experimenten und dem Framework welche für den Start von LeSS empfohlen werden.

LeSS – Herleitung

Für mich gibt es eine schöne Art herzuleiten, wie man LeSS am besten implementiert. Als erstes sollte man sich tatsächlich die Frage stellen: „Can’t you do it with Less“. Also geht es nicht auch mit weniger? Reicht dir ein effektives Team mit 3-9 Produktentwicklern nicht aus um den gewünschten Wert zu schaffen?

Wenn diese Frage tatsächlich mit Nein beantwortet wird und man der Meinung ist eine größere Umsetzungsmannschaft zu benötigen gilt es aus strategischer Sicht die Ziele der Skalierung zu hinterfragen. Skalierung ist nie ein Selbstzweck. Also das Ziel einer Skalierung ist nie mehr Personen im Projekt zu haben sondern meist, dem Kunden mehr Wert in der gleichen Zeit zur Verfügung zu stellen. Man sollte also diesen Punkt und nicht die Skalierung selbst in den Vordergrund rücken.

Hat sich ein Projekt dann einmal dazu entschieden, in Richtung LeSS skalieren zu wollen empfiehlt es sich bereits ein erstes „Mature“ also erfahrenes Team zu haben, welches schon länger in der agilen Welt zu Hause ist und die agilen Werte verinnerlicht hat.

Wenn man in dieses Team fragt: „Was würde passieren“ wenn ihr auf einmal aus 15 oder gar 20 Personen bestehen würdet?“ ergeben sich normalerweise bestimmte Antworten.

• Das Daily würde deutlich länger dauern! => Das Daily hier so teilen, dass nicht jeder alles im Sprint mitbekommen muss. Also 2 Unterteams
• Die Retrospektive wäre zu lang und anstrengend => Die Unterteams machen eine Retro unter sich
• Dennoch müssen wir gemeinsame Probleme abstimmen => Gesamtretrospektive bei Bedarf.
• Wir wollen mitbekommen was das andere Unterteam an Werten schafft! => Gemeinsames Review
• Wir müssen versuchen weiterhin immer am wichtigsten zu arbeiten und uns da auf die richtigen Dinge fokussieren => Gemeinsames Planning 1
• Wir sollten nicht auseinander laufen was die Themen betrifft um weiterhin schlagkräftig zu bleiben => Keine Expertenfokussierung sondern Knowhowsharing zwischen den Teams, gemeinsames Planning 1 und Refinement

Wenn man diese Dinge nach und nach gesund umsetzt, stellt man nach einer Weile fest, dass man sehr nah an LeSS landet. Man könnte also sagen, dass LeSS einen Zielzustand beschreibt, welcher sich an einem gesunden Wachstum von Scrum orientiert.
Der Product Owner hingegen muss nicht skaliert werden. Sogar ganz im Gegenteil, ist es ratsam hier weiterhin eine Person und ein Backlog zu haben, um weiterhin an den wichtigen Dingen zu arbeiten. Dazu aber mehr in einem späteren Blog Artikel.
Direkt als Unternehmen welches noch keine Erfahrung mit Agilität gesammelt hat, in LeSS mit mehreren Teams zu starten ist nicht einfach und nur die wenigsten Unternehmen kommen überhaupt früher oder später in einen LeSS ähnlichen Zustand.

LeSS ist nicht unbedingt die einzig wahre Lösung agil mit mehreren Teams zu arbeiten, aber sicher eine sehr gute Alternative.

Hat dein Unternehmen Herausforderungen mit der agilen Skalierung und fällt es euch schwer hier die richtigen Maßnahmen zu treffen? Gern helfen wir Dir bei den alltäglichen Impediments und entfesseln Kräfte im skalierten Umfeld.