Was ist LeSS? – Einführung in das LeSS Framework

LeSS ist ein Vorgehensmodell zur Skalierung von Scrum. Oder um es mit einem der zentralen Prinzipien von LeSS zu formulieren: “LeSS ist Scrum”. Dieses Eingeständnis ist für das Verständnis des LeSS Frameworks elementar. Denn damit bleiben zentrale Punkte aus dem Scrum Framework trotz oder gerade wegen der Skalierung erhalten:

• Es gibt nur einen Product Owner und einen Product Backlog
• Es gibt eine, für alle Teams gültige, Definition of Done
• Teams sind crossfunktional besetzt und arbeiten “self managed”
• Alle Teams arbeiten synchron im gleichen Sprint-Rhythmus
• Teams arbeiten an einem gemeinsamen Inkrement

Basierend auf diesen aus Scrum übernommenen Ansätzen definiert LeSS zusätzliche Events und erweitert den Kompetenzbereich existierender Scrum-Rollen. Das heißt, LeSS ist eine Erweiterung der Rollen, Meetings und Artefakte des Scrum Frameworks. 

Das LeSS Framework wurde von Craig Larman und Bas Vodde entwickelt. Anlass für die Entwicklung des LeSS Frameworks waren Probleme bei der Anwendung von Scrum bei größeren Vorhaben. Davon ausgehend experimentierten die beiden Gründerväter seit 2005 mit neuen Vorgehensweisen und ergänzenden Regeln. So entstand schrittweise das heutige LeSS Framework. Seit 2014 wird LeSS durch less.works betreut und weiterentwickelt. 

Das LeSS Framework definiert, basierend auf Scrum, konkrete Regeln und Vorgehensweisen. Ergänzt werden diese LeSS Regeln durch Prinzipien, Guides und Experimente. 

• Die LeSS Prinzipien beschreiben grundlegende Konzepte und eine mit LeSS einhergehende Haltung. 
• Das Framework beschreibt konkrete Regeln in den Bereichen Struktur, Produkt und Sprint.
• Guides sind optionale Empfehlungen für die Implementierung von LeSS und helfen bei der effektiven LeSS Implementierung. 
• Experimente sind Erfahrungswissen aus vielen LeSS Implementierungen. Anders als Guides sind Experimente nicht in jeder LeSS Implementierung sinnvoll. Sie sind gleichzeitig eine Einladung und Erinnerung an LeSS Organisationen durch eigene Experimente den Weg zur organisatorischen Perfektion zu beschreiten.

Die LeSS Prinzipien sind das Fundament für die Anwendung des LeSS Frameworks. Das Verständnis der LeSS Prinzipien ist ein wichtiger Kontext, um die ein oder anderen LeSS Regeln und seine Bedeutung nachvollziehen zu können. Über diese LeSS Prinzipien hinaus sind natürlich auch agile Werte, agile Prinzipien und das agile Manifest wichtige Rahmenbedingungen für eine erfolgreiche LeSS Adaptierung. 

Large-Scale Scrum ist Scrum. Das heißt, um LeSS zu verstehen und erfolgreich anzuwenden, musst Du Scrum verstehen. LeSS setzt auf Scrum Konzepte auf und erweitert diese, um Scrum erfolgreich skalieren zu können.

Das zweite wichtige LeSS Prinzip ist Transparenz, die sich in konkreten Inkrementen, kurzen Feedback-Zyklen, Zusammenarbeit auf Augenhöhe und Offenheit aller Beteiligten zeigt.

Ein schönes Wortspiel, das es aber in sich hat. Denn statt mehr Rollen, mehr Meetings, mehr Artefakte, stärkt LeSS die Verantwortung der umsetzenden Teams, um mehr mit weniger zu erreichen.

Das vierte LeSS Prinzip fordert die strikte Fokussierung auf das ganzheitliche Produkt, statt technischer Komponenten. Das hat weitreichende Auswirkungen und manifestiert sich in einem Backlog, einem Product Owner und einem Sprint für alle Teams.

Das fünfte LeSS Prinzip stellt den Kunden ins Zentrum des Handelns. Teams und alle handelnden Personen sind aufgefordert den tatsächlichen Wert für den Kunden stets im Auge zu behalten.

LeSS setzt auf einen permanenten Lernprozess und das Streben nach Perfektion. Sowohl Lernen als auch die kontinuierliche Verbesserung jedes Einzelnen, der Teams, sowie der gesamten Organisation ist ein zentrales Konzept von LeSS.

Das sechste LeSS Prinzip hebt das Lean Thinking hervor. Dabei betont LeSS vor allem den Ort des Geschehens selbst zu sehen (Gemba), das dreistufige Lernkonzept ShuHaRi (Shu = nachahmen, Ha = variieren, Ri = eigene Regeln definieren) und den Respekt gegenüber Menschen.

Das nächste LeSS Prinzip fordert dich auf, das ganze System und nicht einzelne Teile davon zu betrachten. Das heißt, vermeide lokale Optimierungen, sondern konzentriere dich auf das große Ganze und globale Optimierungen. 

Natürlich ist auch die Forderung nach empirischer Prozesskontrolle ein zentrales LeSS Prinzip. Das heißt, Du inspizierst und adaptierst kontinuierlich das Produkt und deinen Arbeitsprozess. Und auf Basis echter empirischer Erfahrung passt Du dein Vorgehen immer wieder an. 

Das letzte LeSS Prinzip ist die Warteschlangentheorie. Das heißt, Du darfst verstehen, wie Warteschlangen oder Queues Systeme beeinflussen und lahmlegen. Definiere also WIP-Limits (Work-in-Progress), vermeide Multitasking und große Arbeitspakete.

Basierend auf Scrum und den zehn Prinzipien definiert das LeSS Framework Regeln in drei Bereichen.

• LeSS Strukturen beschreiben Leitlinien für den strukturellen Aufbau der LeSS Organisation. 
• LeSS Produkt betracht die Organisation aus Sicht des Produktes bzw. Vorgehensweisen, wie das LeSS Prinzip “whole product focus” operationalisiert wird.
• LeSS Sprint sind Regeln für die Durchführung eines Sprints und definiert zusätzliche Meetings.

Bei mehr als acht Teams werden diese Regeln in LeSS Huge variiert und ergänzt. 

Der erste Baustein des Frameworks bezieht sich auf die strukturellen Elemente der LeSS Organisation. 

Teams sind der zentrale Baustein der Organisation, sie und nicht Manager bilden das Herz der Organisation. Dabei sind Teams self-managed, crossfunktional besetzt, co-located und langlebig. Das heißt, Teams sitzen räumlich nah beieinander und werden nicht temporär, sondern für eine dauerhafte Zusammenarbeit zusammengestellt. Mindestens 50% der Teams sind in LeSS sogenannte Feature-Teams. Ein Feature-Team ist dadurch gekennzeichnet, dass sie eine Kundenanforderung autonom gegen die Definition of Done umsetzen können. Dagegen sind Komponenten-Teams auf eine technische Komponente spezialisiert (z.B. Datenbank, Backend). LeSS bevorzugt Feature-Teams, Komponenten-Teams sollten im LeSS Verständnis vermieden werden.

Das zweite strukturelle Element im LeSS Framework widmet sich dem Scrum Master. Scrum Master sind Servant Leader für eine funktionierende LeSS Umsetzung. Jeder Scrum Master arbeitet direkt mit 1-3 Teams. Dabei ist ein Scrum Master in LeSS niemals nur auf die Arbeit mit dem Team fokussiert, sondern immer auf die stete Verbesserung der gesamten Organisation. Um dieser verantwortungsvollen Aufgabe nachzukommen ist der Scrum Master in LeSS immer eine Vollzeitstelle. Das heißt, der Scrum Master übernimmt keine anderen Aufgaben, sondern steht voll im Dienst der Organisation und einer erfolgreichen LeSS Implementierung.

In LeSS sind Manager und Management optional. Dabei geht LeSS davon aus, dass echte Wertschöpfung durch selbstorganisierte Team stattfindet. Damit wandelt sich die Rolle des Managements weg von der Steuerung des operativen Tagesgeschäftes, hin zu einem Befähiger der Organisation. Das heißt, Manager sind überflüssig für die Erbringung der Arbeit, können jedoch ein wichtiger Taktgeber für die dauerhafte Optimierung des gesamten Systems sein. 

Die letzte strukturelle LeSS Regel sieht vor, dass Du LeSS unter allen Umständen auf die gesamte Produktentwicklung anwendest, statt LeSS nur bei einzelnen Teams einzuführen. Also direkt ins kalte Wasser springen, statt nur die Zehen rein zu stecken. Andere ergänzende Funktionen und Bereiche deines Unternehmens über die Produktentwicklung hinaus, wie z.B. Support, kannst Du auch im zweiten Schritt in die LeSS Organisation integrieren. Jedoch ist es unbedingt erforderlich, dass bereits im ersten Schritt deine gesamte Produktentwicklung in einer LeSS Organisation zusammenarbeitet.

Der zweite Baustein des LeSS Frameworks widmet sich deinem Produkt und den organisatorischen Konsequenzen, die aus der Beantwortung der Frage und dem Prinzip “whole product focus” resultieren. 

Mit dem zentralen LeSS Prinzip “whole product focus” geht ein hoher Abstraktionsgrad für die Definition deines Produktes einher. Dabei soll die Produktdefinition so breit und kundenorientiert wie möglich gefasst werden. Das heißt, weg von technischen Komponenten hin zu einer kunden- und wertorientierten Sichtweise. Damit bewegst Du dich bei der Definition deines Produktes auf Ebene einer Value Proposition, statt auf auf technischen Bestandteilen und Leistungsmerkmalen. Diese ganzheitliche Sichtweise ist ein zentraler Eckpfeiler des LeSS Frameworks. Eine gemeinsame Sichtweise auf das Produkt ist eine der wichtigsten Voraussetzungen für eine LeSS Adaptierung. 

Für dieses Produkt gibt es nur einen Product Owner. An dieser wichtigen Stelle emanzipiert sich LeSS von Scrum, wo jedes Team einen eigenen PO hat. Allerdings führen mehr POs zu mehr Abstimmungsaufwand und einer oft sehr technischen Aufteilung des Produktes. Diese Nachteile umgeht LeSS mit der Etablierung eines einzelnen POs. Das heißt aber auch, dass der PO nicht mehr jede User Story vorgeben kann. Umso wichtiger ist es, dass der PO und die Teams gemeinsam anstehende Aufgaben diskutieren und gemeinsam klären. Deswegen setzt LeSS verstärkt auf Product Backlog Refinements (PBR). Darüber hinaus delegiert der PO die Klärung auftretender Rückfragen direkt in die Teams, die im Rahmen der Umsetzung den direkten Kontakt mit dem Anwender suchen, statt über den PO zu gehen. Die strukturierte Durchführung der Refinements und die Klärung von Rückfragen durch umsetzende Teams sind Voraussetzungen dafür, dass die strukturelle Forderung nach einem PO auch wirklich praktikabel ist.

Ein Produkt, ein Product Owner, deswegen auch nur ein Backlog. In diesem einen Backlog werden alle Priorisierungen, wie auch in Scrum direkt, vom Product Owner verantwortet. Allerdings kann sich der PO mit Zunahme des Verantwortungsbereichs und der Teams nicht mehr um jedes Detail kümmern. Das heißt, der PO priorisiert und definiert nicht mehr einzelne Stories, sondern möglicherweise ganze Epics. Die Ausarbeitung der einzelnen Stories ist dann wiederum Aufgabe der Teams. Der Ort dafür sind die Refinement Meetings. Hier wird dann auf Basis der Priorisierungen des POs das Backlog mit konkret umsetzbaren Aufgaben befüllt, auf die sich die Teams dann im Sprint Planning committen können. 

Für alle Teams gilt die gleiche Definition of Done. Im LeSS Verständnis ist die Fähigkeit eines Teams die DoD zu erfüllen ein wesentliches Merkmal für die Agilität deiner Organisation. Auch wenn einzelne Teams eine fortgeschrittenere DoD haben können, ist eine allgemein gültige DoD die Voraussetzung, um im Sprint ein potentiell lieferbares und vor allem gemeinsames Inkrement zu erzeugen. Dabei verfolgt LeSS das Ziel, die DoD über alle Teams hinweg permanent auszuweiten auf dem Weg zu organisatorischer Exzellenz. 

Der dritte Baustein des LeSS Framework bezieht sich auf die Durchführung eines Sprints und damit verbundene Aktivitäten.

Es gibt nur einen Sprint Rhythmus. Das heißt, alle Team starten und beenden den jeweiligen Sprint zur gleichen Zeit. Dabei endet jeder Sprint mit einem gemeinsamen Inkrement, an deren Fertigstellung die Teams gemeinsam gearbeitet haben. Das heißt, dass die Arbeitsergebnisse der einzelnen Teams integriert sind und es nur ein Inkrement gibt, das die Definition of Done erfüllt. Das erfordert natürlich eine hohe technische Exzellenz im DevOps und eine gute Synchronisation der Teams.

Das Product Backlog Refinement ist anders als in Scrum ein klar definiertes Meeting auf zwei Ebenen.

• Im Overall Product Backlog Refinement (#1) nehmen der PO und alle Teams bzw. deren Repräsentanten teil. Das Meeting ist kurz und prägnant (1 Stunde in einem 2 Wochen Sprint). Das Ziel ist relevante Product Backlog Items (PBI) für das weitere Refinement auszuwählen. 
• Im Product Backlog Refinement (#2) werden die priorisierten PBI dann von den Teams gemeinsam mit Usern und Stakeholdern geschärft. Das Ziel des zweiten Meetings ist es, die PBI für das Product Backlog auszuformulieren. 

Refinement Meetings sind im LeSS Verständnis ein wichtiger Lernort. Denn hier erfahren Teams mehr über bisher unbekannte Produktbereiche. Damit sind Refinement Meetings ein Eckpfeiler, um effektiv mit nur einem PO zu arbeiten und vor allem um die Agilität der LeSS Organisation zu fördern. 

Das Sprint Planning besteht in LeSS aus zwei Teilen. Das erste Sprint Planning findet teamübergreifend, das zweite teamintern statt. 

Am Planning #1 nehmen der Product Owner, die Teams oder mindestens ein Team-Repräsentant teil. Dabei werden die anstehenden Aufgaben diskutiert, auf die sich die Teams jeweils verpflichten. 

Im Anschluss findet das Planning #2 auf Ebene der Teams statt, damit das Team die übernommenen Aufgaben besprechen und ihr jeweiliges Sprint Backlog befüllen können. Sofern zwei Teams sich überlappende Aufgaben bearbeiten, können sie auch ein gemeinsames zweites Sprint Planning (Multi-Team Sprint Planning) durchführen. 

Im Sprint hat jedes Team sein eigenes Daily Scrum. Das heißt, es findet kein generelles Daily Scrum mit allen Teams statt. Sofern es Klärungs- und Abstimmungsbedarf mit anderen Teams gibt, erfolgt die Koordination zwischen den Teams eigenverantwortlich auf direktem Weg. Damit wird einmal mehr der Anspruch “more with less” konsequent umgesetzt. Denn statt hier eine koordinierende Rolle oder ein Regelwerk zu bestimmen, wird die Verantwortung dafür komplett in die Hände der Teams gelegt. Um die teamübergreifende Kommunikation zu fördern, gibt es mehrere LeSS Guides wie Communities, team-übergreifende Meetings, Komponenten Mentoren, Travelers, Scouts und Open Spaces.

Zum Abschluss des Sprints präsentieren Teams ihre Arbeitsergebnisse in einer gemeinsamen Sprint Review. Aufgrund der Vielzahl der Beteiligten kann die Durchführung der Review eine echte organisatorische Herausforderung sein. Je nach Anzahl der Teams empfiehlt LeSS in seinen Guides die Durchführung eines Review Bazars. Dabei präsentieren Teams an kleinen Ständen ihr Arbeitsergebnis. Die Teilnehmer können die Arbeitsergebnisse in einem Gallery Walk begutachten. Unabhängig von der Art der Durchführung ist ein zentrales Merkmal, dass die Ergebnisse einzelner Teams integriert sind. Denn sonst würde das wichtige LeSS Prinzip der Transparenz verletzt und ein effektiver Inspektions- und Anpassungsprozess verhindert.

Wie auch im Scrum Prozess schließen Teams ihren Sprint mit einer Retrospektive. Und auch hier setzt LeSS konsequent auf zwei Ebenen. In der ersten Retrospektive geht es, wie im Scrum, um die Verbesserung der teaminternen Zusammenarbeit. Darüber hinaus gibt es im LeSS Framework eine “Overall Retrospective”, also eine teamübergreifende Retrospektive. Dabei geht es vor allem um systemweite Hindernisse und die Verbesserung der Organisation. An der Overall Retrospective nehmen der Product Owner, die Scrum Master, Teams oder ihre Repräsentanten teil. Zeitlich findet die Overall Retrospektive in der ersten Woche des nachfolgenden Sprints statt, um Terminkonflikte zu vermeiden.

Die LeSS Guides sind optionale Empfehlungen für die Implementierung von LeSS. Dabei sind Guides das Ergebnis von erfolgreichen Experimenten und bieten dir eine praktische Hilfestellung für die Umsetzung des LeSS Frameworks. Die Guides beinhalten Empfehlungen, Praktiken und Vorgehensweisen aus den folgenden Bereichen. 

• Wie Du deine Organisation nach Kundenwert organisierst und die Forderung nach “whole product focus” konsequent umsetzt.
• Praktische Empfehlungen für die Organisation des Product Backlogs, die Formulierung deiner Definition of Done (DoD) und die Durchführung von Product Backlog Refinements .
• Empfehlungen im Umgang mit verschiedenen Rollen (Management, Scrum Masters, Product Owner).
• Wie Du Kommunikation und Erfahrungsaustausch effektiv gestaltest, z.B. über Communities, Komponenten Mentoren, Travelers, Scouts, Open Spaces etc..
• Empfehlungen für die LeSS Adoption.

Eine vollständige Liste der LeSS Guides mit detaillierten Ausführungen findest Du im dritten LeSS Buch.

There are no best practices — only adequate practices in context.

LeSS #2

LeSS Experimente sind eine sehr umfangreiche Sammlung von dokumentieren Feldversuchen und bieten damit einen reichhaltigen Fundus an Erfahrungswerten. Anders als Guides sind Experimente nicht in jeder LeSS Implementierung sinnvoll. Dabei warnen die Autoren vor dem Miss(t)verständnis die Experimente mit “best practices” zu verwechseln. Denn während manche Vorgehensweisen nur zeitlich begrenzt sinnvoll sind, können andere nur nur in einem speziellen Kontext nützlich sein. Deswegen gilt der plakative LeSS Leitsatz “There are no best practices—only adequate practices in context.” 

Insgesamt findest Du im zweiten LeSS Buch mehr als 500 Experimente. Gleichzeitig sind die LeSS Experimente eine Ermutigung und Erinnerung daran eigene Experimente in deiner Organisation durchzuführen.

Less Huge ist die Erweiterung des LeSS Frameworks für mehr als acht Teams. Dabei geht LeSS Huge davon aus, dass ein Product Owner ab einer bestimmten Anzahl von Teams seine Rolle nicht mehr effektiv ausfüllen kann. Um die Überlastung eines einzelnen PO zu vermeiden, werden, aufbauend auf LeSS, folgende Konzepte in LeSS Huge ergänzt.

Es werden Requirement Areas definiert, die Domänen und Teilbereiche deines Produktes in Bezug auf den Kunden und die Customer Journey beschreiben. Jedes Team spezialisiert sich auf eine Requirement Area. Dabei wird jede Requirement Area von vier bis acht Teams bespielt.

LeSS Huge führt im Vergleich zu LeSS mit dem Area Product Owner eine neue Rolle ein. Ein Area Product Owner (Area PO) betreut jeweils eine Requirement Area, in dieser Rolle ist der Area PO Ansprechpartner für die Teams in der Requirement Area bei auftretenden Rückfragen. Dabei bilden der Product Owner und die jeweiligen Area Product Owner auf Ebene der gesamten LeSS Organisation gemeinsam das Product Owner Team. Dieses PO Team entscheidet über die produktweite Priorisierung der PBIs und die Priorisierung für die jeweiligen Requirement Areas. Allerdings liegt die letzte Entscheidung für die Priorisierung und einen Release immer beim Product Owner. Die Requirement Area PO sind trotz allem wichtige “Wingmans” und eine tragende Säule, um die Überlastung des PO zu vermeiden.

Das Product Backlog ist zusätzlich nach Requirement Areas untergliedert. Diese “Area Product Backlogs”  kannst Du dir jedoch eher als ein Flagging einzelner PBI vorstellen, bzw. eine Filterung des Backlogs nach einer Requirement Area. Denn vom Konzept “des einen Backlogs” weicht auch LeSS Huge nicht ab. Nur gehört jedes PBI eindeutig zu einer Requirement Area.

Die folgende Übersicht verdeutlicht die Gemeinsamkeiten und die Ergänzungen, die Du in einer LeSS Huge Implementierung vornimmst. Dabei ergänzt LeSS Huge die weiterhin gültigen LeSS Regeln. Weitere Details zu LeSS Huge kannst Du auf der LeSS Webseite nachlesen.

Die Einführung von LeSS ist, je nach Größe der Organisation, ein monatelanger Lernprozess. Dabei definiert das LeSS Framework drei absolut entscheidende Leitlinien für jede LeSS Einführung.

1. Deep and Narrow over Broad and Shallow: Eine gute, strukturierte und vollständige Umsetzung für ein Produkt und ein Team ist wertvoller als eine unvollständige, fehlerhafte und zögerliche Umsetzung für alle Produkte und Teams.
2. Top-down and Bottom-up: Eine erfolgreiche LeSS Einführung braucht sowohl Energie, Einsatz und Support von unten, als auch die Unterstützung der Manager mit organisatorischen Kompetenzen.
3. „Freiwillige vor“: Gerade bei der Einführung sollten Mitarbeiter nicht gezwungen werden ihr angelerntes Verhalten und bekannte Umgebung zu verlassen. Freiwillige, experimentierfreudige Mitarbeiter dürfen zunächst mit den neuen Ideen und Strukturen von LeSS vertraut gemacht und in die frühe Umsetzung eingebunden werden. Alle anderen werden folgen mit fortschreitender Umsetzung.

Über diese drei Leitlinien hinaus empfiehlt LeSS außerdem die folgenden Schritte, um die Wahrscheinlichkeit einer erfolgreichen LeSS Einführung zu erhöhen.

Handelnde Personen benötigen ein gemeinsames Verständnis was das Produkt ist. Das ist eine vermeintlich einfache, in der Praxis aber schwer zu beantwortende Frage. Denn sehr oft sind Produktdefinitionen sehr technisch oder eng definiert. Die Definition des Produktes hat direkte Auswirkung auf den Umfang der LeSS Anpassung. 

Eine mindestens genauso spannende Diskussion ist die Frage, was alles in die gemeinsame “Definition of Done” gehört. Denn eine weitgehende Definition of Done (DoD) erfordert funktionierende, gut besetzte und gut ausgebildete Teams mit einem breiten Wissen. Zudem führt eine stärkere und bessere DoD zu mehr organisatorischen Veränderungen.

Je mehr Mitarbeiter und Beteiligte verstehen, wieso und weshalb die Veränderungen geschehen und wie sich diese positiv auswirken, umso besser. Deswegen baue möglichst viel Wissen zu LeSS in deiner Organisation auf.

Teams sind der zentrale Baustein für eine erfolgreiche LeSS Adaption. Aus diesem Grund ist es gerade zu Beginn einer Einführung erforderlich einen Fokus auf die Teams, deren Bildung und Zusammensetzung zu legen. Bei der Teambildung wird im Idealfall eine freie, selbstständige Teamfindung bevorzugt. Dabei kannst Du soweit gehen, dass sich Teams selbst finden (“self designed”). Dennoch sollen die Teams sicherstellen, dass mindestens 50% aller Teams Feature-Teams sind sowie die Kundenanforderungen autonom, end-to-end gegen die Definition of Done liefern können.

Gerade der Beginn etwas Neuen birgt die Gefahr, dass in alte Verhaltensmuster zurückgefallen wird. Gerade, wenn Du aus einer traditionellen Organisation kommst. Stelle also von Anfang an sicher, dass Teams nur Arbeit über den Product Owner bekommen. Kein Manager oder andere Abteilung darf und kann dem Team Arbeit geben und damit in die Autonomie der Teams eingreifen.

LeSS kennt keine Projektmanager. Sofern diese in bestehenden Strukturen existieren, können sie in der LeSS Organisation als Teammitglieder oder Product Owner eine neue Rolle finden.

Wie bei allen organisatorischen Änderungen ist ein intensives Coaching wichtig, um Mitarbeiter zu unterstützen und Veränderungen wertschätzend zu begleiten. Das Coaching sollte sowohl einzelne Teams und Mitarbeiter im Umgang mit LeSS beinhalten, als auch den Umgang mit technischen Prozessen und Werkzeugen.

Zu guter Letzt darf eine gesunde Prise Humor auch bei der Einführung von LeSS nicht fehlen. Selbstorganisierte Systeme leben von der Freude gemeinsam etwas zu erschaffen und zu lernen. Nimm Dich und die Fehler nicht so ernst, bleib im Prozess und befolge ShuHaRi in Bezug auf die LeSS Regeln und die LeSS Prinzipien. 

LeSS verfolgt einen sehr systemischen Ansatz mit minimalen und unkomplizierten Regeln. Was mir an LeSS gut gefällt, ist der Aspekt, dass viel Verantwortung in die Hände umsetzender Teams gelegt wird und die Idee der empirischen Prozesskontrolle auch auf Ebene des Frameworks konsequent lebt. Die größte Herausforderung ist sicherlich, das eigene Produkt auf einem entsprechenden Abstraktionsgrad zu definieren. Das gilt vor allem dann, wenn deine angebotene Leistung bzw. dein Produkt ein Hybrid aus technischer Plattform und Dienstleistungen ist. Dabei ist sicherlich die größte persönliche Herausforderung, sich von der eigenen technokratischen Sichtweise und dem Bild zu lösen, was unser Denken über Arbeit bestimmt. Nämlich, dass die Organisation von Arbeit immer einer funktionalen Aufteilung folgen muss. Wenn Du dieses 100 Jahre alte Bild hinter Dir lassen kannst, wird es leichter. Auch mit LeSS. 

Viel Erfolg dabei.