Large Scale Scrum (LeSS) ist Scrum, angewendet auf mehrere Teams, die ein Produkt entwickeln. Dieser Definition von LeSS liegen (neben den Prinzipien) auch Regeln zugrunde. Diese Regeln sind sehr einfach und fokussiert.
Die LeSS Regeln sind Teil dieses Artikels und wir werden die Regeln und Auswirkungen betrachten sowie die Anwendbarkeit auf die Praxis beleuchten. Dabei gibt es zwei Arten dieser LeSS Regeln, einmal für das "normale" LeSS und einmal die erweiterten Regeln für LeSS Huge. Letztere betrachten wir hier nicht weiter im Detail.
Hinweis: Im Folgenden habe ich diese Kästen eingefügt, um auf besondere Umstände und Praxiserfahrungen hinzuweisen. Den Artikel zu LeSS in der Übersicht kannst du hier nachlesen.
Ich betrachte die LeSS Regeln auf deutsch und als Basis dient die offizielle Übersetzung, die Sie auch der Webseite von less.works finden.
Übersicht über die LeSS Regeln
Die LeSS Regeln verteilen sich auf drei Bereiche. Diese drei Bereiche ermöglichen eine erste Gruppierung dieser Regeln. Dazu zählen Struktur, das Produkt und der Sprint.
Die Regelbereiche
STRUKTUR
Regeln, die die Struktur adressieren.
Produkt
Regeln, die das Produkt selbst adressieren.
Sprint
Regeln, die den Sprint adressieren.
LeSS Regeln für die Struktur
Organisationen mit echten Teams
Es ist wenig überraschend, aber in agilen Umgebungen sind echte agile Teams die Basis für alles. So findet sich auch in den LeSS Regeln ein Hinweis genau auf diesen Aspekt. Ebenso haben wir schon gelesen, dass es um skaliertes Scrum geht. Auch Scrum nutzt agile Teams als Grundlage.
Entwerfe Organisationen mit echten Teams als fundamentale Bausteine
Auch wenn der Punkt der LeSS Regeln ziemlich selbstverständlich klingt, ist es das oft gar nicht. Achten Sie darauf, dass Sie die Punkte aus der nächsten Regel einhalten.
Echte agile Teams
Echte agile Teams finden sich bei weitem nicht so oft, wie Organisationen gerne behaupten. Damit Sie echte agile Teams finden können, dienen vier Punkte, die sowohl in den Regel vorkommen, als auch hier noch einmal explizit genannt werden.
Jedes Team ist (1) selbst-organisierend, (2) funktionsübergreifend, (3) alle arbeiten im selben Raum und sind (4) langlebig.
Hinweis zu echten agilen Teams der LeSS Regeln
Die obigen Eigenschaften kennen Sie wahrscheinlich, wenn Sie im agilen Kontext Erfahrungen und Projekte gemacht haben. Ein Hinweis möchte ich dazu noch anbringen. Nicht jeder Punkt werden Sie wahrscheinlich zu 100% erfüllen können. Wenn Sie in einem großen Unternehmen arbeiten, dass über verschiedene Standort agiert, dann haben Sie zum Beispiel nicht immer "Teams vor Ort". Beachten Sie bitte diese Regeln als optimale Vorgabe. Wenn Sie diese nicht erfüllen, dann kann Ihre Implementierung trotzdem noch funktionieren. Wenn die zu weit an diesen Regel "herum doktern", dann wird Ihre Implementierung mit Sicherheit nicht mehr funktionieren.
Ich habe für mich die folgende Aufstellung vorgenommen, die sich für mich in der Praxis als gut erwiesen hat. Und auch hier bitte nicht falsch verstehen: dieser Ansatz hilft mir für den Start, ist nicht das Optimum. Sie sollten an der Stelle immer kontinuierlich schauen, wie Sie diese LeSS Regeln richtig umsetzen.
Feature Teams
Häufig finden Sie den Begriff der Feature- und Komponententeams. In den LeSS Regeln fokussieren wir uns auf die Featureteams.
Die Mehrheit der Teams sind kundenorientierte Feature-Teams.
Zu den Featureteams gibt es ein sehr interessantes Bild, welches ich von der less.works Webseite entnommen habe. Auf diesem erkennen Sie den Unterschied zwischen Komponenten- und Fetaureteams.
Um gute Feature Teams zu etablieren sind nicht nur die oben genannten Eigenschaften der agilen Teams wichtig, sondern auch die später betrachtete Produktdefinition. Um die Feature Teams zu erstellen, nutzen Sie die folgenden Hinweise und befragen Sie auch immer die Wegweiser aus dem LeSS Framework.
Diese Betrachtung ist essentiell und darf von den Unternehmen nicht leichtfertig auf die Schulter genommen werden. Diese Entwicklung bedarf ebenso eine Entwicklung bei den Mitarbeitern und der gesamten Organisation.
Verantwortung Scrum Master
Wenig überraschend findet sich in den LeSS Regeln auch die Prozessverantwortung beim Scrum Master. Er ist dazu - analog zu Scrum - angehalten, den Fokus auf die Teams, Product Owner sowie die Organisation und Entwicklungsmethoden zu legen.
Scrum Master sind für eine gut funktionierende LeSS Einführung verantwortlich. Ihr Fokus sind die Teams, der Product Owner, die Organisation und die Entwicklungsmethoden. Ein Scrum Master fokussiert sich nicht nur auf ein Team, sondern auf die gesamte Organisation.
Scrum Master blicken auch immer auf die Organisation im Ganzen. Damit wir bewusst den Blick darauf legen, was für den Kunden und seinen "Wertstrom" essentiell ist. Sie sollten die Rolle des Scrum Masters auch in der Organisation bei einem "kleinen" Scrum so sehen. im skalierten Umfeld fällt es viel schneller auf, wenn Sie Scrum Master haben, die nur die Events moderieren.
Scrum Master als Vollzeit
Damit keine Konflikte mit Rollen auf Aufgaben auftreten, bietet es sich immer an, dass der Scrum Master als Vollzeitrolle verstanden wird. So gibt es auch den entsprechenden Verweis in den LeSS Regeln.
Ein Scrum Master ist eine dedizierte Vollzeitrolle.
Wenn wir dabei den Fokus noch mal auf die Organisation legen, dann wird auch recht schnell klar, dass nicht so viele weitere Möglichkeiten außer einer Vollzeitrolle bestehen. Es sind eben nicht nur die reinen moderativen Elemente die entscheidend sind, sondern das Denken im Sinne von Systemen und Wertströmen. Das braucht Zeit und den entsprechenden Fokus.
Scrum Master und Teams
Ich kann mich früher an die Scrum Schulungen immer noch sehr gut erinnern: "Wie viele Scrum Teams kann denn ein Scrum Master betreuen?" In den LeSS Regeln findet sich dazu ein konkreter Hinweis:
Ein Scrum Master kann zwischen einem und drei Teams betreuen.
Dazu auch der Abgleich gegen die Realität: drei Teams finde ich schon ziemlich herausfordernd. Mit zweien haben ich mich in der Regel noch recht wohl gefühlt. Hier finden sich oft auch unterschiedliche Reifegrade der Teams vor, so dass eine Betreuung unterschiedlich stark aussehen kann.
Manager und LeSS
In den LeSS Regeln finden auch die Manager Platz. Sie sind zwar optional, aber nichtsdestotrotz finden diese hier eine entsprechende Erwähnung. Aus meiner Praxiserfahrung ist das auch sehr wichtig. Gerade wenn wir gestandene Organisationen haben, ist es elementar, dass wir an diese Personengruppen denken.
In LeSS sind Manager optional, aber wenn sie existieren, wird sich ihre Rolle sehr wahrscheinlich ändern. Ihr Fokus verschiebt sich vom Managen der täglichen Arbeit hin zur Verbesserung der Organisation und der Entwicklungsmethoden.
Ebenso adressieren die LeSS Regel auch den wandelnden Fokus der Manager. Das ist auch der wirklich entscheidende Punkt. Nicht die Personen müssen gehen, aber ihre Rolle und die Aufgaben werden sich ändern.
Aufgabe Manager
Viele Manager finden sich heute schon in einer Art Dilemma, die möchten führen und müssen managen. Das ist oft nicht leicht, in den LeSS Regel findet sich ebenso der Hinweis hin zu einer führenden und wertstromverbessernden Aufgabe.
Die Aufgabe des Managers ist die Verbesserung des Produktentwicklungssystems durch die Anwendung von „Go See“, sowie der Ansätze „Stop & Fix“ und „Experimente über Konformität“.
Produktgruppe
Ein Produkt zu etablieren ist ein schwieriges Unterfangen. In vielen Unternehmen finden sich viele Produkte. Es wird sich nicht genügend Gedanken darüber gemacht, wie ein Produkt aussehen soll. Es ist einfacher mehrere Produkte zu definieren, die wiederum nur den bisherigen Organisationsstrukturen entsprechen, als sich einem guten Produktgedanken für die agile Entwicklung zu widmen.
Die gesamte LeSS Struktur muss für die Produktentwicklungsgruppe vom Beginn an etabliert werden; das ist für eine LeSS Einführung essentiell.
In LeSS steht für das Etablieren von Produkten ein Wegweiser bereit, um sich diesen Thema zu nähern. In LeSS fokussieren wir auf einer breiten Produktdefinition, die als Basis dient. Eine mögliche Produktgruppe könnte wie folgt aussehen.
Beachten Sie auch hier bitte die Einfachheit der Struktur. Das Produkt wird von mehreren Teams entwickelt, die aber hier zum Beispiel keinen eigenen Team Product Owner besitzen. Es gibt einen Product Owner, der ein Produkt entwickelt.
Evolutionäre Weiterentwicklung
Die Weiterentwicklung von LeSS in der Organisation wird nicht halt machen. Doch was und wie passiert diese Weiterentwicklung innerhalb der restlichen Organisation? Das passiert in der Regel
Für die restliche Organisation, die über die Produktentwicklung hinausgeht, sollte LeSS evolutionär eingeführt werden. Dies kann durch „Go See“ erreicht werden, wodurch eine Organisation entsteht, in der Experimente und Verbesserungen zum Alltag gehören.
LeSS Regeln für das Produkt
Product Owner und Backlog
In vielen Unternehmen finden sich auch sehr viele Product Owner. Diese haben oft unterschiedliche Hierarchieebenen und steuern gemeinsam Backlogs. In den LeSS Regeln gibt es diesen klaren Hinweis:
Es gibt einen Product Owner und ein Product Backlog für das gesamte auszuliefernde Produkt.
Wenn wir unsere Produktdefinition gefunden haben, dann wollen wir dafür auch einen Product Owner. Und zwar genau einen. Aus meiner Praxis habe ich oft den Fall, dass es diesen einen Product Owner in vielen Organisationen schlicht nicht gibt. Doch auch dafür haben die LeSS Regeln einen Hinweis. Sie verlagern vieles in die Selbstorganisation des Teams. Und dafür benötigt es eine hohe Reife im Team.
Selbstorganisation Teams für das Backlog
An diesem Punkt sieht man sehr schön (wie oben angesprochen), dass Unternehmen einiges an Reife mitbringen müssen. Die Teams sollen den Product Owner unterstützen, in dem er nicht alleine für das Product Backlog arbeiten muss, sondern die Hilfe der Teams bekommt.
Der Product Owner sollte nicht alleine an der Verbesserung des Product Backlogs arbeiten. Er wird dabei von mehreren Teams unterstützt, die direkt mit dem Kunden/den Benutzern und anderen Stakeholdern arbeiten.
Gerade in der Abstimmung mit anderen Stakeholdern ist so etwas sehr relevant. Die Teams stimmen sich zudem auch mit den Kunden selbst und Keyusern ab. Wie Sie bereits an solchen Regeln sehr gut sehen können, eignet sich ein LeSS an der Stelle besonders für Teams, die solche Arbeitsweisen leben wollen und auch können.
Wenn Sie wenig Erfahrungen mit agilen Vorgehen gemacht haben, noch keine agilen Teams im Unternehmen haben, dann werden Sie auch mit den Regeln einiges an Arbeit vor sich haben.
Reife der Organisation
Diese Regel ist eine, die aus meiner Sicht eine besondere Reife der Organisation voraussetzt. Die meisten großen Organisationen sind mit so einer Arbeitsweise überfordert. Zudem sind die organisatorischen Strukturen oft so, dass die es nicht ermöglichen, zum Beispiel mit dem Kunden direkt zu sprechen.
Das zeigt auch, wie wichtig es zu Beginn ist, diese Struktur zu schaffen oder zumindest darauf hin zu arbeiten.
Priorisierungen
Die Priorisierungen nimmt der Product Owner selbst vor. Das ist wenig überraschend, das kennen wir aus dem reinen Scrum. Normalerweise ist der Product Owner zentral die Person, die auch die Kommunikation mit den Stakeholdern übernimmt. In den LeSS Regel findet sich der folgende Hinweis:
Alle Priorisierungen nimmt der Product Owner vor, aber Abklärungen finden so viel wie möglich direkt zwischen den Teams und dem Kunden/den Benutzern und anderen Stakeholdern statt.
Da brauchen Sie als Product Owner und Team ein gutes Vertrauensverhältnis. Sie brauchen die echten agilen Teams und Sie brauchen die bereits oft zitierte Reife. Wenn Sie diese Regel aber beherzigen und die Rahmenbedingungen haben, dann bekommen Sie so ein recht schlankes und effizientes Gerüst, dass Ihnen hilft die richtigen Produkte zu entwickeln.
Definition Produkt
In der Praxis ist die Definition des Produktes eine richtige Mammutaufgabe. Gerade in den Unternehmen, die historisch gewachsen sind, die Strukturen etabliert haben, die auf dem Tailorismus beruhen, ist es nicht leicht, die folgende Regel einzuhalten:
Die Definition des Produkts sollte so generell und endbenutzer-/kundenorientiert wie möglich sein. Im Laufe der Zeit kann die Definition wachsen. Breitere Definitionen sind bevorzugt.
Wir kennen Sie alle, die Produkte, die eigentlich keine sind. Gerne finden wir Dinge wie zum Beispiel die folgenden Produkte
Produktdefinition
LeSS stellt Wegweiser bereit, die Produkte zu definieren. Dabei ist vieles sehr einfach gehalten. Diese Einfachheit ist für die meisten Unternehmen aber noch nicht greifbar.
Es hat sehr viel damit zutun, dass Sie Ihre "Probleme" nicht übernehmen und skalieren dürfen.
Eine Definition of Done
Die Definition of Done bekommt zwei Regeln innerhalb der LeSS Regeln ab. Zunächst gibt es die Regel, dass eine Definition of Done für das ganze Produkt existiert. Das ist für den eingefleischten Scrumanwender keine Überraschung. Die Definition of Done gehört schließlich zu Scrum dazu.
Es existiert eine „Definition of Done (DoD)“ für das gesamte Produkt und ist für alle Teams gleich.
Erweiterung Definition of Done
Jedes Team darf selbst entscheiden, dass es sich eine stärkere Definition of Done auferlegt. Das kann durchaus sinnvoll sein. So sind Verbesserungen in Qualität zum Beispiel denkbar, um sich diesem Thema zu widmen. Ebenso kann man sich experimentelle Dinge vorstellen, die einfach mal ausprobiert werden können, um zu einer verbesserten Definition of Done in Summe zu gelangen.
Jedes Team kann seine eigene, stärkere „Definition of Done“ besitzen, indem es die gemeinsame DoD um eigene Punkte erweitert.
Verbesserung Definition of Done
Diese LeSS Regel finde ich sehr wichtig, denn in dieser Regel sprechen wir von einem Ziel. Das ist sehr wichtig und zugleich wertvoll, denn viele Organisationen stehen da zu Beginn Ihrer Reise noch nicht.
Das Ziel ist es die „Definition of Done“ so weit zu verbessern, dass nach jedem Sprint – oder öfters – ein auslieferbares Produkt entsteht.
Mit dem Team Adoption Map haben Sie aus dem LeSS zudem ein Tool an der Hand, dass es Ihnen erlaubt - leicht abgewandelt - einen Blick auf die Entwicklung der Definition of Done zu werfen.
Wichtig ist es auch hier, zu beginnen. Starten Sie mit dem was Sie haben. Machen Sie mit dem Team einen Workshop, was schon für die Definition of Done möglich ist. Finden Sie Verbesserungen und nutzen Sie ihr Sprint Backlog, um solche Verbesserungen im Sprint umzusetzen.
LeSS Regeln für den Sprint
Gemeinsamer Sprint
Kurz und knackig, es gibt in den LeSS Regeln einen Verweis auf einen gemeinsamen Sprint. Nicht mehrere, keine unterschiedlichen Start- und Endpunkte. Und ein Gesamtprodukt am Ende. Auch hier sei noch mal die Produktdefinition erwähnt, wenn wir an unterschiedliche Domänen wie Software und Hardware denken, müssen wir physikalische Rahmenbedingungen im Auge behalten.
Es gibt einen gemeinsamen Sprint pro Produkt anstatt eines Sprints für jedes Team. Jedes Team started und beendet den Sprint zur selben Zeit. Jeder Sprint bringt ein integriertes Gesamtproduktinkrement hervor.
Sprint Planung
Wie auch im normalen Scrum haben Sie hier den Verweis auf das zweiteilige Sprint Planning. Diese zwei Teile müssen nicht zwangsläufig sequentiell ablaufen, oft gibt es ein daran angelehntes, erfahrungsbasiertes Vorgehen, was sich daran orientieren kann.
Die Sprint Planung besteht aus zwei Teilen: Sprint Planning Teil 1 wird mit allen Teams gemeinsam durchgeführt während Sprint Planning Teil 2 in der Regel von jedem Team selbstständig abgehalten wird. Für eng verbundene Product Backlog Elemente sollte das Sprint Planning Teil 2 für mehrere Teams an einem gemeinsamen Ort stattfinden.
Hier sehen wir wieder einen wichtigen Punkt der Selbstorganisation. Während die Teams den Teil 1 in der Regel zusammen machen (siehe auch nächste LeSS Regel), ist der zweite Teil der Selbstorganisation überlassen. Das betrifft hier auch Abhängigkeiten.
Teilnahme an der Sprint Planung
Am Sprint Planning Teil 1 nehmen der Product Owner und die Teams oder deren Repräsentanten teil. Zusammen wählen sie die Product Backlog Elemente aus, die im kommenden Sprint von den Teams umgesetzt werden sollen. Zudem identifizieren die Teams Möglichkeiten der Zusammenarbeit und noch offen gebliebene Fragen werden geklärt.
Die Stellvertreter Regel setzt wieder ein echtes agile Team voraus. Die LeSS Regeln gehen an dieser Stelle nicht zu tief in die Materie, aber mit den Wegweisern bekommt der interessierte Leser weitere wertvolle Unterstützung bei der Umsetzung.
Sprint Backlog
Es gibt ein Product Backlog für alle und ein Sprint Backlog, das in jedem Team vorhanden ist und durch das Team genutzt wird.
Jedes Team hat seinen eigenen Sprint Backlog.
Sprint Planning 2
Die LeSS Regel zum Sprint Planning 2 unterscheidet sich nicht zu reinen Scrum. Auch hier liegt die konkrete Umsetzung, als das "wie" in der Verantwortung der Teams.
Während des Sprint Plannings Teil 2 entscheiden die Teams, wie sie die ausgewählten Product Backlog Elemente umsetzen werden. In der Regel beinhaltet es das Design und die Erstellung des Sprint Backlogs.
Daily Scrum
Während in der Teams das Daily Scrum als LeSS Regel ebenso gesetzt ist, gibt es zum Beispiel keine LeSS Regel über ein Scrum of Scrums, sondern nur eine weitere Regel über die teamübergreifende Kommunikation.
Jedes Team hält sein eigenes Daily Scrum ab.
Teamübergreifende Koordination
Die LeSS Regel zur teamübergreifenden Kommunikation wird durch die dezentrale Kommunikation gestützt.
Teamübergreifende Koordination wird von den Teams durchgeführt. Dezentralisierte und informelle Koordination ist der zentralisierten Koordination vorzuziehen. Lege Wert auf Kommunikation und informelle Netzwerke, wie zum Beispiel Kommunikation über Code (Kommentare, etc.), teamübergreifende Besprechungen, Mentoren für Komponenten, Reisende („travelers“), Kundschafter und Open Spaces.
Product Backlog Refinement
Das Product Backlog Refinement ist häufig ein neuralgischer Punkt in vielen Implementierungen. Die LeSS Regeln fokussieren auch hier auf ein selbstbestimmtes Vorgehen der Teams.
Product Backlog Refinement (PBR) wird von jedem Team für jene Product Backlog Elemente erledigt, die es wahrscheinlich in der Zukunft umsetzten wird. Multi-Team PBR und übergreifendes PBR dienen dazu das gemeinsame Verständnis zu erhöhen und Möglichkeiten der Zusammenarbeit zu erkennen, wenn es stark zusammenhängende PB Elemente gibt. Zudem helfen Multi-Team PBR und übergreifende PBRs, wenn es einen Lernbedarf bzw. eine breitere Meinung gibt.
Sprint Review
Das Sprint Review wird nicht innerhalb der einzelnen Teams durchgeführt, sondern nur übergreifend in einem gemeinsames Sprint Review.
Es gibt gemeinsam für alle Teams einen Sprint Review für das Produkt. Es gilt sicherzustellen, dass die richtigen Stakeholder am Review teilnehmen, um die nötige Information für eine effektive Inspektion und Adaption einzubringen.
Sprint Retrospektive
Jedes Team führt seine eigene Sprint Retrospektive durch. Dadurch liegt der Fokus auf dem Team selbst. Alles, was das eigene Team verlässt und übergreifenden Fokus hat wird in der der übergreifenden Retrospektive betrachtet.
Jedes Team hält seine eigene Sprint Retrospektive ab.
Übergreifende Sprint Retrospektive
Natürlich sollen auch übergreifende Belange adressiert werden. Ebenso gibt es Verbesserungsbedarf zwischen den Teams. Alles das passiert in der übergreifende Sprint Regel, die als letztes in den LeSS Regeln zu finden ist.
Eine übergreifende Retrospektive wird im Anschluss an die teambezogenen Retrospektiven durchgeführt, um die teamübergreifenden und organisationsweiten Probleme zu diskutieren und Experimente zur Verbesserung zu erarbeiten. Daran nehmen der Product Owner, die Scrum Master, die Teamrepräsentanten, sowie die Manager (sofern es welche gibt) teil.
