Make it big! LeSS – Large Scale Scrum

Präsidentenpalast BukarestIn den letzten Monaten wirft sich mir bei Kunden immer wieder die Frage nach einer Skalierung von Scrum auf. Das ist zwar insofern recht bemerkenswert, da viele Firmen schon mit einer stabilen Implementierung innerhalb eines einzelnen Teams Schwierigkeiten haben. Da werden Entwickler zum Teilzeit Scrum Master ausgelobt und der Product Owner ist auch nicht genügend in den Entwicklungsprozess eingebunden, off-site oder ist eine Art Architekt mit Chefentwicklerstatus.

Vielleicht könnte ja gerade ein Skalierungsansatz diese Probleme bereits im Kern lösen, da bei einer SCRUM-Einführung im Enterprise-Umfeld ja ohnehin umfassender gedacht wird und die systemischen Probleme dabei grundsätzlich behoben werden könnten.

Deshalb habe ich mir eine Skalierungsmethodik für SCRUM näher angeschaut, die Craig Larmann entwickelt hat und erfolgreich in Produktentwicklungen mit mehreren tausend Personen und über mehrere Standorte hinweg eingesetzt hat. Dazu hatte ich die Gelegenheit, bei Craig persönlich eine Einführung zu bekommen, die nicht nur sehr interessant sondern dabei auch kontrovers und spannend diskutiert wurde.

LeSS

Eine der ersten Beschreibungen über LeSS lautet: „LeSS is SCRUM“. Das klingt zunächst trivial ist aber ein sehr wichtiger Aspekt, der einem beim Blick auf das visualisierte Framework ins Auge sticht. Im Grunde genommen gibt es keine zusätzlichen Rollen, Artefakte oder Abstimmungstermine , die man nicht schon vom klassischen SCRUM kennt.

Es gibt ebenso:

  • das Team,
  • den Product Owner und
  • den SCRUM Master.

Die Teams sind so aufgestellt, dass sie als multifunktionale Teams alle am selben Produkt arbeiten. Damit gibt es genau einen Product Owner für alle Teams, die an diesem Produkt arbeiten. Die Teams sind inhaltlich und priorisierungstechnisch gleich gestellt, müssen aber nicht zwangsläufig gleich groß sein.

Also: Bisher alles beim Alten!

Interessant ist , in welcher Zusammensetzung die Meetings stattfinden und mit welchem Fokus. Nehmen wir das:

Planning 1

Die Teilnehmer
Die Beteiligten des Planning1 sind der Product Owner, von jedem Team maximal zwei Vertreter und evtl. die Scrum Master – wobei diese nicht erforderlich sind. Die Scrum Master sind niemals die Repräsentanten der Teams. Es geht hier nicht um vermeintliche Teamverantwortung oder gar um eine „Projektleitung“. Es sind tatsächliche Teammitglieder notwendig, die im Laufe der Sprints auch wechseln, damit alle Team Mitglieder diese Rolle einnehmen.

Vorgehen
Der Product Owner stellt die Backlog-Items, die er für den anstehenden Sprint ausgewählt hat den Team Vertretern aus allen Teams vor und beantwortet die dabei anfallenden Fragen. Soweit geschieht inhaltlich erst einmal das gleiche, wie bei jedem anderen Scrum-Planning 1 auch.

Danach suchen sich die Vertreter aus den vorgestellten Items, die aus, die sie in ihre Teams tragen möchten.

Anschließend werden in dieser Runde die Abhängigkeiten zwischen den einzelnen Arbeitssträngen besprochen – seien es Architektur- oder fachliche Fragen. Am Ende der Diskussion ist klar, welches Team im kommenden Sprint welche Themen mit anderen Teams noch näher beleuchten muss, um den Sprint erfolgreich anzuschließen. Diese Abstimmungen erfolgen parallel zum Sprint in dazu selbständig einzurichtenden Communities of Practise. Im Planning 1 werden lediglich die Notwendigkeiten zur Abstimmung untereinander festgehalten und evtl. leicht lösbare Themen schon angegangen.

Planning 2

Die Repräsentanten der Teams gehen mit ihren Sprint Backlogs in Ihre Teams und planen die Spezifizierung der Backlog Items, die Vorgehensweise und die Umsetzung für den Sprint. Hier bleibt im Prinzip alles, wie gehabt. Am Ende startet das Team in den Sprint.

Sprint Review

Hier treffen sich wieder der Product Owner und Repräsentanten der Teams und das fertige Produkt wird vorgeführt. Die DoD wird abgehakt und der Product Owner nimmt das fertige Produkt-Inkrement ab.

Team Retrospective

Die Retro zum Sprint wird zunächst im Team mit seinem Scrum Master durchgeführt. Auch hier gelten die gleichen Regeln wie beim nativen SCRUM. Lediglich Themen, die in der Zusammenarbeit zwischen Teams oder mit dem Product Owner liegen, werden in die Joint Retro mitgenommen

Joint Retrospective

Hier werden die Themen zwischen Vertretern aller Teams, den Scrum Mastern und dem Product Owner besprochen, Änderungen festgehalten und nach dem Prinzip „inspect and adapt“ durchgeführt

Im Schaubild sieht so ein Vorgehen folgendermaßen aus:

LeSS Framework
LeSSFramework nach Craig Larmann

LeSS Huge

Craigs provokative Aussage zum Thema „Große Produktentwicklungen, die an verschiedenen Orten und offshore stattfinden“ lautet:

large: don’t

multisite: dont

offshore: don’t

Dennoch gibt es zu LeSS noch eine Erweiterung, die den Faktor von einer großen Anzahl von Teams (>8-10 Teams) und das (global) verteilte Aufstellen von Produktentwicklungen behandelt.

Essentielle Änderung ist die verteilte Aufstellung eines Product Owner Teams. Es gibt zwar nach wie vor nur einen Product Owner. Dieser kann in einer multisite-Umgebung aber nicht an allen Standorten parallel am Planning 1 teilnehmen. Deshalb teilt sich der Product Owner mit den Area Product Ownern diese Tätigkeit. Davon gibt es so viele, wie es Standorte gibt.

Ebenso macht dieses Vorgehen bei Produktentwicklungen mit mehr als 10 Teams Sinn, da bei wachsender Anzahl von Team Vertretern das Planning 1 zu lange würde. So teilen sich die Area Product Owner die Arbeit an einem Standort auf.

Im Schaubild sieht so ein Vorgehen folgendermaßen aus:

 LeSS Huge Framework
LeSS Huge Framework nach Craig Larmann

Transition

Wie kann man von einer Linien-geprägten Unternehmensstruktur in einen solchen Arbeitsmodus wechseln? Das ist für die meisten Unternehmen aber auch Agile Coaches und Scrum Master eine essentielle Frage, die von Craig sehr „straight“ beantwortet wurde:

top -> down, starting from C-level management

Eine Änderung und Implementierung hin zu SCRUM geht nur, indem die komplette Produktionskette umgestellt wird und das geht nur mit einem verbindlichen committment der Unternehmensleitung oder mindestens dem Vice-President / Bereichsleiter der Produktentwicklung. demnach wäre ein Strategie:

  1. Schulung und Verpflichtung des C-Level Managements, agile Produktentwicklung anzuwenden
  2. Auflösen bestehender Abteilungen und Teams, die zu Spezialisten- oder Komponententeams zusammengestellt wurden. Damit sind aber auch die daran gekoppelten Abteilungs- und Teamleiter ihrer Funktion entledigt.
  3. Zusammenstellen der Multifunktionalen Teams unter Anleitung der SCRUM Master. Diese füllen die Lücke, die durch die weg fallenden Linien-Führungskräfte entstanden ist.
  4. Erstellen und Priorisieren des Product Backlogs
  5. Vorbereitung für den ersten Sprint durch den Product Owner und die SCRUM Master

Fazit

Wie man leicht erkennen kann, ist LeSS nur eine kleine Erweiterung zum bisher bekannten SCRUM. Es erweitert diesen Ansatz um wenige Punkte, die einerseits die Abhängigkeiten zwischen den Teams steuert und den Umgang mit einer Vielzahl von Teams koordiniert. Der Rest ist den Maximen der agilen Entwicklung unterworfen:

  • Selbstverantwortung und -organisation der Teams,
  • Verantwortung für die Weiterentwicklung des Produkts liegt beim Produkt Owner und
  • die SCRUM Master dienen der Adaption von SCRUm und agilen Werten und sind methodische Impulsgeber.

Meiner Meinung nach hat dieses Vorgehen den Charme, dass es natives SCRUM ist und sich nicht an die alt hergebrachten Bedürfnisse von Unternehmensstrukturen der klassischen Welt anbiedert. Auch löst es das „Contract Game“ zwischen Beauftrager und Umsetzer auf, da der Entscheider – also der „Eigentümer des Produkts“ direkten Einfluss auf den Zeitpunkt und die Priorisierung einer Feature-Entwicklung hat. Er entscheidet und verantwortet, wann welches Feature kommt.

Schwierig dürfte eine agile Transition nach LeSS deshalb werden, da es keine „Grassroots-Bewegung“ zulässt, sondern im oberen Management angesiedelt sein muss. Nur wenige Agile Coaches und Berater werden die Gelegenheit haben, an diesen Punkten anzusetzen und den enormen Umbau der Unternehmensstruktur durchsetzen können. Und mit einer Fake-SCRUM Implementierung, da Strukturen nicht aufgelöst werden, gehen die offensichtlichen Vorzüge von SCRUM leider verloren – egal ob im Kleinen oder im Großen.

Links und Literatur

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.