Agile / Software-Test / Testmanagement

Scaling Agile – Welcher Ansatz passt zu mir?

Große Unternehmen stehen oft vor dem Problem, agile Methoden einzuführen. Warum? Agile Methoden und Praktiken sind für relativ kleine Teams entwickelt worden und lassen sich nicht ohne weiteres im großen Maßstab unternehmensweit einsetzen. Deshalb haben sich in den letzten Jahren verschiedene Frameworks entwickelt, die Unternehmen dabei unterstützen sollen, agile Vorgehen unternehmensweit anzuwenden. Um den Nebel um diese Frameworks zu lichten, nehmen wir die bekanntesten von ihnen unter die Lupe.

vintage-waage_blog

Kleine, selbstorganisierte Teams, wenig Dokumentation, schnelle Zyklen und direkte Einbindung des Kunden – was im Kleinen funktioniert, kann im großen Maßstab im Chaos enden. Und die Auswirkungen, wenn ein agiles Experiment unternehmensweit fehlschlägt, sind gravierender, als das Scheitern eines – kleinen – Projektes.

Verteilte Teams und mangelnde Kommunikation, nicht erkannte Abhängigkeiten, keinerlei Dokumentation, gleiche Aufgaben werden in unterschiedlichen Teams bearbeitet … Beim (Up-)scaling der agilen Methoden auf Unternehmensebene versucht man, über die Koordination sowohl der Teams als auch der Aufgaben, den Überblick zu bewahren. Die bekanntesten Methoden, die Unternehmen dabei unterstützen sollen, sind Scrum of Scrums, Scaled Agile Framework, Large Scale Scrum und Disciplined Agile Delivery. Im Folgenden stelle ich ihnen die verschiedenen Ansätze vor.

 

SoS – SCRUM of SCRUMS

Die einfachste Methode: SCRUM für größere Projekte und sogar Programme zu skalieren. Wenn ein SCRUM Team zu groß wird (die Empfehlung liegt bei mehr als 12 Teammitgliedern), werden die Personen auf Teams von 5 bis 10 Mitgliedern verteilt. Nach dem teaminternen Daily SCRUM entsendet jedes Team einen Botschafter, der am Scrum of Scrums- Meeting teilnimmt. Wer dabei der Botschafter ist, kann abhängig von den der Agenda des Scrum of Scrums-Meeting im Daily Scrum entschieden werden.

Jeder einzelne Botschafter beantwortet im SoS im einfachsten Fall die gleichen Fragen wie im Daily Scrum:

  • Was habe ich/haben wir seit dem letzten Daily Scrum/SoS getan?
  • Was plane ich/planen wir, bis zum nächsten Daily Scrum/SoS zu tun?
  • Was hat mich/uns bei der Arbeit behindert (Impediments)?

Für Scrum of Scrum Teams macht es allerdings Sinn, die Fragen anzupassen:

  • Welche Risiken, Hindernisse oder Abhängigkeiten hat Ihr Team seit dem letzten Treffen bearbeitet?
  • Welche Risiken, Hindernisse oder Abhängigkeiten wird Ihr Team bis zum nächsten Treffen weiterbearbeiten?
  • Gibt es neue Risiken, Hindernisse oder Abhängigkeiten, die Ihr Team behindern?
  • Gibt es ein neues Risiko, Hindernis oder eine Abhängigkeit, die sich auf die anderen Teams auswirken wird?

Das Scrum of Scrums-Meeting führt dabei einen eigenen Backlog.

Sprint Planning und Retrospektive sollen ebenfalls auf Scrum of Scrums-Ebene erfolgen. So können Themen geclustert und an die jeweiligen (Spezialisten-)Teams übergeben werden.

Der Nachteil ist, dass Scrum of Scrums ebenfalls sehr von den beteiligten Personen und ihrer Einstellung und Methodenkenntnis abhängt und eine Kontrolle nur schwer möglich ist.

 

SAFe – Scaled Agile Framework

Dean Leffinwell´s „Scaled Agile Framework“ oder kurz SAFe beschreitet einen strukturierteren Weg als das Scrum of Scrums. Leffinwell bezieht sich dabei auf vier Ebenen – Portfolio, Programm und Team und seit SAFe 4.0 einer optionalen vierten „Value Stream“-Ebene – und beschreibt detailliert, was zu tun ist. Auf der Portfolio-Ebene wird über strategische Themen, an denen gearbeitet werden soll, entschieden und Portfolio-Epics erstellt. Diese werden an das entsprechende Programm übergeben. Auf der Programm-Ebene werden die Portfolio-Epics verfeinert und in einzelne Features aufgeteilt, die den Teams zugewiesen werden. Ein Programm besteht dabei aus 5 bis 10 Teams mit insgesamt 50 bis 125 Personen die einen „Agile Release Train“ bilden, der alle zwei Wochen eine funktionierende, lauffähige Software liefert. Die Teams arbeiten mit verschiedenen Methoden aus z.B. Scrum und XP.

Die Gefahr bei SAFe ist allerdings, dass die einzelnen Regeln und Punkte unreflektiert und ohne, dass sie verstanden werden, zur Anwendung kommen. Die daraus entstehende Komplexität und der entstandene Methoden-Mix stehen im Gegensatz zu den ursprünglichen Absichten und verhindern unter Umständen die gewünschten Vorzüge des agilen Vorgehens. Auch der One-Size-Fits-All Anspruch von SAFe ist ein Kritikpunkt, da es nicht auf unterschiedliche Rahmenbedingungen eingeht. Vielen Autoren bestreiten zudem, dass SAFe selbst Agil ist, da es den Schwerpunkt auf die Prozesse setzt und genaue Vorgaben trifft. Doch scheint es für Unternehmen, die aus dem klassischen Projektumfeld kommen genau durch diese Struktur und Vorgaben ein praktikabler Weg zu sein, sich Richtung agil zu entwickeln – wenn gleichzeitig das agile Mindset mitentwickelt wird.

 

LeSS – Large Scale SCRUM

„Large-scale Scrum is regular Scrum applied to large-scale development.“ Large Scale Scrum macht nichts anderes, als die normalen Scrum-Vorgaben hoch zu skalieren. Insofern ähnelt es dem Scrum of Scrums mit zusätzlichen Koordinations-Meetings und einem Overall Product Backlog. Laut Craig Larman, dem Miterfinder von LeSS ging es ursprünglich darum, unnötige Komplexität zu vermeiden. Auch aus diesem Grund werden bei LeSS zwei Frameworks angeboten:

  • das reguläre LeSS für bis zu acht Teams (mit je acht Teammitgliedern)
  • LeSS Huge für mehrere Tausend Personen, die an einem Produkt arbeiten.

LeSS Huge baut dabei auf dem regulären LeSS auf und erweitert es um ein paar Regeln. Ein Beispiel ist, dass sich jedes Team auf einen bestimmten Themenbereich spezialisieren soll, wobei ein Themenbereich 4 bis zu 8 Teams haben sollte.

Die offiziellen Regeln für beide Frameworks passen dabei auf drei A4-Seiten, sind also sehr überschaubar und leicht erlernbar. Aber sie lassen auch viele Freiheiten und somit Gelegenheiten, Fehler zu machen – vor allem, wenn die Grundprinzipien nicht verstanden wurden. Auch hier ist das agile Mindset Voraussetzung für den erfolgreichen Wandel.

 

DaD – Disciplined Agile Delivery

Viele Scrumritter (in Anlehnung an die Kreuzritter, die ihren Glauben auf das bitterste verteidigten) werden beim Disciplined Agile Delivery Framework zuerst schlucken müssen, wurde es doch von Scott Ambler unter der Ägide von IBM entwickelt und bedient sich zusätzlich verschiedener Methoden aus dem Unified Prozess.

DaD versucht bereits vor Scrum und Sprint 0 anzusetzen. Dazu berücksichtigt das Framework Entscheidungen über die anzuwendende Programmiersprache, die Architektur und Plattform, sowie welche Tools zum Einsatz kommen. Der Anspruch, den die Entwickler von DaD erheben, ist, dass eine end-to-end Strategie geliefert wird, die von der Initiierung des Projekts bis hin zu Wartung und Betrieb reicht.

Dazu unterscheidet DaD 3 Phasen

  • Inception Phase
  • Construction Phase
  • Transition Phase

mit jeweiligen Phasenzielen sowie phasenübergreifende Ziele.

DaD bedient sich bei Methoden aus Scrum, Extreme Programming (XP), Agile Modeling (AM), Unified Process (UP), Kanban und Agile Data (AD), ändert aber häufig die Bezeichnungen. So wird etwa aus dem Scrum Master der Team Lead.

DaD ist taktisch auf Team-Ebene und strategisch über das gesamte Unternehmen skalierbar.

Kritikpunkte aus der Praxis finden sich bisher wenige, da die Anwendung durch unabhängige Experten bisher nicht aussagekräftig genug ist. Im Vergleich zu LeSS gibt es mehr Vorgaben und ähnlich wie SAFe setzt DaD auf einen Methodenmix, der allerdings nicht unreflektiert und ohne Verständnis der dahinterliegenden Prinzipien übernommen werden sollte.

 

Evidence Based Management und Enterprise Transition Framework

Zwei weitere Modelle, Evidence Based Management (früher Agility Path) und Enterprise Transition Framework (ETF) liefern im Gegensatz zu den bisher genannten Frameworks keine Struktur. Sie geben den Prozess vor, wie man agiler wird – auch auf Unternehmensebene. Beide sind sich ähnlich, stammen allerdings von scrum.org und von agile24, die Scrum Alliance- Zertifizierungen anbieten.

 

Eigene Ansätze finden

Ein Nachteil aller Methoden (bis auf Scrum of Scrums) ist, dass sie eingetragene Marken sind und die Zertifizierungen und somit auch die Coaches entsprechend kosten.

Und dennoch gilt für alle diese Ansätze: Man muss die Prinzipien hinter den Agilen Methoden verstanden haben und das richtige Mindset entwickeln. Ein erfahrener agiler Coach, der das Unternehmen durch den Änderungsprozess begleitet und die oben genannten Frameworks an die Rahmenbedingungen anpasst, sollte immer mit an Bord geholt werden. Ob dabei starre und klar strukturierte Vorgaben aus SAFe und damit aus dem Produktmanagement oder die Team-Autonomie und Selbstorganisation bei LeSS bevorzugt wird, muss das Unternehmen selbst entscheiden. Aber mit Hausverstand.

Passende Artikel

Antwort schreiben

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

*