Agile Methoden in der Softwareentwicklung: 6 Modelle im Vergleich

Einleitung

Agilität ist in der Softwarebranche längst mehr als ein schnelllebiger Trend. Die meisten Teams kennen und schätzen die Vorteile agilen Arbeitens: Flexibilität, Kundenorientierung, Kosten- und Qualitätskontrolle, Transparenz und regelmäßige Outputs.  Agil ist jedoch nicht gleich agil. Eine Vielzahl verschiedener Methoden versteht Agilität zum Teil sehr unterschiedlich. Welches Modell ist das richtige für welches Team? Dieser Blogartikel vergleicht sechs der bekanntesten Frameworks und erklärt, für welche Arbeitsumfelder sie besonders gut geeignet sind. 

Die Vorteile agilen Arbeitens

Warum sollten Softwareteams auf agile Methoden setzen? Agilität zeichnet sich durch eine Reihe an Grundsätzen und Funktionsweisen aus, die den Teams einige Vorteile bieten:

• Flache Hierarchien: Agile Teams organisieren sich in der Regel selbst.
• Teaminterne Kooperation: Besonders wichtig sind eine direkte und offene Kommunikation sowie Transparenz über alle Entwicklungsstände hinweg.
• Ein hohes Maß an Flexibilität: Agile Methoden können schnell auf sich verändernde Kundenwünsche reagieren.
• Empirische Anwendung als Grundlage: Die Abläufe sind nicht von Anfang an perfekt, sondern werden in einem stetigen Lern- und Weiterentwicklungsprozess verbessert.
• Arbeiten in Iterationen: Entwicklerteams erstellen zunächst eine funktionierende Grundversion des Codes und wiederholen den immer gleichen Prozess bis zum gewünschten Ergebnis.
• Ein inkrementeller Ansatz: Das Software-Produkt entsteht nicht nach dem Wasserfall-Prinzip, sondern Schritt für Schritt.

6 agile Methoden im Vergleich

Scrum

Scrum ist die wohl bekannteste agile Methode. Sie zeichnet sich vor allem durch eine empirische Prozesssteuerung, regelmäßige Iterationen und eine inkrementelle Arbeitsweise aus. Da Softwareentwicklung komplex und oft unvorhersehbar ist, müssen agile Teams ihre Prozesse regelmäßig prüfen und anpassen. Testverfahren werden in den Prozess implementiert und der gesamte Ablauf somit kontinuierlich verbessert. Das Team entwickelt Softwareprodukte in zwei- bis vierwöchigen Zyklen, den sogenannten Sprints. Wiederkehrende Termine strukturieren den Sprint: das Planning, tägliche Meetings (Daily) und eine Endreview. In einer Retrospektive zieht das Team zudem Bilanz, um den nächsten Sprint zu optimieren.

Scrum sieht drei verschiedene Rollen vor: Der Product Owner erstellt auf der Basis der Kundenerwartungen eine sogenannte User Story, die die Vision und Richtung des Projektes abbildet. Diese abstrakte User Story wird daraufhin auf technische Aufgaben heruntergebrochen. Das Entwicklungsteam arbeitet diese Aufgaben in den jeweiligen Sprints ab. Der Scrum Manager koordiniert währenddessen die Zusammenarbeit und ist dafür verantwortlich, den Prozess kontinuierlich zu verbessern.

Dank der kurzen Entwicklungszyklen ist Scrum ideal für Projekte, die weder vollständig planbar noch vorhersehbar sind. Zudem lassen sich externe Stakeholder einfach einbeziehen. Allerdings eignet sich Scrum vor allem für kleine Teams, die autonom arbeiten können.

Kanban

Anders als Scrum folgt Kanban keinem festen Kodex. Vor allem Flexibilität und Anpassungsfähigkeit für verschiedene Arbeitsumfelder stehen bei Kanban im Fokus. Es baut auf bestehenden Workflows auf und zielt darauf ab, diese zu verbessern. Gerade wenn in einem Team noch keine agilen Techniken zum Einsatz kommen, hilft Kanban, diese langsam zu implementieren. Im Mittelpunkt dieser Methode steht die Visualisierung von Prozessen. Das wichtigstes Werkzeug hierfür ist das Kanban-Board. Das Team hält die verschiedenen Aufgaben eines Projektes auf Karten fest und verschiebt sie – je nach Arbeitsstand – zwischen mehreren Spalten des Boards. Klassischerweise gibt es drei bis vier Spalten: „das Backlog“ (unerledigte Aufgaben), „in Arbeit“, gegebenenfalls „Tests“ und „erledigt“. Innerhalb dieser Spalten priorisiert das Team die Aufgaben zusätzlich.

Die Entwickler ziehen sich ihre Aufgaben nach dem Pull-Prinzip in die nächste Spalte und müssen nicht darauf warten, dass sie ihnen zugewiesen werden. Sogenannte Work-in-Progress-Limits (kurz WiP-Limits) legen fest, wie viele Aufgaben pro Spalte bzw. Prozessphase bearbeitet werden dürfen. Das verhindert, dass das Team zu viele Aufgaben gleichzeitig anfängt und es zu Wartezeiten kommt.

Ursprünglich stammt Kanban aus der japanischen Autoindustrie, ist aber inzwischen auf die Softwareentwicklung angepasst. Die Methode eignet sich sowohl für Einzelpersonen und Teams als auch für die Organisationsebene. Kanban ist dank seiner Flexibilität zudem dann zu empfehlen, wenn sich die Prioritäten von Aufgaben während des Prozesses verändern.

Scrumban

Wie der Name schon verrät, mischt Scrumban Elemente der beiden Modelle Scrum und Kanban. Scrumban setzt Agilität allerdings nicht als feste Methode um, sondern überlässt es jedem Team, Aspekte von Scrum und Kanban frei zu kombinieren. In der Regel enthält ein Scrumban-Prozess aber die regelmäßigen Iterationen, Sprints und Daily Meetings von Scrum. Von Kanban übernimmt die Methode die Visualisierung anhand eines Boards – in diesem Fall das Scrumban Board –, das Backlog, die WiP-Limits und das Pull-Prinzip. Dieses Framework bietet den eindeutigen Vorteil, dass es langfristige Planung zulässt (Bucket-Size-Planning) und dennoch keine konkreten Ziele oder Deadlines benötigt. Zudem löst sich Scrumban von dem werte- und prozessgebundenen Korsett von Scrum. Es ist wie Kanban flexibel und kommt ohne Hierarchien aus. Scrumban garantiert sozusagen einen geregelten Ablauf ohne zu viele Regeln. Generell ist die Methode sinnvoll, wenn ein Team bereits mit Elementen von Scrum oder Kanban arbeitet.

LeSS (Large Scale Scrum)

Large Scale Scrum (kurz: LeSS) versucht, eine andere Schwachstelle von Scrum zu umgehen. Während Scrum in der Regel auf Teamebene angewandt wird, weitet LeSS das Prinzip für mehrere Teams aus, die gemeinsam an einem Produkt arbeiten. LeSS existiert in zwei verschiedenen Modellen: Basic LeSS eignet sich für zwei bis acht Teams mit insgesamt zehn bis 50 Mitarbeitern. LeSS Huge kann Projekte mit mehr als acht Teams und insgesamt 50 bis 6000+ Personen organisieren. An sich funktioniert LeSS ähnlich wie Scrum. Allerdings arbeiten die Entwicklungsteams – hier Feature-Teams genannt – selbstständiger und enger mit den Kunden zusammen. LeSS Huge kennt zudem die Rolle des Area Product Owners, der sich auf bestimmte Aspekte des Produktes konzentriert. Zudem erweitert LeSS die Sprint-Planung um ein sogenanntes Product Backlog Refinement (PBR), das parallele Sprints mehrerer Teams koordiniert.

Trotz des großen Anwendungskontexts möchte LeSS vor allem Ressourcen sparen und Komplexität reduzieren. Die Prozesse müssen demnach nicht nur agil, sondern auch wirtschaftlich sein. LeSS einzuführen, lohnt sich besonders dann, wenn die einzelnen Teams bereits Scrum nutzen. Beliebte Anwendungsbereiche sind Trading Systeme, Telekommunikation, Investment, Privatkunden-Banking, Video-Konferenztools und Online-Gaming.

SAFe (Scaled Agile Framework)

Anders als die bisherigen Modelle ist SAFe kein Framework. Es funktioniert stattdessen wie eine Wissenssammlung mit strukturierten Leitlinien zu Rollen, Zuständigkeiten, Planung, Aufgaben und Werten des agilen Arbeitens. Ähnlich wie LeSS skaliert es agiles Arbeiten für größere Projekt-Zusammenhänge und behält die allgemeinen Business-Ziele eines Softwareunternehmens im Blick. Gleichzeitig bleibt es auch für einzelne Teams und die Langzeitplanung mehrerer Projekte einsetzbar.

SAFe basiert auf fünf Grundelementen: integrierte Qualitätssicherung, Transparenz, einem Fokus auf der Programmumsetzung, einer starken Unternehmensführung sowie der Abstimmung, Planung und Reflexion in festen Rhythmen. Der große Planungsaufwand und das Top-Down-Prinzip werfen allerdings die Frage auf, ob SAFe wirklich eine agile Methode ist.

DAD (Disciplined Agile Delivery)

Bei Disciplined Agile Delivery (DAD) handelt es sich um einen hybriden Ansatz, der ähnlich wie SAFe Praktiken verschiedener agiler Methoden kombiniert. Als Bottom-up-Ansatz ist DAD im Vergleich zu SAFe allerdings weniger hierarchisch und planungsintensiv. Es konzentriert sich vor allem auf die Verbesserung, Flexibilität und Anpassbarkeit von Prozessen. Anders als die meisten agilen Frameworks legt DAD nicht nur einen Fokus auf die Entwicklung von Software im Unternehmen, sondern kümmert sich zudem um die Initiierungs- und die Transitionsphase. In der Initiierungsphase bespricht und plant das Unternehmen das Projekt mit seinem Kunden. Während der Transitionsphase, stellt es die fertige Software-Lösung bereit. DAD legt entsprechend großen Wert darauf, externe Akteure in den Arbeitsprozess einbeziehen zu können.

Als hybrider Ansatz kennt DAD sechs verschiedene Modelle, die je nach den Bedürfnissen und Zielen der Kunden auf anderen Methoden beruhen. Soll der Prozess besonders agil sein, bildet Scrum die Basis. Muss er besonders schlank sein, stehen Aspekte von Kanban im Fokus. Wenn das Anwendungsfeld undefiniert ist, kann DAD mit einem explorativen Stil an ein Projekt herangehen: Die Planung fällt hier minimalistisch aus und die Entwicklungszyklen bleiben kurz. Auch Prozesse, die mit CI/CD-Pipelines und DevOps-Kulturen kombiniert werden sollen, kann DAD organisieren. DAD ist letztlich als Toolbox und weniger als geschlossene Methode zu verstehen. Entsprechend ist das Framework sehr breit anwendbar. Allerdings sollte das Team bereits gewisse Erfahrungen mit agilem Arbeiten mitbringen. DAD ist besonders dann empfehlenswert, wenn große Teams und viele externe Stakeholder zusammenarbeiten.

Fazit

Agiles Arbeiten begünstigt nicht nur die Flexibilität in Entwicklungsprozessen, sondern ist auch selbst sehr flexibel. Es vereint viele Grundsätze und Funktionsweisen, die nicht für jedes Softwareunternehmen gleichermaßen relevant sein müssen. Soll ein Prozess möglichst flexibel, anpassbar und hierarchiearm sein, sind Kanban, Scrumban und DAD geeignete Methoden. Benötigt ein Team hingegen eine genauere Planung und eine feste Führung, sollte es auf SAFe zurückgreifen. Auch der Zeithorizont spielt eine Rolle: Ein schlecht vorhersehbares Projekt sollte am besten mit Scrum organisiert werden, während längerfristige Planung mit Scrumban besser gelingt. Die Größe des Teams ist ein ebenso wichtiges Kriterium: Für kleine Teams ist Scrum interessant; große Projekte brauchen Frameworks wie LeSS oder SAFe. DAD kann hingegen alle Projekt-Ebenen und Kontexte abdecken. Wenn die empirische Prozessverbesserung im Fokus steht, sollten Projektteams auf Scrum oder DAD setzen. Beide Methoden erlauben es zudem, sich stark an Kundenwünschen zu orientieren und externe Stakeholder zu integrieren. Steht die Wirtschaftlichkeit von Prozessen im Fokus, können LeSS und SAFe punkten. Eine übersichtliche Visualisierung lässt sich hingegen am besten mit Kanban erreichen.



Die beste Methode, um agiles Arbeiten umzusetzen, gibt es folglich nicht. Die Wahl des richtigen Frameworks hängt vielmehr von den Bedürfnissen eines jeden Entwicklungsteams ab.

Wenn Sie Ihren Workflow auf agiles Arbeiten umstellen wollen und nach einer passenden Methode für Ihr Software-Unternehmen suchen, unterstützen wir von ARINNAU Sie gerne dabei. Unsere Qualitätsexperten beraten Sie unverbindlich und professionell.