LeSS Einführung – Teil 3: Wie skaliert man Scrum

Scrum skalieren

Ein weiterer methodischer Reflexionsschritt in LeSS ist die Frage, wie eine Skalierung von Scrum zur Organisation eines erhöhten Entwicklungsaufwand sinnvoll bewerkstelligt werden kann – was macht (single-team) Scrum wirklich aus? Der offizielle Scrum Guide ist sicher eine hilfreiche Ausgangsbasis und die empirischen Erfahrungswerte sind hier von Ken Schwaber [Schwaber/Beedle: Agile Software Development with Scrum, 2001] beigetragen worden. Die zentrale Organisationseinheit in Scrum ist das Team mit seiner Fähigkeit, alle Arbeitsschritte im Produktentwicklungszyklus von der Erstellung der Backlog Items in einer Feedback-loop mit den Anwendern des Produktes bis hin zur Auslieferung des Produktinkrements (PSPI) im Team selbst abzubilden.

LeSS ist nun der Versuch, die Prinzipien von Scrum als solche zu skalieren und weniger die Praktiken: “LeSS ist weder neues noch verbessertes Scrum. Und es geht auch nicht um Scrum auf Team-Ebene mit etwas darauf gesetzt. Vielmehr geht es darum, wie die Prinzipien, der Zweck, die Elemente und die Eleganz von Scrum im skalierten Kontext so einfach wie möglich angewendet werden können… Richtig skaliertes Scrum ist Scrum skaliert.” [less.works] Mit anderen Worten geht es darum, die Vorteile, die Scrum im Kleinen bietet, im größeren Kontext zu bewahren.

Bemerkenswert ist zunächst, dass LeSS eine organisatorische Skalierung etwa im Sinne der eigenen Daseinsberechtigung keineswegs begrüßt, sondern es wird, ganz im Gegenteil, dazu geraten, so wenig wie möglich zu skalieren. So zeigen die von LeSS vorgetragenen Erfahrungsmodelle, dass ein Team aus wenigen exzellenten Produktentwicklern effektivere Ergebnisse erzielen kann als etwa drei Teams mit “mittelmässigen” Entwicklern. Bevor skaliert wird sollte daher stets durch deep critical thinking betrachtet werden, inwieweit eine Skalierung vermieden werden kann.

LeSS bietet einen Multi-Team-Ansatz mit bis zu acht Teams an. Es werden jedoch gegenüber Scrum keine weiteren Rollen oder Organisationseinheiten eingeführt, abgesehen von der Overall Retrospective.

Beispielhaft für diese Skalierung der Scrum Prinzipien von innen heraus sei hier das Product Backlog angeführt. Ebenso wie Scrum ein einzelnes Backlog vorsieht, setzt LeSS zwingend voraus, dass die Singularität der möglichst weit gefassten Produktdefinition sich in einem singulären Backlog manifestiert, an dem alle Teams gemeinsamen arbeiten. Dies ermöglicht die Gesamtpriorisierung ebenso wie die Skalierung der höchstpriorisierten Themen über die Teams hinweg.

Ebenso ist etwa die Rolle des Scrum Masters und das Verhältnis zu seinem Team von Scrum übernommen. Der erfahrene und versierte Scrum Master führt seine ein bis drei Teams von der Selbstorganisation über die Selbstverwaltung (self management) bis hin zur  Selbstführung (self leading). Sein Tätigkeitsschwerpunkt verschiebt sich in Richtung Coaching von Entwicklungstechniken sowie das Treiben von Verbesserung auf Ebene der Organisation.

Verschiebung des Fokus des Scrum Masters (less.works)

Edit