Wer sich ein wenig mit dem Thema Softwareentwicklung beschäftigt oder sich gerade in die Materie einarbeitet, stolpert schnell über Buzzwords wie “Agile”, “Scrum”, “Product Owner” oder “Kanban”. Doch was ist das alles? Worin unterscheiden sich die verschiedenen Entwicklungsansätze? Und ist agile Entwicklung für alle Softwareprojekte praktikabel?

Wasserfall vs. Agile

Zu Beginn der Softwareentwicklung wurde in der Regel nach der sogenannten “Wasserfallmethode” entwickelt. Der Name rührt daher, dass die einzelnen Schritte Anforderungserhebung, Entwurf und Design, Implementierung, Test und Wartung wie in einem Wasserfall strikt nacheinander durchlaufen werden. Eine neue Stufe wird erst begonnen, wenn die vorhergehende vollständig abgeschlossen ist.[1] 

Seit den 60er Jahren, in denen die Wasserfallmethode entstand, hat sich die Welt jedoch stark verändert. Die Zeit läuft schneller, der Wettbewerbsdruck ist durch die Globalisierung deutlich gestiegen und von der ersten Idee bis zum fertigen Produkt sollen im Idealfall nur noch wenige Wochen liegen. Damit ist klar: Eine neue Art der Softwareentwicklung muss her! 

In den letzten Jahrzehnten sind deshalb viele verschiedene Methoden wie Lean, DevOps, Kanban oder Scrum entstanden, die alle unter den Sammelbegriff "agile Methoden" fallen.

Grundsätzlich ist allen Methoden gemeinsam, dass der Entwicklungsprozess darauf ausgelegt ist, so schnell wie möglich ein MVP, ein Minimum Viable Product, (also ein minimal brauchbares Produkt) zu liefern. Um dies zu gewährleisten, werden die einzelnen Schritte (wie Design, Entwicklung, Test), die beim Wasserfallmodell den gesamten Entwicklungsprozess abdecken, in kleineren, abgeschlossenen Phasen - meist “Sprints” genannt - durchlaufen. Am Ende jedes Sprints liegt eine in sich abgeschlossene und einsatzfähige Version des Endprodukts vor. 

Scrum

Eine Methode sticht jedoch deutlich hervor: Über 63% aller agil entwickelnden Teams verwenden das Scrum Framework [1], das damit das mit Abstand beliebteste agile Framework der letzten Jahre ist. Es soll im Folgenden etwas näher betrachtet werden.

Rollen

Bei der Entwicklung mit Scrum gibt es insgesamt drei Rollen: Die Entwickler, den Product Owner und den Scrum Master.[2]

Entwickler

Die Entwickler sind die Experten, die für die Implementierung verantwortlich sind.[2]

Product Owner

Der Product Owner ist für die Definition und Priorisierung der Anforderungen an das Produkt verantwortlich. Er erstellt und pflegt das Product Backlog, eine geordnete Liste der Anforderungen, die das Team umzusetzen hat (dazu später mehr).[2]

Scrum Master

Er stellt sicher, dass das Team die Scrum-Prinzipien einhält. Außerdem unterstützt er das Team bei der kontinuierlichen Verbesserung.

Vorbereitungen

Zu Beginn der Umsetzung eines Projektes mit Scrum müssen verschiedene Punkte geklärt werden. 

Definition of Done

Das gesamte Scrum-Team erarbeitet eine “Definition of Done”. Dabei handelt es sich um eine Liste von Kriterien, wann eine Arbeit als “erledigt” gilt. Diese Liste schafft Transparenz sowie eine gemeinsame Sprache und ein gemeinsames Verständnis darüber, welche Aufgaben erledigt sein müssen. Existiert im Unternehmen bereits eine Definition of Done, kann diese verwendet werden.[2]

Product Backlog

Das Product Backlog ist eine Liste aller Anforderungen, die in das Produkt einfließen können. Für den Inhalt und die Reihenfolge ist der Product Owner verantwortlich.[2] 

Sprint

Wie lange soll der Sprint sein? Auch dies wird zu Beginn festgelegt.[2]

Abläufe

Sprint Planung

Zu Beginn jedes Sprints wählt das Entwicklungsteam aus dem Product Backlog so viele Tasks (auch PBI, Product Backlog Items) aus, wie es im kommenden Sprint voraussichtlich bearbeiten kann. Da die Reihenfolge und Priorisierung bereits vom Product Owner festgelegt wurde, werden die Tasks von oben nach unten (bzw. von wichtig nach unwichtig) ausgewählt und dem aktuellen Sprint hinzugefügt.[2]

Arbeit

Dann beginnt die eigentliche Arbeit. Jeder Arbeitstag beginnt mit dem Daily Scrum, einem Meeting, das nicht länger als 15 Minuten dauert und in dem die folgenden Fragen beantwortet werden:

• Was habe ich gestern für das Sprintziel getan?
• Was tue ich heute für das Sprintziel?
• Welche Hindernisse sehe ich für das Sprintziel? 

Sprint Review

Am Ende jedes Sprints findet ein Sprint Review statt. Hier wird das neue Inkrement, also das Ergebnis des Sprints vorgestellt. Der Fokus liegt hier auf dem Produkt.

Sprint Retrospective

Danach findet die Sprint-Retrospektive statt. Diese sollte bei einem Sprint von 4 Wochen maximal 3 Stunden dauern. Hier liegt der Fokus auf dem Prozess. Was ist gut gelaufen, was nicht so gut und was kann wie verbessert werden? War der Sprint zu kurz oder zu lang? Muss an der Definition of Done etwas geändert werden? Gibt es andere Verbesserungsmöglichkeiten? Das Meeting wird durch den Scrum Master moderiert. 

Vorteile vs. Nachteile

Wie bei allem im Leben gibt es natürlich auch bei agilen Methoden Vor- und Nachteile. Zunächst einmal eignet sich nicht jedes Projekt für die Umsetzung mit agilen Methoden. Am besten geeignet sind komplexe Projekte mit dynamischen Anforderungen. Wenn aber z.B. die Projektanforderungen bereits feststehen und sich nicht ändern oder die Projektdauer sehr kurz ist, sollte man sich überlegen, ob es überhaupt sinnvoll ist, agil zu entwickeln. Mehr dazu in einem eigenen Blogbeitrag.

Hybrider Ansatz

Doch was nun? Weder die Wasserfallmethode noch ein agiles Framework scheinen zu passen? Es gibt noch eine dritte Möglichkeit: den hybriden Ansatz. Hier können verschiedene Elemente aus unterschiedlichen Methoden miteinander kombiniert werden. Das kann man dann zwar nicht mehr “Scrum” nennen, aber man kann sehr wohl einzelne Elemente wiederverwenden. Auch das hat natürlich Vor- und Nachteile. Am besten ist es hier, es einfach auszuprobieren! Testen Sie ein Framework im Unternehmen und diskutieren Sie gemeinsam, was sinnvoll ist und was in Zukunft vielleicht nicht mehr benötigt wird.

Beispiel Biz Factory

Wir bei der Biz Factory verwenden in den meisten Projekten einen hybriden Ansatz. Da viele unserer Kunden aus dem öffentlichen Bereich stammen, sind wir oft an recht strikte Vorgaben aus der Leistungsbeschreibung und dem Konzept gebunden, mit dem wir uns auf die Ausschreibung beworben haben. Deswegen ist ein rein agiles Vorgehen nur schwer bis gar nicht möglich. 

Rollen

In der Regel verzichten wir auf die konkreten Rollen des Scrum-Frameworks. Bei uns gibt es meist eine Projektleitung und ein Entwicklerteam. Es kann auch vorkommen, dass die Projektleitung selbst mitentwickelt. Die Projektleitung bei uns vereint die Rolle des Scrummasters und des Product Owners. Da wir eine sehr offene Feedback-Kultur und extrem flache Hierarchien haben, hat das bisher auch keine Probleme verursacht. Die Projektleitung ist in enger Abstimmung mit dem Entwicklerteam.

Vorbereitungen

In der Regel arbeiten wir trotzdem in Sprints. Alle Anforderungen aus der Leistungsbeschreibung werden zunächst in eigene Tickets überführt. Jedes Ticket sollte maximal so groß sein, dass ein:e Entwickler:in die Aufgaben in maximal einer Woche erledigen kann. Ist die Anforderung größer, wird sie in mehrere kleinere Tickets unterteilt. 

Mit dem Kunden wird eine Sprintlänge ausgemacht. Meistens bewegen wir uns hier in der Größenordnung eines Monats. 

Abläufe

Sprint Planung

Alle Tickets befinden sich in unserem gemeinsamen Kanban-Board in der “Alle Aufgaben” Spalte. 

Die Reihenfolge - also die Priorisierung - legt die Projektleitung fest. Hier findet allerdings ein enger Austausch mit dem Kunden statt: Soll ein bestimmtes Feature bevorzugt werden, und ist dies aus Projektleitungssicht ebenfalls sinnvoll, wird die Priorisierung angepasst. 
Für den aktuellen Sprint entscheidet die Projektleitung zusammen mit den Entwickler:innen, wie viele Tickets in dieser Periode umgesetzt werden können.

Arbeit

Da in der Regel jede:r Entwickler:in an mehr als einem Projekt arbeitet, gibt es kein explizites Daily für ein Projekt: Stattdessen haben wir zweimal am Tag (10.00 Uhr und 15.00 Uhr, unsere Kernarbeitszeiten) ein Teammeeting. Hier wird besprochen, an welchen Tasks aktuell gearbeitet wird, wie jeder vorankommt und ob es aktuelle Hindernisse gibt.

Sprint Retrospektive

Zusätzlich findet einmal in der Woche ein internes Meeting nur für dieses Projekt statt. Dieses ersetzt die Sprint Retrospektive. Passt etwas in einem Workflow oder Prozess nicht? So wird es direkt angesprochen.

Sprint Review

Das Sprint-Review findet meist asynchron statt. Wir erstellen einen neuen Deploy am Testserver, und der Kunde kann für sich die bearbeiteten Tickets noch einmal gegenchecken. Für den gemeinsamen Austausch findet in der Regel einmal die Woche ein gemeinsamer Jour Fixe statt.

Fazit

Agile Softwareentwicklung ist heute nicht mehr wegzudenken. Laut dem 17th State of Agile Report werden über 71% aller Softwareprojekte mit agilen Methoden umgesetzt. Sie bringen viele Vorteile mit sich und Prozesse können leichter optimiert werden, da zusätzlicher Raum für diese Diskussionen geschaffen wird. Wichtig ist, dass zu Beginn jeder Projektumsetzung geprüft wird, ob das Projekt überhaupt für einen agilen Entwicklungsansatz geeignet ist. 

Ansonsten bleibt nur zu wünschen: Happy developing!

Quellen

[1] Führen in der Arbeitswelt 4.0, Christoph Negri, Springer 2019

[2] Offizielle Scrum Website (https://www.scrum.org/learning-series/what-is-scrum/, aufgerufen am 08. Juli 2024)