Agile Entwicklungsmethoden wie Scrum und Kanban existieren bereits seit mehreren Jahrzehnten und haben sich in der Praxis bewährt. In diesem Blogbeitrag erklären wir, wie es dazu kam und wie sich die Denkweise von klassischen Entwicklungsprozessen unterscheidet. Ausserdem zeigen wir, wo Scrum und Kanban eingesetzt werden können und wie Continuous Delivery der Schlüssel zum Erfolg agiler Projektabwicklung ist.
Ein wenig Geschichte
Das Wasserfallmodell ist eine der ersten Softwareentwicklungsmethoden und taucht bereits 1970 in einem Dokument von Dr. Winston W. Royce auf, auch wenn das Wort "Wasserfall" erst später in diesem Zusammenhang erwähnt wird. Das Modell wurde für die Entwicklung grosser Softwaresysteme konzipiert und definiert mehrere Phasen, die nacheinander abgearbeitet werden. Tritt in einer Phase ein Fehler auf, muss zu dem Schritt zurückgekehrt werden, der den Fehler verursacht hat. Dr. Winston W. Royce erkannte schon damals, dass dies ein Problem darstellt und schrieb, "In der Tat ist der Entwicklungsprozess zum Ursprung zurückgekehrt, und man kann mit einer Überschreitung des Zeitplans und/oder der Kosten um bis zu 100% rechnen."
Die agile Entwicklung versucht genau dieses Problem zu lösen, indem kleinere Iterationen das Risiko und die Auswirkungen von Fehlern verringern. Der Begriff "agil" wurde im Zusammenhang mit Softwareentwicklung erstmals im Jahr 2001 im "Manifesto for Agile Software Development" erwähnt, obwohl iterative Vorgehensmodelle schon früher verwendet wurden. Das Manifest betont die Bedeutung der Bereitstellung funktionierender Software in kurzen Iterationen, kontinuierliches Kundenfeedback und die Förderung kollaborativer, selbstorganisierter Teams. Dabei werden unterschiedliche Prioritäten gesetzt.
Menschen und Interaktionen vor Prozessen und Tools
Funktionierende Software vor vollständiger Dokumentation
Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen
Reagieren auf Veränderungen vor Befolgen eines Plans
Neu ist immer besser! Oder doch nicht?
Das Wasserfallmodell ist auch heute noch weit verbreitet. Der Übergang von klassischen Vorgehensmodellen zu agilen Methoden erfordert eine Veränderung der Denkweise und der Organisationsstruktur. Darüber hinaus gibt es verschiedene Faktoren, die ein klassisches sequentielles Vorgehen erfordern. Dies kann beispielsweise der Fall sein, wenn zu Projektbeginn alle Anforderungen klar definiert sind oder wenn regulatorische Anforderungen dies erfordern.
Das eiserne Dreieck
Das eiserne Dreieck zeigt deutlich die Unterschiede in der Denkweise zwischen klassischen und agilen Methoden. Es stellt die wechselseitigen Beziehungen zwischen Umfang, Zeit und Kosten in einem Projekt dar.
Bei einem Wasserfallmodell ist der Umfang in der Regel vorgegeben. Es ist jedoch schwierig, die Kosten oder den Liefertermin im Voraus zu bestimmen. Bei der agilen Entwicklung hingegen sind die Kosten und die Iteration als Zeitrahmen vorgegeben. Der Umfang kann jedoch variabel sein.
Das eiserne Dreieck hat aber auch seine Tücken. Zum Beispiel kann der Eindruck entstehen, dass mehr Ressourcen automatisch zu mehr Umfang oder kürzeren Entwicklungszeiten führen. Die Auswirkungen sind jedoch nicht immer linear und können sogar negativ sein.
Es ist auch eine Illusion zu glauben, dass alle drei Faktoren kontrolliert werden können. In der Regel können maximal zwei Faktoren beeinflusst werden, der dritte bleibt variabel.
Hybride Modelle
Es gibt auch hybride Ansätze, die das klassische Vorgehensmodell mit agilen Methoden kombinieren. Einerseits gibt es Modelle, die übergeordnete Prozesse definieren, wie beispielsweise das Scaled Agile Framework (SAFe). Zum anderen gibt es Methoden, welche die Phasen des Wasserfallmodells in die einzelnen Iterationen integrieren oder zusätzliche Meilensteine für mehrere Iterationen definieren.
Grundsätzlich handelt es sich bei den Vorgehensmodellen und Methoden um Rahmenwerke, die an die eigenen Bedürfnisse angepasst werden können. Dabei dürfen die Prinzipien der jeweiligen Entwicklungsmethode nicht verletzt werden.
Agile Methoden
Scrum und Kanban sind die am weitesten verbreiteten agilen Methoden. Wir zeigen, wie sie aufgebaut sind und welche Vor- und Nachteile sie haben.
Scrum
Scrum ist ein agiles Framework für die Softwareentwicklung, das die Zusammenarbeit in einem selbstorganisierten Team fördert und feste Rollen und Zeitfenster definiert.
Rollen
Der Product Owner ist "die Stimme des Kunden" und verantwortlich für das Product Backlog sowie für die Klärung mit den Stakeholdern und die Priorisierung der Aufgaben.
Der Scrum Master ist als "dienender Leiter" für die korrekte Durchführung von Scrum verantwortlich. Er unterstützt das Team bei der Problemlösung und beseitigt mögliche Hindernisse.
Das Team ist für die Zuweisung und Durchführung der Aufgaben sowie für die Lieferung des Produktinkrements am Ende jedes Sprints verantwortlich.
Sprints
Projekte werden in Sprints von 1 bis 6 Wochen organisiert. Am Ende jedes Sprints steht ein potenziell auslieferbares Produktinkrement.
Backlog
Das "Product Backlog" ist eine Sammlung von Anforderungen, Funktionalitäten, Verbesserungen und Fehlerbehebungen, die vom Product Owner verwaltet und priorisiert werden.
Meetings
Zu Beginn jeder Iteration wird ein Sprint Planning durchgeführt. Dabei nimmt das Team die Aufgaben aus dem Product Backlog auf, die im aktuellen Sprint umgesetzt werden sollen.
Während des Sprints findet täglich das Daily Scrum statt, bei dem sich das Team über den Fortschritt, die Herausforderungen und den Plan für den aktuellen Tag austauscht.
Am Ende jedes Sprints präsentiert das Entwicklungsteam dem Product Owner und den Stakeholdern im Sprint Review das fertiggestellte Produktinkrement.
Nach dem Sprint Review findet die Retrospektive statt, in der das Entwicklungsteam gemeinsam mit dem Scrum Master Verbesserungsvorschläge für die nächste Iteration definiert.
Das Time-Boxing ist bei allen Meetings sehr wichtig. Jede Sitzung hat einen festen Zeitrahmen, der nicht überschritten werden darf.
Kanban
Kanban ist eine agile Projektmanagementmethode, die eine kontinuierliche Lieferung anstrebt. Es gibt keine festen Strukturen oder Iterationen. Stattdessen werden neue Arbeitspakete in Angriff genommen, sobald Kapazitäten frei werden. Dadurch ist jederzeit ersichtlich, wo sich die Arbeitspakete im Entwicklungsprozess befinden und ob diese blockiert sind. Eine Aufgabe soll so schnell wie möglich abgearbeitet und geliefert werden, um den "Work in Progress" so gering wie möglich zu halten.
Board
Das Kanban-Board visualisiert den gesamten Arbeitsablauf und gliedert ihn in einzelne Phasen. Die Phasen können frei gewählt werden. In der ersten Phase befinden sich in der Regel die noch zu erledigenden Aufgaben. Die Arbeitspakete wandern von links nach rechts über das Board, bis sie abgeschlossen sind. Für jede Phase können Qualitätsstandards definiert werden, die eingehalten werden müssen.
WIP (Work in Progress)
Kanban verfolgt das Ziel, begonnene Arbeitspakete so schnell wie möglich abzuschließen, um einen kontinuierlichen Arbeitsfluss zu gewährleisten. Deshalb wird für jede Phase eine maximale Anzahl von Arbeitspaketen definiert, die nicht überschritten werden darf. Dadurch wird verhindert, dass das Team überlastet wird und neue Arbeiten begonnen werden, ohne dass die bestehenden abgeschlossen sind.
Scrum vs. Kanban
Es ist immer einfacher, neue Aufgaben zu beginnen als bestehende abzuschließen. Gerade deshalb ist es bei Kanban wichtig, den "work in progress" zu begrenzen. Bei Scrum besteht dieses Problem weniger, da die Aufgaben in der Regel am Ende des Sprints abgeschlossen werden, auch wenn dies in der Realität nicht immer der Fall ist.
Das Ende des Sprints ist daher oft eine stressige Phase für das Scrum-Team, in der die Arbeit noch abgeschlossen werden muss, um in das Inkrement zu gelangen. Dieser Stressfaktor tritt bei Kanban eher weniger auf und sollte auch bei Scrum im Auge behalten werden.
Unvorhergesehene Arbeiten werden bei Kanban priorisiert, bearbeitet und geliefert. Bei Scrum wird dieser Prozess erschwert, da die nächste Iteration abgewartet werden muss, um das Arbeitspaket einzuplanen. Um dies zu umgehen, kann in Absprache mit dem Team das Sprint Backlog angepasst und ein Arbeitspaket ausgetauscht werden. Diese Vorgehensweise sollte nicht zur Gewohnheit werden.
Kanban definiert keine festen Rollen und Besprechungen. Stattdessen wird die bestehende Organisationsstruktur beibehalten. Für bestimmte Teams können strukturierte Vorgaben oder feste Zeitfenster hilfreich sein, um Termine einzuhalten und die Planbarkeit der einzelnen Arbeitspakete zu gewährleisten.
Mehr Agilität mit Continuous Delivery
Das agile Manifest betont kontinuierliches Kundenfeedback und die Auslieferung in kurzen Iterationen, um Risiken und Auswirkungen zu minimieren.
Eine kontinuierliche Lieferung von Arbeitspaketen wird vor allem durch Kanban begünstigt. Die Feedbackschleife kann in diesem Fall auf ein Minimum reduziert werden. Auch bei Scrum ist eine kontinuierliche Lieferung möglich. In einigen Fällen wird jedoch das Produktinkrement als auslieferbares Objekt betrachtet und erst am Ende der Iteration ausgeliefert, was den Prinzipien von Continuous Delivery widerspricht.
Die Bereitstellung der Software wird durch Continuous Delivery weitgehend automatisiert, um den Prozess zu beschleunigen.
Änderungen am Quellcode werden mehrmals täglich in den Main-Branch integriert (Continuous Integration).
Tests und Quality Gates werden automatisch ausgeführt bei jeder Integration (Continuous Integration).
Das Deployment wird automatisiert in eine produktionsähnliche Umgebung durchgeführt (Continuous Delivery).
Fazit
Agile Methoden bieten entscheidende Vorteile gegenüber klassischen Entwicklungsmethoden. Dennoch gibt es Projekte, für die ein klassisches Vorgehen empfehlenswert ist. Die Vor- und Nachteile müssen für jedes Projekt einzeln abgewogen werden.
Scrum bietet eine strukturierte Vorgehensweise mit festen Zeiträumen, Rollen und Meetings. Die vorgegebenen Strukturen können vor allem bei größeren Projekten wertvoll sein, da die Planbarkeit erhöht wird.
Kanban nutzt bestehende Organisationsstrukturen und bietet mehr Flexibilität. Es bietet jedoch keine zusätzlichen Anreize für das Team, seine Arbeit innerhalb bestimmter Fristen zu erledigen.
Ein wichtiger Bestandteil der agilen Entwicklung ist die kontinuierliche Auslieferung und das Kundenfeedback. Daher sollte besonderes Augenmerk auf die automatisierte Integration und Bereitstellung von Änderungen gelegt werden.