22.12.2016  Verfasst von Patrick Daut in Agile Methoden Agile Transformation  

LeSS in Kürze

Ansätze zur Skalierung von Agile: Large-Scale Scrum

Agile Skalierungsframeworks erfreuen sich steigender Bekanntheit und Anwendung. Noch immer kommen neue Ansätze auf den Markt der Methoden. Allein diese Dynamik zeigt den Bedarf, agile Methoden auch in großen Organisationen, in Konzernen, im klassischen Umfeld und in regulierten Märkten einsetzen zu können. Eines bekanntesten Frameworks ist das von Craid Larman und Bas Vodde entwickelte Large-Scale Scrum (http://less.works, kurz LeSS).

LeSS ist ein Framework für die agile Produktentwicklung – mit einer klaren Ausrichtung auf Softwareentwicklung.Bei diesem Ansatz ist der Versuch deutlich zu erkennen, möglichst auf komplexe Prozessdefinitionen und Rollenmodelle zu verzichten.

Fokus
So kann man LeSS beschreiben als ein erweitertes Scrum – erweitert um einzelne Elemente und Mechanismen, die eine Skalierung ermöglichen: „Large Scale Scrum is Scrum“ .

Charakteristisch ist zunächst ein einfacher, weitgehend auf Scrum basierenden Ablauf pro Team mit einzelnen Koordinationsmechanismen zwischen den Teams wie Scrum-of-Scrum oder teamübergreifenden Retrospektiven.

Merkmale und Lösungsideen

  • Erweiterung von Scrum um einzelne Elemente und Koordinationsmechanismen
  • Verringerung des Koordinationsbedarfs zwischen Teams durch einen Zuschnitt in „Feature Teams“, die möglichst unabhängig voneinander agieren können
  • Es wird versucht, Overhead und unnötige Komplexität im Framework durch eine zweistufige Definition zu erreichen:
    LeSS reichert Scrum um einzelne Elemente an, empfohlen für bis zu 8 Entwicklungsteams. Beispiele für solche Elemente sind ein Team aus Product Ownern, Scrum-of-Scrum oder teamübergreifende Retrospektiven.
    LeSS Huge für mehr als 8 Teams definiert darüber hinaus eine hierarchische Organisationsstruktur
  • Bei der vorgeschlagenen Organisationsstruktur handelt es sich um eine Hierarchie aus Product Ownern, wobei der Verantwortungsbereich eines Product Owners auf tieferen Hierachie-Ebenen kleiner wird. Hier werden nun Rollen definiert: die Entwicklungsleitung, der Chief Product Owner, mehrere Area Product Owner und schließlich Product Owner
  • Die Idee einer „Area“ beschreibt einen Teil eines Produkts entlang fachlicher und/oder architektonischer Zerlegung
    Die Zerlegung soll Komplexität und Abhängigkeiten minimieren – anstatt sie zu managen.
  • Zeitliche Synchronisierung der Teams – während inhaltlich Unabhängigkeit zwischen diesen angestrebt wird
  • Abstimmung von Querschnittsthemen über Teams hinweg durch Communities of Practice
    Stetige Lieferfähigkeit von Produktinkrementen als Basis für eine empirische Bewertung dieser Inkremente, die Grundlage für die Steuerung ist
  • Technische Qualität und Flexibilität: „Organizational Agility is constrained by Technical Agility“
  • Aktiv getriebene Weiterentwicklung, aktive Community. Inzwischen weist das Framework den Charakter eines Produkts auf. Trainings werden angeboten.

Prinzipien und Werte

  • Large-Scale Scrum is Scrum
  • Guidance durch Prinzipien, weniger detaillierte Prozesse und Praktiken
  • Fokus auf das ganze Produkt
  • Der Kunde im Mittelpunkt
  • Continuous Improvement
  • Empirical Process Control als Kernprinzip in Scrum: Messen und adaptieren

Theoretisches Fundament

  • Lean Thinking
  • Systems Thinking
  • Queuing Theory
  • Agile, insb. Scrum

Wann setze ich es ein?
Stehen Sie aktuell vor der Herausforderung einer wachsenden agilen Entwicklungsorganisation? Ist die Koordination zwischen Ihren selbstorganisierenden Teams kein Selbstläufer mehr? Oder haben Sie Scrum in einem großen Unternehmen beginnend mit einigen Teams eingeführt und planen nun einen weiteren Rollout?
In diesen Fällen sind agile Skalierungsframeworks einen Blick wert – doch ist LeSS das Richtige für Ihre Situation?
Sie planen die Einführung agiler Vorgehensweisen in einem großen Unternehmen? Oder arbeiten Sie bereits agil mit einigen Entwicklungsteams, wachsen weiter und fragen sich, ob einfache Mechanismen und adhoc-Kommunikation den steigenden Koordinationsbedarf zwischen selbstorganisierten Teams decken? Stehen sie vor der Frage, ob LeSS für Sie die benötigten Lösungen mitbringt?
Nach meiner Erfahrung spielt LeSS seine Stärken bei einer mittleren Unternehmensgröße und mittleren Produktkomplexität aus. Hinsichtlich der Größe der Entwicklungsorganisation sehe ich den idealen Einsatz bei kleiner bis mittlerer Teamanzahl bis hin zu mehreren Dutzend Teams, während darüber hinaus andere Alternativen  Vorteile bieten.
Der „schlanke“ Ansatz hinter LeSS – die Idee der Erweiterung von Scrum um einzelne Elemente und der Einführung einer eigenen Organisationsstruktur erst bei steigender Teamanzahl – kann den Koordinationsbedarf zwischen mehreren Teams decken und hält dennoch den Overhead gering. Eine Hierarchie aus Chief Product Owner, Area Product Owner sowie Product Owner auf Teamebene wird jedoch ab einer gewissen Größenordnung an Grenzen stoßen: Der Kommunikations- und Koordinationsbedarf wird in dieser Struktur stark ansteigen. Interessant ist dies beispielsweise für eine gerade wachsende Organisation.
Dabei lassen sich in einem Ansatz basierend auf LeSS alle Funktionen gut abbilden, die sich in crossfunktionale Teams integrieren lassen: Entwickler, Ingenieure, Qualitätsmanager und Designer. Für die Integration sog. „cross-cutting concerns“ wie die Sicherstellung der Einhaltung regulatorischer Anforderungen an Produkt oder Prozess bietet das Framework selbst kaum Lösungen.

Entscheidend für den erfolgreichen Einsatz ist der Zuschnitt in möglichst voneinander unabhängige Teams, um den Koordinationsbedarf zwischen ihnen gering zu halten. Dies ist einfacher möglich, wenn das entwickelte Produkt in seiner Struktur die unabhängige Entwicklung einzelner Produktteile erlaubt: Eine fachliche und funktionale Trennung in möglichst unabhängige Teilprodukte wird hier schon den Großteil des Koordinationsbedarfs zwischen den Teams decken können.
Komplexe und gewachsene Produkte jedoch bieten diese Möglichkeit meist nicht: Fachliche Abhängigkeiten bestehen und LeSS unterstützt deren Handhabung kaum.
Dennoch: Der Aufbau des Frameworks um das weit verbreitete Scrum als Kern bietet Vorteile in einem wachsenden Projekt: Man baut auf einer möglicherweise schon gelebten Methode auf und erweitert diese – immer nur soweit wie nötig.
Grundsätzlich muss der Einsatz eines Skalierungsframeworks situativ entschieden werden. Für die beschriebenen Bedingungen bietet LeSS Lösungen bei vergleichsweise geringer Komplexität und geringen Overhead. Es lohnt sich aber auch immer ein Blick auf die Eignung anderer Frameworks. Über Alternativlosigkeit können wir uns seit einigen Jahren nicht beschweren.

In der Praxis zeigen sich hohe Ausprägungen insbesondere der folgenden Einflussfaktoren als wesentlich für den Einsatz von SAFe:

  • Größe der Entwicklungsorganisation
  • Produktkomplexität
  • Hohe architektonische Kopplungsdichte der Lösungen
  • Komplexität in Branche und Markt bspw. durch regulatorische oder Compliance-Vorgaben.

Tendenziell zielt SAFe auf große Organisationen und eine Produktentwicklung mit einer Größe von 12 oder mehr Entwicklungsteams zuzüglich angrenzender Rollen. Das Modell über drei oder gar vier Ebenen bringt ein Portfoliomanagement für die Einlastung mehrerer Produkte oder Projekte auf die bestehenden Ressourcen mit. Entscheidender: Seine Programm-Ebene bietet Lösungen zur Koordination vieler Entwicklungsteams, die gemeinsam an einem Produkt arbeiten. Die im Framework detailliert definierten Rollen und deren Zusammenspiel geben der Organisation Mittel an die Hand, auch in Branchen mit beispielsweise hohen regulatorischen Anforderungen an Prozess oder Produkt Nutzen aus agilen Methoden zu ziehen.
Einen anderen entscheidenden Aspekt konnte ich vielfach in der Begleitung agiler Transformationen beobachten: Verfügt eine große Organisation über wenig Erfahrung mit agilen Methoden, kann sie sich mit der Einführung über ein Framework mit sehr konkreten Rollen und Abläufen – praktisch als Hilfsmittel – deutlich leichter tun. Wir können dies analog schon bei einzelnen Teams feststellen: Scrum bietet einem Team anfangs mehr Orientierung als beispielsweise Kanban. Sind die zugrundeliegenden Ideen und Konzepte verinnerlicht und werden sie gelebt, kann das umgebende „Gerüst“ durchaus verschlankt werden.
Dennoch: SAFe stellt längst nicht für jede Organisation das Mittel der Wahl dar. Der vergleichsweise hohe Overhead für Koordination und Planung verliert seine Wirksamkeit bei der Entwicklung zeitkritischer und stark veränderlicher Produktentwicklung. Wie eingangs erwähnt bietet der Markt inzwischen eine ganze Reihe an Alternativen für verschiedene Anwendungsbereiche. Ein Framework zur Skalierung von Agilität kann nur als Methodik verstanden werden, deren Einsatz situativ entschieden werden muss.

Literatur

  • Larman, Craig; Vodde, Bas: Large-Scale Scrum: More with Less. Addison-Wesley, 2016.
  • Larman, Craig; Vodde, Bas: Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010.
  • Larman, Craig; Vodde, Bas: Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley, 2008.

Mehr zum Thema

Der Autor

Patrick Daut
Senior Consultant