Agile Frameworks Übersicht: Vergleich der besten Methoden

Das Agile Framework in der Übersicht

Seit den 1970er-Jahren wurden aufgrund von Problemen traditioneller Methoden unterschiedliche Ansätze entwickelt. Ende der 1990er-Jahre wurden agile Ansätze in vielen Softwareprojekten eingesetzt und gewannen an Bedeutung. Mit der Veröffentlichung des Agile-Manifests im Jahr 2001 stieg das Bewusstsein für Agilität und sein Einfluss auf die Softwarewelt nahm enorm zu.

Nach der Veröffentlichung des Agilen Manifests im Jahr 2001 rückte der Begriff der Agilität in den Fokus vieler Unternehmen. Der Fokus liegt darauf, die Zielqualität zu erhöhen, schneller auf Änderungen zu reagieren, Vorlaufzeiten zu verkürzen, häufiger neue Produktvarianten herauszubringen und Kosten zu senken. Für kleine und mittlere Unternehmen war es einfacher, agiles Management einzuführen und zu transformieren. Scrum ist das führende agile Framework, das Unternehmen dieser Größenordnung die schnellste Transformation bietet.

Die Transformation der traditionellen Kultur in Großunternehmen war nicht einfach. Aus diesem Grund wurden neue Methoden für die agile Transformation großer Unternehmen mit dem Konzept der skalierten Agilität entwickelt. Das heute beliebteste Framework für ein skaliertes agiles Vorgehen ist SAFe (Scaled Agile Framework).

Was sind die beliebtesten agilen Frameworks?

Ein agiles Framework ist ein spezifischer Ansatz zur Planung, Verwaltung und Ausführung von Unternehmen. Agile Frameworks lassen sich im Allgemeinen in zwei Kategorien einteilen: Frameworks, die für Teams entwickelt wurden, und skalierte Frameworks, die Organisationen bzw. Unternehmen dabei helfen sollen, Agile in großem Maßstab über mehrere Teams hinweg zu implementieren.

Scrum-Framework

Scrum ist ein Framework, das seit Anfang der 1990er-Jahre zur Verwaltung des komplexen agiler Softwareentwicklungsprozesses verwendet wird. Das Konzept von Scrum ist keine Methodik oder ein Prozess, sondern ein Rahmenwerk, in dem verschiedene Prozesse und Techniken existieren. Scrum wurde von Ken Schwaber und Jeff Sutherland entwickelt und leitet sich vom Begriff Rugby ab. Beim Rugby treffen sich Spieler für kurze Zeit und tauschen Ideen aus, um über ihren nächsten Zug im Spiel zu entscheiden. Im Rugby-Spiel bildete die Selbstorganisation, Führung und Zusammenarbeit des Teams die Grundlage des Begriffs Scrum.

Um also sagen zu können, dass man Scrum anwendet, ist es notwendig, alle Schritte im Framework zu durchlaufen. Scrum basiert auf Empirie und verwendet einen inkrementellen und iterativen Ansatz. Es gibt drei Säulen, die Scrum unterstützt: Transparenz, Beobachtung und Anpassung. Die zuständigen Teams arbeiten, indem sie diesen drei Themen die Bedeutung beimessen, die sie verdienen.

• Transparenz: Die geleistete Arbeit des gesamten Teams, die zu erledigende Arbeit soll nachvollziehbar sein. Jeder sollte aus dem, was er sieht, die gleichen Schlüsse ziehen können.
• Beobachtung: Häufige Beobachtungen werden durchgeführt, um Abweichungen vom Projekt früher zu erkennen. Diese Beobachtungen werden nicht gemacht, um die Arbeit zu verlangsamen, sondern um den Wert des Produkts zu maximieren, das auf dem optimalen Niveau entstehen wird.
• Anpassung: Wenn festgestellt wird, dass das Produkt nicht die gewünschte Form hat, sollte das Produkt oder der Prozess schnell korrigiert werden. Diese Korrektur sollte so schnell wie möglich erfolgen.

Es gibt Werte, die die in Scrum geleistete Arbeit leiten und helfen, die Arbeitsethik zu definieren, die das Scrum-Team haben sollte. Diese Scrum-Werte werden wie folgt aufgelistet:

• Engagement: Scrum-Teammitglieder verpflichten sich persönlich, das Scrum-Ziel zu erreichen.
• Mut: Scrum-Teammitglieder haben den Mut, sich durch schwierige Probleme zu arbeiten und den richtigen Weg einzuschlagen.
• Fokus: Alle konzentrieren sich auf die Arbeit des Sprints und das Ziel des Scrum-Teams.
• Offenheit: Das Scrum-Team und seine Stakeholder stimmen zu, offen über die Arbeit und die Herausforderungen zu sein, denen man während der Entwicklung begegnet.
• Respekt: Scrum-Teammitglieder respektieren einander, um fähige und unabhängige Individuen zu sein.

Das Scrum-Framework besteht aus dem Scrum-Team, Rollen, Aktivitäten und Ergebnissen. Jede Komponente innerhalb des Frameworks dient einem bestimmten Zweck und ist notwendig, damit Scrum nutzbar und erfolgreich ist. Das Scrum-Team verwaltet die Beziehungen und Interaktionen zwischen ihnen, indem es Rollen, Aktivitäten und Ergebnisse verknüpft.

Obligatorische Meetings während des Scrum-Prozesses

1. Sprint Planning: In diesem Meeting werden die durch die Anforderungsliste spezifizierten Bedürfnisse vom Entwicklungsteam in kleine Fäden zerlegt. Jedes Teammitglied übernimmt diese Aufgaben nach eigenem Plan. An diesem Meeting nehmen der Product Owner, das Entwicklungsteam und der Scrum-Experte teil. Sprints: werden so geplant, dass am Ende jedes Sprints eine Präsentation an den Product Owner erfolgt. Im Durchschnitt werden Sprints im Abstand von ein bis drei Wochen durchgeführt.
2. Daily Scrum: Ist ein stehendes Meeting, das ungefähr fünfzehn Minuten dauert und jeden Tag zu einer bestimmten Zeit oberflächlich an einem vorher festgelegten und standardisierten Ort abgehalten wird. Teammitglieder nehmen direkt an diesem Meeting teil und die nächsten 24 Stunden sind geplant. Jedes Teammitglied erzählt, was es am Vortag getan hat, was es an diesem Tag tun wird und welche Probleme seine Arbeit behindern. Wenn ein Problem auftritt, bemüht sich der Scrum-Spezialist, dieses Problem zu lösen. Wenn ein Mitglied des Teams zu spät kommt oder bei der Besprechung abwesend ist, verhindert dies die Besprechung nicht. Bei fehlender Mehrheit im Team wird die Versammlung einfach abgesagt.
3. Sprint-Bewertung: Wird am Ende jedes Sprints durchgeführt und dieser Sprint wird überprüft. An dem resultierenden Arbeitsprodukt wird eine Bewertung vorgenommen. Das Ziel hier ist zu sehen, ob sich das Produkt im Einklang mit den Bedürfnissen des Eigentümers entwickelt.
4. Retrospektive Bewertung des Sprints: Hier wird bewertet, ob die während des Sprints geleisteten Arbeiten die erwartete Qualität erreichen und ob die Arbeiten korrekt ausgeführt werden. Ein prioritäres Element, das am Ende jedes Meetings identifiziert wird, wird in das nächste Sprint-Planungsmeeting aufgenommen.

Kanban

Kanban ist eine agile Methode, die in den 1950er-Jahren von Toyota eingeführt wurde. Im Softwareentwicklungsprozess wurde es erstmals 2004 von David J. Anderson mit einem Team bei Microsoft eingesetzt. Kanban konzentriert sich auf kontinuierliche Produktion und Lieferung. Kanban begrenzt die Anzahl der Jobs, an denen in jeder Phase des Softwareentwicklungsprozesses gearbeitet wird. Im Gegensatz zu Scrum hat Kanban keine bestimmte Ablaufzeit.

Die nächste Stufe wird für die Änderungen nicht erwartet und kann je nach Priorität sofort eingegriffen werden. Im Kanban gibt es keine Sonderrollen. Beim Kanban steht die Optik im Vordergrund. Der Prozess wird visualisiert und das Board mit den Arbeitspaketen mit dem Namen „Board“ ist für alle sichtbar. Kanban wird gegenüber Scrum bevorzugt, um die Anzahl der laufenden Arbeiten zu reduzieren, das Änderungsmanagement zu beschleunigen und die Visualisierung zu verbessern.

Extreme Programming (XP)

1996 wurde im Rahmen eines Projekts von Kent Beck und seinem Freund bei Chrysler die Extreme Programming-Methode entwickelt. Extreme Programming ist eine Ingenieurpraxis, die Softwareprojektteams dabei unterstützt, fehlerfreie und erfolgreiche Software zu entwickeln, wenn sich die Anforderungen ständig ändern und die Unsicherheit hoch ist. XP bietet eine einfache, aber effektive Umgebung, die es Teams ermöglicht, hochproduktiv zu sein.

Beim Extreme Programming arbeiten Manager, Kunde und Entwickler zusammen, und Projektteams können sich selbst organisieren, um Probleme so effizient wie möglich zu lösen. Das XP basiert auf 5 Grundwerten, 15 Prinzipien und 12 Praktiken.

Die Hauptmerkmale von XP

1. fortlaufende Entwicklung,
2. kontinuierliche Integration,
3. kurze Wiederholungen,
4. Veröffentlichen von Nebenversionen,
5. schnelles Feedback bekommen,
6. Kundenbeteiligung und Feedback,
7. kontinuierliche Kommunikation und Koordination,
8. Paar-Programmierung,
9. kontinuierliches Testen.

Bei XP steht das Testen im Vordergrund. Bevor die Codierung abgeschlossen ist, werden Testszenarien von den Softwareentwicklungsteams vorbereitet, die Codierung durchgeführt und dann die Tests sofort durchgeführt. Ohne Kenntnis des Testumfangs kann mit der Softwareentwicklung nicht begonnen werden.

Kunden erstellen auch geschäftsorientierte, testbare und funktionale Testszenarien für Iterationen, und die gesammelten Komponenten sind so geplant, dass sie alle diese Tests erfolgreich bestehen. Bei erfolglosen Testszenarien kann je nach Kundenwunsch aus Kosten- und Zeitgründen auf dieses Szenario verzichtet werden. In XP arbeitet der Kunde mit dem kontinuierlichen Entwicklungsteam zusammen. Dies führt zu einer starken Kommunikation, der Früherkennung von Problemen und der Aufteilung von Verantwortlichkeiten.

Vergleichende Interpretation von Agile Frameworks

	SCRUM	KAMBAN	XP
Rollendefinitionen	Scrum-Master, Produkteigentümer, Entwicklungsteam spielen eine Rolle.   Die Rolle des Projektleiters gibt es nicht.	Eine benutzerdefinierte Rollendefinition gibt es nicht.   Die Rolle des Projektleiters gibt es nicht.	Es hat eine Kunden- und eine Teamrolle.
Job-Priorisierung	Der Product Owner übernimmt die Priorisierung.	Der Kunde priorisiert.	Der Kunde priorisiert.
Hinzufügen eines neuen Jobs	Während des Sprints können keine neuen Jobs hinzugefügt werden.	Neue Jobs können laufend hinzugefügt werden.	Es kann während der Iteration hinzugefügt werden.
Zeitkonzept	Die Zeit ist durch den Sprint begrenzt.	Es gibt keinen konkreten Zeitplan.	Eine monatliche Iteration kommt mit einer wöchentlichen Iteration heraus.
Meeting	Es gibt Sprintplanung, Daily Scrum, Sprintauswertung und Sprint-Flashback-Evaluierungsmeetings.	Es finden keine vorab vereinbarten Meetings statt.	Es finden keine vorab vereinbarten Meetings statt.

Agile Frameworks nach Maß

Der Hauptzweck von skalierten agilen Ansätzen besteht darin, die Koordination zwischen Teams in Fällen sicherzustellen, in denen es mehr als ein Team gibt, die Portfolioloyalität zwischen Projekten aufrechtzuerhalten und die Agilität großer Organisationen zu skalieren. In diesen Situationen, in denen die Anzahl der Teams zunimmt und das Portfolio verwaltet werden soll, werden viele organisatorische Rollen in den verwendeten Modellen geändert und neue Rollen hinzugefügt.

Die beliebtesten skalierten agilen Frameworks sind:

SAFe (Scaled Agile Framework)

SAFe ist eine der agilen Entwicklungsmethoden, die Anleitungen zur Bewältigung der Herausforderungen bietet, die bei der Entwicklung und Bereitstellung von Großprojekten mit kürzester Vorlaufzeit auftreten. Bei Scaled Agile Framework handelt es sich um eine Reihe erprobter Praktiken, die sich auf schlanken und agilen Ansätzen stützen, um insbesondere agile Teams für größere Projekte zusammenzubringen sowie zu synchronisieren und auszurichten. Die Hauptphilosophie von SAFe ist es, Werte zu schaffen – die kostbare Zeit einer Organisation sollte nicht mit einer Anwendung oder User Story verschwendet werden, die keinen Wert schafft.

Mit der neuesten aktualisierten Version 5.1 bietet Scaled Agile Framework - SAFe vier verschiedene Konfigurationen, die unterschiedliche Unternehmensgrößen und Entwicklungsumgebungen unterstützen können.

1. Essential SAFe: Ist nicht nur die Grundlage des SAFe-Ansatzes, sondern auch der einfachste Ausgangspunkt für die Implementierung. Essential SAFe definiert die kritischen Elemente, die notwendig sind, um die meisten Vorteile des Scaled Agile Framework besser zu realisieren. Noch dazu, ist Essential SAFe der grundlegende Baustein für alle anderen SAFe-Konfigurationen. Die Team- und Programmebenen bilden die Organisationsstruktur, die als Agile Release Train (ART) bezeichnet wird, in der agile Teams, wichtige Stakeholder und andere Ressourcen einer wichtigen und fortlaufenden Lösung zugewiesen werden.
2. Large Solution SAFe: Wird verwendet für die Entwicklung sehr komplexer und problematischer Lösungen. Zudem enthält Large Solution SAFe mehrere Lieferanten sowie ARTs, jedoch nicht auf Portfolioebene. Die Lösungszugstruktur des Modells zielt darauf ab, die Lösung der Entwicklungsprobleme zu unterstützen, mit denen Organisationen konfrontiert sind, die umfangreiche multidisziplinäre Software, Hardware und komplexe Informationstechnologiesysteme entwickeln. Organisationen, die eigenständige Systeme entwickeln oder die mit einer kleinen Anzahl von implementierenden entwickelt werden können, benötigen diese Konfiguration möglicherweise nicht.
3. Portfolio SAFe: Die Konfiguration von Portfolio Scaled Agile Framework hilft bei der Harmonisierung von Portfoliomanagement und Organisationsstrategie, wobei der strategische Mehrwert berücksichtigt wird, den Entwicklungsaktivitäten bieten. Es umfasst die Personen und Prozesse, die die Systeme und Lösungen schaffen, die die Organisation benötigt, um ihre strategischen Ziele zu erreichen. Portfolio SAFe-Praktiken und -Prinzipien bieten Business Agility Framework für Portfoliostrategie, Investitionsfinanzierung, agiles Portfoliomanagement und Lean Management. In großen Unternehmen ist es möglich, mehrere SAFe-Portfoliokonfigurationen zu implementiert.
4. Full SAFe: Ist die umfassendste Version des Frameworks. Es eignet sich für Organisationen, die Hunderte von Mitarbeitern oder mehr benötigen, und ermöglicht die Entwicklung und Wartung umfangreicher integrierter Lösungen, die alle SAFe-Ebenen (Team, Programm, Lösung und Portfolio) umfassen. In sehr großen Organisationen können mehrere Instanzen unterschiedlicher SAFe-Konfigurationen erforderlich sein.

Eine weitere mit SAFe gewonnene Definition sind DevOps-Teams:

DevOps ist eine Reihe technischer Praktiken, die Kommunikation, Integration, enge Zusammenarbeit und Automatisierung ermöglichen. Abgeleitet aus der Kombination und Abkürzung der Wörter Entwicklung und Betrieb bezieht sich dieses Wort auf die harmonische und kooperative Arbeit dieser beiden Gruppen. Somit können ARTs kontinuierliche Produktionslinien effizienter betreiben.

DevOps-Teams zielen darauf ab, die Qualität und Häufigkeit von Lieferungen zu erhöhen, die Risikobereitschaft und Innovation zu verbessern, die Recyclingzeiten zu verbessern (Fehler nach der Bereitstellung auf die alte Praxis zurückzusetzen), die Häufigkeit und Schwere von Veröffentlichungsfehlern zu verringern, die Zeiten zur Fehlerbehebung zu verkürzen und Produkte zu erhalten, schneller zu vermarkten.

Die Tatsache, dass Scaled Agile Framework für groß angelegte Agilität verwendet werden kann und dass wir mehr Wissen und Erfahrung über SAFe besitzen als andere Frameworks sowie die klar definierten Rahmenprinzipien, Werte und Praktiken und das Mindestmaß an Prozesslücken im Framework wirksam sind, macht SAFe als agile Framework unschlagbar.

LeSS (Large Scale Scrum)

LeSS wurde 2008 von Craig Larman und Bas Vodde veröffentlicht und ist eine breit angelegte Version der Scrum-Technik. LeSS bietet zwei verschiedene große Scrum-Frameworks an. Die meisten Skalierungselemente von LeSS konzentrieren sich darauf, die Aufmerksamkeit aller Teams auf das gesamte Produkt und nicht auf „mein Team“ zu lenken. Für LeSS ist die „End-to-End“-Fokussierung vielleicht das wichtigste Problem, das es bei der Skalierung zu lösen gilt.

Hier sind zwei Frameworks, die Scrum skalieren, was im Grunde ein Ein-Mann-Team ist:

1. LeSS: Acht Teams (jeweils mehr als acht).
2. LeSS Huge: Bis zu mehrere Tausend Personen in einem Produkt.

Dieses Framework bietet:

• Einfachheit
• Scrum wird skaliert
• In der gewünschten Größenordnung von unten nach oben erweiterbar sein statt einer sich nach unten ausbreitenden Harmonisierung.
• Eines seiner Features ist, dass es Feature-Sets und deren Vorteile nutzt.

Zusätzlich zu Scrum hat LeSS die folgenden Details:

• Ein einzelnes Product Backlog
• Eine Done-Definition für alle Teams,
• Ein potenziell bewegliches Produktinkrement am Ende jedes Sprints,
• Ein Product Owner,
• Eine große Anzahl vollständiger, funktionaler Teams (ohne einzelne Expertenteams).

In LeSS arbeiten alle Teams in einem gemeinsamen Sprint, um in jedem Sprint ein gemeinsames auslieferbares Produkt zu liefern.

Der Unterschied zu Scrum ist:

1. Sprint-Planung Teil 1: Beinhaltet neben einem Product Owner Personen aus allen Teams. Ermöglicht es Teammitgliedern, sich selbst zu verwalten, um über die Abschnitte der Product Backlog-Elemente zu entscheiden. Die Teammitglieder besprechen auch Möglichkeiten der Zusammenarbeit bei besonders relevanten Themen.
2. Sprint-Planung Teil 2: Es wird von jedem Team unabhängig (und oft parallel) durchgeführt, aber manchmal können sich zwei oder mehr Teams im selben Raum treffen, um sich einfach zu koordinieren und zu lernen.
3. Daily Scrum: Auch von jedem Team unabhängig durchgeführt, aber die Team-A-Mitglieder erhöhen den Wissensaustausch, indem es das Daily Scrum von Team B beobachtet.
4. Koordination: Priorisiert die Kommunikation mit Sprache.
5. Allgemeine Produktlistenentwicklung: Ein optionales kurzes allgemeines Produktlistenentwicklungsmeeting kann abgehalten werden, an dem ein Product Owner und Personen aus allen Teams teilnehmen. Das Hauptziel besteht darin, zu entscheiden, welche Teams welche Elemente implementieren und diese Elemente daher für die spätere detaillierte Entwicklung von Produktlisten für einzelne Teams auszuwählen. Es ist auch eine Chance, die Abstimmung mit dem Product Owner und allen Teams zu verbessern.
6. Verfeinerung des Product Backlogs: Die einzige Anforderung in LeSS ist ein Single-Team Product Backlog wie in Single-Team Scrum. Eine übliche und nützliche Variante ist jedoch die Entwicklung einer Produktliste für mehrere Teams, bei der sich zwei oder mehr Teams im selben Raum befinden, um das Lernen und die Koordination zu verbessern.
7. Sprint Review: Umfasst zusätzlich zu einem Product Owner Personen aus allen Teams und relevanten Kunden,/Benutzern und anderen Stakeholdern.
8. Allgemeine Retrospektive: Ein neues Meeting, das nicht in Scrum enthalten ist und dessen Zweck darin besteht, die Verbesserung des Gesamtsystems zu untersuchen, anstatt sich ausschließlich darauf zu konzentrieren, wie ein Team in nachfolgenden Sprints besser abschneiden wird, indem der relevante Sprint betrachtet wird. Die maximale Sitzungsdauer beträgt 45 Minuten pro Woche. Es umfasst den Product Owner, die Scrum Master und die wiederkehrenden Vertreter jedes Teams.

SoS (Scrum of Scrums)

Es ist ein skalierter, agiler Ansatz, der 2004 von Ken Schwaber definiert wurde. Im Wesentlichen ist dieser Ansatz eine Weiterentwicklung des zuvor beschriebenen Scrum-Frameworks. Im Gegensatz dazu bezieht sich SoS sich auf die Meetings, die mit dem Upstream-Team zusätzlich zu den täglichen Meetings der normalen Scrum-Teams von SoS abgehalten werden. SoS ist ein Team, das durch Auswahl von einem oder zwei Botschaftern aus jedem Scrum-Team gebildet wird, wenn mehr als ein Scrum-Team koordinieren muss. Dieses Team trifft sich täglich, wöchentlich oder monatlich in der vom Team selbst festgelegten Häufigkeit und führt ähnliche Meetings vergleichbar wie die im Framework von Scrum beschriebenen täglichen Scrum-Meetings durch.

Die Tagesordnungspunkte der SoS-Sitzungen lauten wie folgt:

●      Was jedes Team seit dem letzten Meeting erledigt hat

●      Woran jedes Team bis zum nächsten Meeting arbeiten wird (sich verpflichten es abzuschließen).

●      Welche Risiken, Probleme, Hindernisse betreffen andere Teams?

●      Abhängigkeiten zwischen der Arbeit der Teams und ihrem aktuellen Status 

Diese Meetings vermeiden auch das Risiko, dass Teams zusätzliche (unnötige) Arbeit in gleichem Maße leisten. Die Dauer der SoS-Meetings kann weiterhin vom Team bestimmt werden. Sie wird entsprechend der Anzahl der im SoS enthaltenen Scrum-Teams angepasst. Obwohl es keine Begrenzung für die Anzahl der Teams gibt, die in den SoS aufgenommen werden sollten, hat die Praxis gezeigt, dass sich bei mehr als 10 beteiligten Teams die Besprechungszeiten verlängern und die Mitglieder sich nicht auf die Besprechung konzentrieren können.

DAD (Disciplined Agile Delivery)

DAD ist ein prozessorientiertes, lern- und lösungsorientiertes Framework, das 2007 von Scott Ambler veröffentlicht wurde. Hauptmerkmale dieses Frameworks sind:

1. Schaffung von Unternehmensbewusstsein
2. Sich auf das Lernen konzentrieren
3. Lösungsorientiert sein
4. Zuerst eine menschliche Philosophie haben
5. Eine hybride Struktur haben
6. Einen risikobewerteten Lebenszyklus haben
7. Zielorientiert sein
8. Darstellung des End-to-End-Bereitstellungslebenszyklus

Im Grunde genommen wurde dieses Framework geschaffen, um die Verfahrenslücken zu schließen, die in Scrum nicht definiert waren. Was das DAD-Framework hybrid macht, ist, dass es von vielen Methoden wie agiler Modellierung, Kanban, Edge-Programmierung, Lean-Software-Entwicklung gespeist wird. Die Rollen im DAD-Framework sind Scrum weitgehend ähnlich.

Anders als bei Scrum gibt es beim DAD Framework eine Teamleiterrolle. Die Definition der Rolle ist eine Mischung aus der Rolle des Scrum-Masters in Scrum und der Rolle des architektonischen Eigentümers in agilen Techniken. Der Teamleiter ist die Person, die die Architektur sowie den DAD-Prozess immer kennt und das Team lenkt und leitet.

Die Rollen des Product Owners und des Teammitglieds in DAD sind die gleichen wie in Scrum. Es gibt auch sekundäre Rollen in DAD, dies sind: Experte unabhängiger Tester, Domänenexperte, technischer Experte und Adapter (Integrator).

Das DAD-Framework ist ein zielorientiertes Framework. In jeder Phase von DAD werden unterschiedliche Ziele definiert. Wenn wir diese Ziele unter den Phasen von DAD auflisten, sind sie wie folgt:

Ziele der Anfangsphase

1. Erstellen des Starters/ersten Teams
2. Erstellen der Gesamtvision
3. Im Einklang mit der Unternehmensvision stehen
4. Erkundung des ersten Geltungsbereichs
5. Definieren Sie die anfängliche technische Strategie
6. Entwicklung des ersten Release-Plans
7. Mittel finden
8. Bestimmung der Arbeitsumgebung
9. Risiken erkennen

Phasenziele Aufbauen

• Generieren einer möglichen Verbrauchslösung
• Berücksichtigung der sich ändernden Bedürfnisse der Interessengruppen
• Übergang zur lieferbaren Version
• Verbesserung der Qualität

Ziele der Übergangsphase

• Die Lösung nutzbar machen
• Präsentation/Bereitstellung der Lösung 

Kontinuierliche Ziele, während DAD

• Teammitglieder füttern
• Bewältigung der Teamaufgabe
• Die bestehende Struktur nutzen (nutzen) und verbessern
• Reduzierung von Risiken
• Verbesserung der Teamprozesse und Umgebung
• Aktivitäten koordinieren

Da DAD ein lernorientiertes Framework ist, werden die Schleifen in jeder Iteration so betrieben, dass auch die Lernfähigkeiten der Teammitglieder innerhalb des DAD erhöht werden. Die People-First-Philosophie von DAD zielt darauf ab, Teammitglieder wertzuschätzen, sie wie in anderen agilen Methoden zu stärken, ihr Selbstbewusstsein zu steigern und so selbstorganisierte agile Teams mit Entscheidungsmacht zu bilden.

Scrum@Scale

Das Scrum@Scale-Framework wurde von Jeff Sutherland geschaffen, einem der Schöpfer des agilen Manifests, das die Werte und Prinzipien der agilen Denkweise darlegt. Scrum@Scale ist ein agiles Framework, das es Organisationen ermöglicht, geschäftliche Agilität zu erreichen und eine größere Wirkung zu erzielen, indem das Scrum-Framework auf Teams ausgeweitet wird. Scrum@Scale ist bestrebt, Produkte und Dienstleistungen von höchstmöglichem Wert zu liefern und gleichzeitig Teamnetzwerke über Branchen und Disziplinen hinweg bei der Bewältigung komplexer Probleme zu unterstützen.

Scrum@Scale bietet die Tools, die Unternehmen benötigen, um leistungsstarke Teams aufzubauen. Es ermöglicht ihren Teams, in einem nachhaltigen Tempo zu arbeiten und gleichzeitig einen Mehrwert für den Kunden zu schaffen. Scrum@Scale erweitert das Scrum-Framework, um branchen- und disziplinübergreifend produktive Ergebnisse zu liefern, einschließlich Software, Hardware, Services, Betrieb und F&E (Forschung und Entwicklung).

Während Scrum einen Rahmen für die Entwicklung und Wartung komplexer Produkte durch ein einzelnes Team bietet, konzentriert sich Scrum@Scale (S@S) auf das gesamte Ökosystem von Teams, um die gesamte Unternehmenskultur zu verändern. Der Scrum@Scale-Ansatz basiert darauf, ein gesundes Scrum-Team aufzubauen und Veränderungen in der gesamten Organisation positiv zu beeinflussen.

Die Grundkonzepte von Scrum@Scale

1. Kleine Teams: Kleine Teams sind nicht nur für Scrum, sondern auch für Scrum@Scale von entscheidender Bedeutung. Bei mehr als einem Team muss jedes Team aus drei bis neun Mitgliedern bestehen.
2. Skalierung im gesamten Unternehmen: Je besser die einzelnen Teams arbeiten, desto größer ist die Erfolgswahrscheinlichkeit für Scrum@Scale.
3. Umsetzung der minimal anwendbaren Bürokratie: Der minimale Zeitaufwand für das Treffen und Umsetzen von Entscheidungen hilft, Hindernisse in kurzer Zeit zu überwinden.

Die gleichen Meetings wie im Scrum-Prozess sind auch in Scrum@Scale verfügbar.

• Der Sprint
• Sprintplanung
• Skaliertes Daily Scrum
• Sprint-Review
• Retrospektive

Der einzige Unterschied zu Scrum ist hier das Scaled Daily Scrum. Wie das Daily Scrum in Scrum ist es ein tägliches Meeting, an dem ein Vertreter jedes Teams teilnehmen muss. Die Teilnahme des gesamten Teams ist nicht erforderlich. Es reicht aus, wenn jemand anwesend ist, der weiß, was in seinem Team vor sich geht.

Das Scaled Daily Scrum ist ein 15-minütiges Meeting, das die Mitglieder zusammenbringt, um Engpässe oder Probleme zu besprechen, die Teams daran hindern könnten, ihre Sprintziele zu erreichen, Wissen auszutauschen und Transparenz und Vertrauen zwischen allen Teams aufrechtzuerhalten.

Scrum@Scale-Rollen

Da Scrum@Scale auf Scrum basiert, verwendet es die Rollen des Product Owners und des Scrum Managers und sind dieselben Kompetenzen, die im Scrum Guide definiert sind. Verschiedene Verantwortlichkeiten werden in größeren Maßstäben wahrgenommen. In diesem skalierten Framework gibt es zwei Hauptrollen: den Scrum of Scrums Master (SoSM), der für den Scrum-Master-Zyklus verantwortlich ist, und den Chief Product Owner (CPO), der für den Product-Owner-Zyklus verantwortlich ist. Diese Rollen ähneln den Positionen des Product Owners und des Scrum Managers bei andere Scrum-Methoden.

• Chief Product Owner (CPO):  Der Chief Product Owner ist dafür verantwortlich, die Gesamtrichtung des Produkts zu bestimmen. Die Rolle des CPO ist der des POs sehr ähnlich, jedoch nur bis zu einem bestimmten Punkt. Diese Rolle hilft bei der Koordination der Produktion über mehrere Teams hinweg. CPOs koordinieren auch Prioritäten zwischen verschiedenen POs, die mit einzelnen Teams zusammenarbeiten. Der CPO ist dafür verantwortlich, ein einziges Backlog für alle zu erstellen. Sie arbeiten mit SoSM zusammen, um sicherzustellen, dass alle Teams auf das gleiche Ziel hinarbeiten und dass jedes Team versteht, was es tun muss.
• Scrum of Scrums Master (SoSM): Verantwortlich für die Koordination der Bemühungen mehrerer Scrum-Teams. Er fungiert in erster Linie als Bindeglied zwischen Teams und hilft dabei, auftretende Abhängigkeiten oder Konflikte zu lösen. Darüber hinaus ist SoSM dafür verantwortlich, dass jedes Team über die Ressourcen verfügt, die es benötigt. Als Scrum Master ist er für gemeinsame Freigabebemühungen und ähnliche Aufgaben verantwortlich.

Skalierung von Scrum of Scrums (SoS)

Je nach Größe der Organisation oder Anwendung sind möglicherweise mehrere SoS erforderlich, um ein sehr komplexes Produkt bereitzustellen. In solchen Fällen kann ein Scrum of Scrum of Scrums (SoSoS) unter vielen SoSs erstellt werden. Die SM-Organisation (SoS, SoSoS und EAT) arbeitet als Ganzes, um die anderen Komponenten des Scrum-Master-Zyklus zu ergänzen.

Executive Action Team (EAT)

Wenn Scrum skaliert wird, können sich organisatorische Probleme vervielfachen. In diesem Fall braucht Scrum@Scale ein Executive Action Team (EAT). Die Funktion des Executive Action Teams besteht darin, eine große Anzahl von SoS (oder SoSoSs) zu koordinieren. Dieses Team ist für die Transformationsstrategie verantwortlich und hat die Implementierung von Scrum-Werten, Rollen und Unterstützung bei der Entscheidungsfindung und Beseitigung von Barrieren. Eine wichtige Voraussetzung für EAT ist der Wille und die Macht der Top-Führungskräfte, die Organisation zu verändern.

Executive MetaScrum (EMT)

Das Executive MetaScrum Team (EMT) hat die organisatorische Vision und legt strategische Prioritäten für die Organisation fest. So wie SoSs als SoSoS wachsen können, kann MetaScrums durch den gleichen Mechanismus expandieren. Dieses Team ist dafür verantwortlich, die organisatorische Richtung zu ändern oder zu entscheiden, welche Produkte oder Dienstleistungen umstrukturiert oder eingestellt werden müssen. Es richtet das Geschäft weiter an einer Roadmap aus und kann in einem regelmäßigen oder vorübergehenden Tempo gehalten werden.

Dieses Team besteht aus Finanz-, Personal- und Kundenverpflichtungen des CPO und des Geschäftsinhabers. EMT und CPO arbeiten eng zusammen, um notwendige Änderungen in Strategie, Finanzierung oder Ressourcenallokation anzugehen.

Nexus

Das Nexus-Framework ist ein skaliertes agiles Framework, das von Ken Swabber erstellt und 2015 von Scrum.org veröffentlicht wurde. Laut dem Nexus-Leitfaden ist Nexus ein Framework, das die Arbeit von ungefähr drei bis neun Entwicklungsteams verbindet, die an einem einzigen Produkt-Backlog arbeiten, um einen integrierten Produktteil zu erstellen, der einem bestimmten Zweck dient und aus Rollen, Aktivitäten, Artefakten und den Regeln besteht.

Es wird empfohlen, maximal 9 und mindestens 3 Scrum-Teams in einem Nexus-Team zu haben. Innerhalb einer Organisation können beliebig viele Nexus-Teams aufgebaut werden, abhängig von der Größe der Organisation und der Anzahl der zu entwickelnden Produkte.

Nexus erweitert Scrum um eine neue Rolle und einige erweiterte Ereignisse und Artefakte.

Die erste der mit Nexus definierten Rollen ist das Nexus-Integrationsteam (NIT). Das Nexus-Integrationsteam befasst sich mit der Lösung aller technischen oder nicht-technischen Integrationsprobleme zwischen Scrum-Teams. Dazu gehören Probleme, Risiken, Hindernisse und Abhängigkeiten. Mitglieder dieses Teams können auch in verschiedenen Rollen innerhalb von Scrum-Teams arbeiten, sollten aber immer zuerst die Aufgaben des Integrationsteams priorisieren.

Denn jedes Problem, das das Funktionieren der Teams stören wird, ist viel wichtiger. Dieses Team besteht aus dem Product Owner, einem Scrum Master und gewählten repräsentativen Mitgliedern. Die NIT kann sich im Laufe der Zeit ändern, mit Ausnahme des Produkteigentümers.

Es gibt drei vom Nexus-Framework definierte Werke:

1. Nexus-Ziel,
2. Nexus-Sprint-Backlog und
3. integrierter Produktteil.

Das Nexus-Ziel ist ein gemeinsames Ziel für alle Nexus-Teams. Das Nexus-Sprint-Backlog ist das Ergebnis der ersten Sitzung der Nexus-Sprint-Planungsmeetings. Diese Liste ist die Summe der Arbeitselemente, zu deren Erledigung sich alle Scrum-Teams in diesem Sprint verpflichtet haben. Sie werden mit täglichen Nexus-Meetings aktualisiert. Der integrierte Produktteil ist die endgültige Ausgabe des Nexus.

Am Ende jedes Sprints muss jedes Nexus-Team ein funktionales, wertschöpfendes Produktstück produzieren, das in das Kernprodukt integriert werden kann. Der integrierte Produktteil wird den Stakeholdern beim Nexus-Sprint-Review-Meeting präsentiert, das am Ende jedes Sprints stattfindet. Von diesem Produktteil wird erwartet, dass es die Definition von „Fertig“ erfüllt.

Mit Nexus identifizierte Aktivitäten sind:

• Nexus-Sprint-Planung,
• Nexus Daily Scrum,
• Nexus-Sprint-Review und
• Nexus-Sprint-Retrospektive-Meetings.

Diese Meetings sind auch zeitlich begrenzte Ereignisse, wie im Scrum-Framework angegeben.

Die Prinzipien und Werte, die in Scrum gelten, gelten auch in Nexus. Das wichtigste Prinzip von Nexus ist, dass die Teams, ihre Funktionsweise, Arbeit und Kommunikation transparent sind. Nexus hat absolut keinen Platz für das Verstecken von Informationen, das Bemühen, Fehler unsichtbar zu machen, und undurchsichtige Verhaltensweisen wie Fehlinformationen des Kunden.

Agile Skalierung @ Spotify

Während die Entwicklungsteams von Spotify daran arbeiteten, ihre Agilität zu steigern, teilten sie ihre Erfahrungen und ihr Wissen. Jetzt inspirieren deren dokumentierten Praktiken, bekannt als das Spotify-Modell, viele Softwareunternehmen, ihre Arbeit besser zu strukturieren.

Das Spotify-Modell ist ein auf den Menschen ausgerichteter, autonomer Ansatz zur Skalierung von Agilität, der die Bedeutung von Kultur und Netzwerken betont. Dieses Modell hat Spotify und anderen Organisationen dabei geholfen, Innovation und Produktivität voranzutreiben, wobei der Schwerpunkt auf Autonomie, Kommunikation, Verantwortlichkeit und Qualität lag.

Spotify Squad

Die grundlegende Entwicklungseinheit bei Spotify ist Squad. Squad ist ähnlich wie das Scrum-Team aufgebaut. Dieses Team, das Design-, Entwicklungs- und Testaktivitäten gemeinsam durchführt, sind selbstorganisierte Teams (8 oder weniger Mitglieder), die agile Frameworks verwenden, einige davon Scrum, andere Kanban oder eine Mischung aus beidem. Nicht jeder Squad hat einen offiziell ernannten Teamleiter. Allerdings gibt es einen Product Owner.

Diese Struktur erhöht die Autonomie, was die Menschen glücklicher macht, da sie eine starke Quelle der Motivation ist. Darüber hinaus ist die Struktur in Squads schnell, da Genehmigungssysteme, Entscheidungsengpässe an der Spitze und Abhängigkeiten von anderen Teams vermieden werden. Der Product Owner ist dafür verantwortlich, die zu erledigende Arbeit zu priorisieren. Wie die Arbeit erledigt wird, steht nicht in seiner Verantwortung. Ein Team kann auch Zugang zu einem agilen Coach haben, der ihm hilft, seine Arbeitsweise zu entwickeln und zu verbessern. Spotify hat den Scrum Master in Scrum in “Agile Coach“ umbenannt. Coaches halten Retrospektiven, Sprint-Planungsmeetings und Einzelcoachings ab.

Spotify Tribe

Eine andere Struktur in Spotify wird durch Tribes ausgedrückt. Es gibt einen Tribes Leader, der dafür verantwortlich ist, diesen Strukturen, die durch das Zusammenkommen mehrerer Squads gebildet werden, den bestmöglichen Lebensraum zu bieten. Tribes sind so konzipiert, dass sie kleiner als 100 Personen sind. Ein Tribe besteht aus Squad-Gruppen, die in verwandten Bereichen wie der Backend-Systeminfrastruktur arbeiten.

Chapter- und Guild-Rollen sind auch auf Spotify verfügbar. Ein Chapter ist definiert als eine kleine Familie von Menschen desselben Tribes mit ähnlichen Fähigkeiten und der gleichen Besonderheit (das ist der Kitt, der das Unternehmen zusammenhält). Jedes Chapter trifft sich regelmäßig, um spezifische Probleme im Zusammenhang mit seinem Fachgebiet zu besprechen. Zum Beispiel Chapter Testingenieure, Chapter Webentwickler oder Chapter Backend.

Das Guild ist eine „Interessengruppe“, die sich aus Menschen zusammensetzt, die Wissen, Werkzeuge, Codes und Praktiken organischer und mit größerer Beteiligung teilen möchten. Guilds umfassen normalerweise die gesamte Organisation, während Chapters immer eine Gruppe innerhalb des Gebietsschemas des Tribes sind. Einige Beispiele für Guilds sind: Web Technology Guild, Test Engineers Guild, Agile Coaches Guild usw. tatsächlich ist Spotify eine Art Matrixorganisation.

Spotify System Owner

Das Risiko dieses Modells besteht darin, dass die Infrastruktur des Systems zusammenbricht, wenn sich niemand auf die Integration des Systems als Ganzes konzentriert. Um dies zu verhindern, kommt eine weitere Rolle „System Owner“ ins Spiel. Alle Systeme haben einen oder zwei Systembesitzer. Der Systembesitzer ist die Person(en), die bei technischen oder architektonischen Problemen im Zusammenhang mit dem System kontaktiert werden. Diese Person ist der Koordinator und leitet diejenigen, die die Codes auf dem System entwickeln. Der System Owner konzentriert sich unter anderem auf Themen wie Qualität, Dokumentation, technische Schulden, Stabilität, Skalierbarkeit und den Rollout-Prozess.

Fazit

Zusammenfassend lässt sich sagen, dass es viele verschiedene agile Frameworks gibt, die je nach Situation und Anforderungen eingesetzt werden können. Jedes Framework hat seine eigenen Vor- und Nachteile, und es ist wichtig, das passende Framework für das eigene Projekt und Team auszuwählen.

Wenn du mehr darüber erfahren möchtest, welche agilen Frameworks es gibt und wie sie im Projektmanagement eingesetzt werden können, empfehlen wir dir unsere "Scaled Agile Framework"-Seite. Hier findest du verschiedene SAFe-Kurse, darunter auch unseren "Leading SAFe"-Kurs, der dir die Grundlagen von Agilität und SAFe vermittelt und dich auf die entsprechenden SAFe-Zertifizierungen vorbereitet.

Und wenn du auch dein Wissen und deine Fähigkeiten in anderen IT-Bereichen erweitern möchtest, schau doch mal auf unserer "Academy"-Seite vorbei. Dort findest du eine Vielzahl an Schulungen und Zertifizierungen zu verschiedenen IT-Themen, darunter auch agile Methoden. Wir freuen uns darauf, dir dabei zu helfen, deine Karriereziele zu erreichen!

 

---

Referenzen

• Scrum.org. (n.d.). Scrum. https://www.scrum.org/

• Scrum.org. (2020). Das Scrum Guide. https://scrumguides.org/scrum-guide.html

• Scrum Inc. (n.d.). Scrum Inc. https://www.scruminc.com/

• Scaled Agile, Inc. (n.d.). Scaled Agile Framework. https://www.scaledagileframework.com/

• Scaled Agile, Inc. (2023). Skalierung von Agile [Webseite]. https://scaledagile.com/

• Kanban University. (n.d.). Kanban Leitfaden. https://kanban.university/kanban-guide/

• Extreme Programming. (n.d.). Extreme Programming. http://www.extremeprogramming.org/

• Large-Scale Scrum (LeSS). (n.d.). Large-Scale Scrum (LeSS). https://less.works/

• Agilest. (n.d.). Agilest. https://www.agilest.org/

• Agile Modeling. (n.d.). Agile Modeling. http://agilemodeling.com/

• OpenXcell. (2019, 19. Februar). Disciplined Agile Delivery - Ein umfassender Leitfaden. https://www.openxcell.com/blog/disciplined-agile-delivery/

• Methods & Tools. (2014, 1. März). Einführung in Agile-Methoden [Webseite]. https://www.methodsandtools.com/archive/archive.php?id=104

• Scrum@Scale. (n.d.). Scrum@Scale. https://www.scrumatscale.com/

• Scrum.org. (n.d.). Der Online Nexus Guide. https://www.scrum.org/resources/online-nexus-guide

• Spotify. (2012, 21. November). Engineering-Kultur [Blog-Post]. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf