Agile Frameworks: Die beliebtesten Vorgehensmodelle in der Praxis

Agile Frameworks sind in der Softwareentwicklung zu einem unverzichtbaren Instrument geworden. Als Leitfäden für Unternehmen und Teams sorgen sie dafür, dass qualitativ hochwertige Produkte schneller und effizienter auf den Markt gelangen. Viele denken beim Thema Agilität sofort an Scrum, doch in der Praxis gibt es noch viele weitere Vorgehensmodelle.

Von Kanban über von SAFe bis DA: Jedes agile Framework hat seine Daseinsberechtigung, mit eigenen Stärken und Besonderheiten. In diesem Artikel erhalten Sie einen umfassenden Überblick über die beliebtesten agilen Frameworks, deren Besonderheiten sowie Vor- und Nachteile.

Was ist der Unterschied zwischen agilen Methoden und agilen Frameworks? Weil die Begriffe häufig synonym verwendet werden, möchten wir zu Beginn eine Abgrenzung vornehmen.

Scrum wird oft als agile Methode bezeichnet, was in der Praxis zwar nicht falsch, genaugenommen aber nicht richtig ausgedrückt ist. Es handelt sich um ein agiles Framework, das agile Methoden wie Planning Poker integrieren kann.

Alle agilen Frameworks haben gemeinsam, dass sie flexibel und anpassungsfähig sind und in einem dynamischen Umfeld bestehen können. Sie arbeiten nach dem agilen Manifest und überzeugen mit kundenzentrierten Ansätzen.

Jedes agile Framework birgt unterschiedliche Stärken und Schwächen. Im Folgenden stellen wir Ihnen die wichtigsten Eigenschaften einiger gängiger Vorgehensmodelle und deren Vor- und Nachteile kurz vor:

Scrum ist eines der bekanntesten agilen Frameworks. Der „Scrum Guide“ bietet Teams und Unternehmen eine Anleitung für die Implementierung agiler Arbeitsweisen und für die inkrementelle Softwareentwicklung.

Sie möchten mehr zu Scrum erfahren? Unser Ratgeber bietet weiterführende Informationen:

Ein Kanban Board lässt sich als agile Methode oft mit anderen Frameworks verbinden. Beim Kanban-Board handelt es sich um eine Projekttafel, die in mehrere Spalten organisiert ist, die verschiedene Phasen eines Prozesses darstellen. Typischerweise gibt es primär drei Spalten: „Offen“, „In Arbeit“ und „Erledigt“:

Kanban ist aber nicht nur eine Methode, sondern kann auch als eigenes Framework stehen und sowohl im agilen, als auch im klassischen Umfeld Einsatz finden.

Wer Kanban als Framework einsetzt, wird auch mit Begriffen wie WIP-Limits und dem Pull-Prinzip konfrontiert werden. Alles, was Sie dazu wissen müssen, erklären wir hier:

Scrumban vereint verschiedene Aspekte aus Scrum und Kanban. Es nutzt Aspekte beider Frameworks – beispielsweise regelmäßige Projektmeetings wie bei Scrum und WIP-Limits wie bei Kanban – um eine schlanke und agile Projektsteuerung zu ermöglichen.

Mehr zu Scrumban lesen Sie hier:

XP ist ein agiles Framework, das in erster Linie auf eine schnelle Reaktionsfähigkeit auf sich ändernde Kundenanforderungen abzielt. Die Ursprünge des Frameworks gehen auf Kent Beck zurück, der für Softwareentwicklungs-Projekte eine Qualitätssicherung sicherstellen wollte.

Der Name lässt schon erahnen, dass dieses Vorgehensmodell extrem ist – extrem agil. Das Framework kommt mit fünf Leitwerten daher:

Es gibt darüber hinaus einige Regeln und Prinzipien, welche die Prozesse von XP verfeinern sollen. Dazu gehört, dass man sich bei der Planung bereits Gedanken macht, ob XP anwendbar ist.

Zu den eigentlichen Methoden gehören dann unter anderem das Pair-Programming und die testgesteuerte Entwicklung, bei der man jederzeit auf Änderungen und Fehler reagieren kann.

Sogar Kunden-Tests sind vorgesehen, damit das Team die Qualität der Software gewährleisten kann und sicherstellt, die Anforderungen zu erfüllen. Sie müssen auch strenge Zyklen einhalten, die eine schnelle inkrementellen Fertigung und die Abstimmungsprozesse sicherstellen.

Das von Alistair Cockburn entwickelte Framework ist vordergründig für seine Flexibilität und Anpassungsfähigkeit an verschiedene Projektgrößen und Komplexitäten bekannt. Genau genommen ist Crystal jedoch nicht ein einzelnes Framework, sondern eine Familie von Varianten mit agilen Methoden. Diese lassen sich jeweils an spezifische Anforderungen und Bedingungen eines bestimmten Projekts anpassen.

Die wichtigsten Prinzipien der Crystal-Methode sind direkte Kommunikation, inkrementelle Entwicklung, ständige Verbesserung und Anpassungsfähigkeit. Dabei stehen Menschen und Teams im Fokus. Die jeweils zu wählende Variante hängt von der Höhe des Projektrisikos sowie der Teamgröße ab.

Je größer das Projekt und das Risiko, desto mehr Rollen und Steuerungsmechanismen trägt die Variante in sich. Während es bei der Variante Crystal Clear völlig ausreicht, dass die Entwickler gegenseitig die Ergebnisse testen, sollen Teams ab Crystal Orange einen externen Entwickler an Bord holen.

Jeff De Luca entwickelte dieses Framework um 1997 und legte damit einen Fokus auf die Entwicklung von Features. Jedes einzelne Feature generiert einen Mehrwert für den Kunden und lässt sich durch Feature-Pläne iterativ umsetzen.

Vereinfacht lässt sich FDD in fünf Prozessschritten abbilden:

FDD bringt aber auch einen Baukasten mit unterschiedlichen agilen Methoden, Rollen und Strukturen mit sich, die eine schnelle Umsetzung und eine schnelle Lieferung der Inkremente ermöglichen.

Design Thinking fördert die Zusammenarbeit und Interdisziplinarität, da es Teams ermutigt, aus unterschiedlichen Perspektiven zu denken und Silodenken zu durchbrechen. Deshalb birgt es das Potenzial, traditionelle Denkmuster hinter sich zu lassen und innovative Lösungen für komplexe Probleme hervorzubringen.

Viele verstehen es in der Praxis als agile Methode, genau genommen handelt es sich jedoch um ein Framework mit iterativem Prozess. Dieser bezieht die Nutzer mit ein, um Herausforderungen aus ihrer Perspektive zu verstehen und Lösungsansätze zu entwickeln, die auf ihre Bedürfnisse und Wünsche abgestimmt sind.

David Kelley hat hierzu den bekannten Design-Thinking-Prozess entwickelt, der sich aus fünf Phasen zusammensetzt:

Viele unterschiedliche Branchen setzen auf das Design Thinking-Framework – sowohl zur Problemlösung als auch für die Entwicklung von Produkten, Prozessen oder Rollen.

DSDM ist eines der ersten agilen Frameworks, das seine Geburtsstunde im Jahr 1994 hatte. Es unterliegt acht Prinzipien, die den Prozess und die Entscheidungsfindung leiten. Dazu gehören unter anderem der Fokus auf das Geschäftsbedürfnis, die kollaborative Arbeit und die iterative Entwicklung.

Im Herzen des Vorgehensmodells steht der iterative und inkrementelle Ansatz. Dieser erlaubt es, den Projektverlauf flexibel zu gestalten und schnell auf veränderte Anforderungen zu reagieren, während das Team acht grundlegende Phasen durchläuft:

Scrum gehört zu den am häufigsten verwendeten Frameworks. Doch wenn ein Projekt oder ein Unternehmen wächst, kann Scrum mit seiner begrenzten Teamgröße schnell an seine Grenzen kommen.

In der Praxis haben sich daher entsprechende Frameworks etabliert, die Scrum auf unterschiedliche Art und Weise skalieren und das Arbeiten in größeren Teams ermöglichen. Einige bewährte Ansätze stellen wir Ihnen im Folgenden kurz vor.

SAFe ist ein umfangreiches Framework, das darauf abzielt, agile Praktiken auf Unternehmensebene zu skalieren. Es kommt insbesondere dann zum Einsatz, wenn eine Organisation bereits mit Scrum arbeitet und nun nach einem Framework sucht, das mitwächst.

SAFe bietet ein Set von Organisations- und Arbeitsabläufen, die dazu dienen, ein koordiniertes und synchronisiertes Arbeiten mehrerer agiler Teams zu ermöglichen. Die einzelnen Teams werden dabei in einem sogenannten „Agile Release Train“ (ART) zusammengeführt. Dieses kann insgesamt aus 50–125 Personen bestehen. Jedes Team hat, wie in Scrum üblich, einen Scrum Master und einen Product Owner, während nun drei neue Rollen hinzukommen.

Wenn Ihnen das immer noch nicht groß genug ist, können Sie weiter skalieren und auf einen Solution Train setzen, bei dem bis zu 1.000 Personen zusammenkommen können. Jeder Solution Train besteht dabei aus mehreren ARTs.

Die Strukturen und Prozesse, wie etwa die feste Dauer der Product Increments und das dazu notwendige, aber aufwendige PI-Planning, machen SAFe zu einem komplexen Vorgehensmodell. Damit die Umsetzung in der Praxis gelingt, stellt die Organisation eine Implementierungs-Roadmap zur Verfügung. Andernfalls wüssten viele Organisationen nicht, wie sie dies umsetzen sollen.

Scrum wird für ihre Organisation zu klein? Dann haben Sie mit LeSS ein weiteres Framework zur Auswahl, mit dem Sie Agilität skalieren können.

Dabei geht LeSS nach dem „LeSS is more“ Prinzip vor, baut Hierarchien ab und versucht die Steuerung sowie Rollen so einfach wie möglich zu halten. Es eignet sich für Organisationen mit mehreren Teams, die an einem gemeinsamen Produkt arbeiten. Wie bei SAFe stehen Ihnen unterschiedliche Skalierungsoptionen offen: LeSS und LeSS Huge.

LeSS ist für zwei bis acht Teams konzipiert und beinhaltet grundlegende Scrum-Prinzipien, die sich auf eine größere Gruppe anwenden lassen. Der Unterschied zu Scrum? Ein Product Owner ist für mehrere Scrum Teams verantwortlich, die Scrum Teams selbst haben entweder jeweils einen eigenen Scrum Master oder ein Scrum Master betreut bis zu drei Teams.

LeSS Huge hingegen ist für mehr als acht Teams gedacht.

Um die unterschiedlichen Themenbereiche effizient zu managen, baut das Vorgehensmodell eine weitere Hierarchie ein: Die Area Product Owners (APOs) vermitteln zwischen den Teams und dem PO und sind bestimmten Teams oder Bereichen zugeordnet.

Nexus ist ein weiteres Framework, das dabei hilft, die Herausforderungen bei der Skalierung von Scrum-Ansätzen zu bewältigen. Das Konzept, das von Ken Schwaber und seinem Scrum.org-Team entwickelt wurde, konzentriert sich auf die Entdeckung und Handhabung der Abhängigkeiten zwischen den Teams, um die Auslieferung und Integration zu verbessern.

Es erweitert den Scrum-Prozess um neue Rollen und Ereignisse, die über die des einzelnen Scrum-Teams hinausgehen. Diese sollen die Zusammenarbeit und Kommunikation zwischen den Teams verbessern. Nexus ist für die Verwendung mit drei bis neun Scrum-Teams konzipiert, wobei es sich weiterhin stark an den Scrum-Prinzipien und -Praktiken orientiert und danach strebt, die Komplexität so gering wie möglich zu halten.

Die Scrum Teams besitzen jeweils einen Scrum Master und bilden in der Gesamtheit ein Nexus. Diesem ist ein Nexus Integration Team (NIT) zugeordnet, welches einen Product Owner, einen Scrum Master und einige Teammitglieder besitzt.

Das NIT hat die Aufgabe, Abhängigkeiten zu identifizieren und zu lösen, sowie zur Steuerung beizutragen und Rahmenbedingungen für Nexus zu schaffen.

Ferner gibt es weitere Nexus-Events wie ein Daily, ein Planning und die Retrospektive. Sollten mehr als neun Teams zusammenarbeiten, gibt es eine weitere Skalierungsform, das Nexus+. Dafür gibt es jedoch keine konkrete Roadmap für die Praxis.

Am nächsten Modell wird deutlich, wie sehr Methoden und Frameworks in der Praxis verschwimmen. Denn auch in unsere Liste hat sich ein Modell eingeschlichen, das im eigentlichen Sinne kein Framework darstellt. Disciplined Agile (DA) gibt nämlich keinen Leitfaden für die Umsetzung eines bestimmten Vorgehens, sondern bietet eine Art Methoden-Baukasten, aus dem sich Unternehmen bedienen können, um agil zu skalieren.

Es wurde von Scott Ambler und Mark Lines von IBM entwickelt und ist ein hybrider Ansatz, der Scrum, agile Modellierung, Lean Software Development und weitere Konzepte in ein Gesamtkonzept gießt. In der Praxis verstehen Teams dieses als Prozessentscheidungs-Framework.

DA betont die Wichtigkeit eines durchdachten, geplanten Vorgehens. Es erkennt aber auch an, dass jede Organisation einzigartig ist und entsprechend eine eigene Strategie benötigt. DA daher eine Sammlung von Best Practices und Lifecycles an, sogenannte „Ways of Working“ (WOW) aus denen Unternehmen sich etwas zusammenstellen können. Ganz nach dem Motto „Choose your own Way of Work“.

Das Spotify-Modell ist ein agiles Framework, das Kreativität und Effizienz in großen Organisationen fördern kann. Das Framework stammt vom Musik-Streaming-Anbieter Spotify und zeichnet sich durch mehrere Strukturen und Rollen aus.

Durch die Förderung der Autonomie und Eigenverantwortung der Squads ermutigt das Spotify-Modell die Teams, kreativ zu denken und innovative Lösungen zu entwickeln. Organisationen können dadurch schnell und effizient auf Veränderungen reagieren.

Scrum@Scale wurde von Jeff Sutherland, dem Mitbegründer von Scrum, entwickelt. Es dient dem Ziel, Scrum in großen Unternehmen einfach zu skalieren – auf allen Ebenen.

Bis zu fünf Scrum-Teams können sich zu einem übergeordneten Team, dem Scrum of Scrum (SoS), zusammentun. Zusätzlich zu den bereits bestehenden Rollen kommen zwei weitere hinzu: der Scrum of Scrum Master (SoSM) und der Chief Product Owner (CPO). Neue Abstimmungstermine und Prozesse sorgen für gute Kommunikation unter den Teams.

Wenn die Teams weiter wachsen und mehr als 25 Scrum-Teams existieren, greift die nächste Stufe der Skalierung.

Der Product Owner-Zyklus, der sich mit dem „Was“ des Projektes beschäftigt, mündet in einem Executive Meta Scrum Team (EMS). Der Scrum Master Zyklus, der sich hingegen mit dem „Wie“ beschäftigt, mündet in einem Executive Action Team (EAT).

Das übergeordnete Konstrukt ist auch als SoSoS (Scrum of Scrum of Scrums) bekannt. Zugegeben – ein Zungenbrecher, den man in der Praxis eher nicht ausspricht, der sich aber beliebig skalieren lässt.

Sie sehen, es steht Ihnen eine große Vielfalt an Frameworks zur Verfügung. Aber welches ist nun das Richtige für Sie? Die Antwort hängt stark von den individuellen Bedürfnissen und Zielen Ihres Unternehmens ab.

Berücksichtigen Sie bei der Auswahl unter anderem folgende Aspekte:

Scrum und Kanban lassen sich etwa gut auch außerhalb der Softwareentwicklung einsetzen. Bei großen Unternehmen kann das Spotify-Modell zuverlässig funktionieren, wenn Sie Kreativität und Autonomie fördern möchten. Scrum@Scale ist hingegen für Unternehmen geeignet, die bereits mit Scrum vertraut sind und dies auf Unternehmensebene skalieren möchten.

Wenn Sie sich unsicher sind, können Sie sich auch von Experten beraten lassen, die mit verschiedenen Vorgehensmodellen vertraut sind. Ein Agile Coach kann Sie beispielsweise dabei unterstützen, Agilität im Unternehmen zu implementieren oder zu skalieren.

Agilität ist mittlerweile nicht mehr nur ein Schlagwort in der IT. Es gibt Vorgehensmodelle für viele unterschiedliche Branchen und Unternehmensgrößen, die die Prinzipien der Agilität nutzen, um schnelle Anpassungsfähigkeit an Veränderungen, effizientere Prozesse und höhere Mitarbeiterzufriedenheit zu fördern.

Die Wahl des richtigen agilen Skalierungsmodells hängt jedoch immer von den spezifischen Anforderungen und Zielen Ihres Unternehmens ab. Jedes Modell hat seine Stärken und kann daher in einem bestimmten Kontext besonders nützlich sein. Bedenken Sie jedoch, dass Agilität kein Allheilmittel, sondern ein Werkzeug ist, das – richtig eingesetzt – Ihr Unternehmen auf dem Weg zu mehr Effizienz und Innovation unterstützen kann.