Scrum skalieren nach LeSS mit objectiF RPM

In jeder Organisation, die mit Scrum in kleinen Projekten erfolgreich arbeitet, stellt sich früher oder später die Frage: Kann man das agile Erfolgsrezept auch auf größere Vorhaben übertragen? Und wenn ja, wie skaliert man Scrum am besten? Schon seit vielen Jahren machen Frameworks zum Skalieren agiler Managementmethoden und speziell von Scrum von sich reden. Längere Zeit stand das Scaled Agile Framework SAFe von Dean Leffingwell et al. (2011)[1] im Mittelpunkt der Diskussion in Fachmedien und auf Kongressen. Meine subjektive Wahrnehmung ist, dass Large Scale Scrum, kurz LeSS, von Craig Larman und Bas Vodde (2008)[2] aufholt und immer beliebter wird.

Was ist LeSS?

Vereinfacht kann man sagen: LeSS ist Scrum, angewandt auf viele Teams, die gemeinsam an einem Produkt arbeiten. Hinter LeSS verbergen sich zwei Frameworks:

• eines für bis zu 8 Teams, das ebenfalls als LeSS bezeichnet wird,
• ein zweites für mehr als 8 Teams, LeSS Huge genannt.

Vier Bestandteile machen LeSS aus:

• Regeln zur Durchführung,
• Wegweiser, die helfen, die Regeln einzuführen,
• Experimente nach dem Motto „Versuch macht klug“,
• Prinzipien, die die Entscheidungsgrundlage dafür bieten, wie LeSS im speziellen Projektkontext am besten angewendet wird.

Hier soll es nicht um das theoretische Fundament von LeSS gehen (dafür ist [2] eine hervorragende Quelle), sondern ganz praktisch um die Frage:

Wie geht LeSS?

Die Antwort lautet: Im Wesentlichen genauso wie Scrum für ein Team:

• Die Rollen – Product Owner, Scrum Master, Team – sind identisch.
• Im Sinne des Prinzips eines ganzheitlichen Produktfokus, gibt es einen (einzigen!) Product Owner und genau ein Product Backlog – egal wie viele Teams am Projekt mitarbeiten.
• Der Product Owner verfeinert – ggf. unterstützt durch Teamvertreter – das Product Backlog und priorisiert die Backlog-Einträge.
• Es gibt einen Sprint für alle Teams oder – anders betrachtet – alle Teams arbeiten synchron.
• Die Teams sind cross-funktional zusammengestellte Feature-Teams und organisieren sich selbst.
• Der Code gehört allen Teams gemeinsam.
• Ein Build geht immer über die Ergebnisse aller Teams.
• Die Teams orientieren sich an einer gemeinsamen Definition of Done.
• Die Teams liefern am Sprint-Ende ein gemeinsames, potenziell auslieferbares Produktinkrement.

Was ist in LeSS anders als in Scrum für ein Team?

Ein wesentlicher Unterschied wird bei der Sprint-Planung sichtbar. Arbeiten mehrere Teams zusammen an einer Projektaufgabe, so wirkt sich das zwangsläufig auf die Durchführung der Sprint-Planung 1 und 2 aus.

In der Sprint-Planung 1 geht es nicht nur – wie in Scrum für ein Team – darum, festzulegen, WAS im nächsten Sprint getan werden soll. Es muss auch entschieden werden, WER – genauer welches Team – welche Einträge des Product Backlogs bearbeiten soll. An dieser Entscheidung sollte der Product Owner Vertreter aller Teams beteiligen.

Die Sprint-Planung 2 führt jedes Team anschließend für sich durch. In diesem Planungsschritt wird das WIE der Realisierung diskutiert. Dabei werden initial Designentscheidungen getroffen. Deshalb ist es häufig sinnvoll, dass sich Teams, die verwandte Themen bearbeiten, während der Sprint-Planung 2 austauschen.

Wenn man den Weg von der Verfeinerung der Backlog-Einträge bis hin zu den realisierten User Stories nachvollziehbar machen will (oder muss!), wenn man Überblick über den aktuellen Status von Epics und User Stories behalten und für alle Teams vergleichbare Metriken anwenden will, dann kann ein gemeinsames Tool für alle Beteiligten helfen.

objectiF RPM unterstützt die Arbeit mit mehreren Teams in agilen Projekten im Sinne von LeSS. Wie das funktioniert, zeige ich Ihnen jetzt:

Agile Projekte nach LeSS mit objectiF RPM – so geht‘s

Ein Product Backlog, ausgewählte User Stories für alle Teams, ein Sprint Backlog für jedes einzelne Team: Wie Sprint-Planung 1 und 2 ablaufen und objectiF RPM dabei Ordnung in die Backlog-Organisation bringt, sehen Sie in der nachfolgenden Animation. Sie zeigt das Prinzip der Projektplanung nach LeSS mit objectiF RPM.

Bevor ich Ihnen zeige, wie der Planungsprozess mit objectiF RPM in der Praxis aussieht, demonstriere ich Ihnen im nachfolgenden Video zunächst, wie einfach und schnell Sie ein neues Team in ein Projekt aufnehmen und die gesamte Arbeitsumgebung für das Team mit allen notwenigen Ordnern, Auswertungen, Dokumenten, Dashboards, Metriken und Backlogs in objectiF RPM einrichten. Das Produktivitätsgeheimnis dahinter ist die Mustertechnik des Tools.

Und jetzt Sprint-Planung 1 und 2 mit objectiF RPM:

Die Trial-Edition von objectiF RPM, die Sie hier herunterladen können, bringt alle gezeigten Features übrigens mit. Einfach mal hineinschauen.

 

Quellen:

[1] Christoph Mathis: SAFe – Das Scaled Agile Framework, dpunkt.verlag 2016

[2] Craig Larman, Bas Vodde: Large-Scale Scrum, dpunkt.verlag 2017