Mittlerweile kann man schon sagen, dass um das agile Management beziehungsweise die agile Softwareentwicklung ein richtiger Hype entstanden ist. Längst hört man diesen Begriff nicht mehr nur aus der Start-Up-Szene. Denn auch in Großkonzernen hält die agile Organisation Einzug. Und was sollen wir sagen, auch wir arbeiten nach dem agilen Prinzip. Also richtig, nicht nur als Bullshit-Bingo.
Doch was ist dieses „agil“ eigentlich?
Nun, zunächst einmal bedeutet agil nichts anderes als beweglich oder flexibel. Es gibt keinen starren Plan, der vor der eigentlichen Entwicklung ausgearbeitet und dann strikt abgearbeitet wird. Vielmehr geht es in der agilen Softwareentwicklung darum, die Transparenz und vor allem auch die Flexibilität zu erhöhen. Durch die Unterteilung in viele kleine abgeschlossene Zyklen, entstehen schon während des Entwicklungsprozesses sogenannte Produktinkremente (Versionen des Produkts, das bereits funktioniert, getestet und freigegeben wurde), die dem Kunden gezeigt werden können. Letztlich führt das zu einem schnelleren Einsatz des entwickelten Systems und der Kunde kann schon frühzeitige erste Erfolge der Entwicklung sehen. In der Regel wird der gesamte Softwareentwicklungsprozess nach einem bestimmten Vorgehensmodell aufgebaut. Das kann zum Beispiel Extreme Programming sein, Kanban oder – wie in unserem Fall – Scrum.
Und Scrum ist ein Akronym für…?
Scrum ist kein Akronym, wie man es vielleicht erwarten würde. Tatsächlich kommt der Begriff aus dem Rugby und bedeutet wörtlich „Gedränge„.
Im Kern der agilen Softwareentwicklung steht immer ein selbstorganisiertes Team, sowie eine iterative und adaptive Vorgehensweise. Das bedeutet, es wird in Iterationen – sogenannten Sprints – gearbeitet, die in der Regel zwei bis vier Wochen dauern.
Bei Scrum im Speziellen wird zu Beginn nur das Ziel definiert und alle Anforderungen (auch Product Backlog Item, kurz PBI, genannt) werden schriftlich festgehalten, im sogenannten Backlog. Dort werden die Anforderungen gepflegt, priorisiert und gegebenenfalls erweitert. Einen genauen Ablaufplan aber gibt es nicht. Stattdessen wird während des Entwicklungsprozesses bzw. im Sprint-Planning entschieden, welche Anforderung als nächstes entwickelt werden soll. Das spart Arbeit, Zeit und Geld. Denn bei Änderungen entsteht kein wesentlicher Mehraufwand, da das gesamte Projekt agil, also beweglich und flexibel gehalten wurde.
Dem geht natürlich immer voraus, dass die Anforderungen entsprechend festgehalten und auch in der Beschreibung ausgearbeitet bzw. ausformuliert sind, um im Sprint-Planning zusammen mit den Beteiligten auf diese einzugehen, Aufwände abzuschätzen (Stichwort: Planning-Poker) und für den kommenden Sprint einzuplanen.
Wie läuft die agile Entwicklung denn nun ab?
Vorab sei noch gesagt, dass es man in der Softwareentwicklung davon ausgeht, dass es ein fertiges Produkt nicht gibt. Stattdessen gibt es immer nur Versionen, die als Fertig definiert werden (Definition of Done). Damit ist jede Version nur das Ergebnis einer Iteration.
Dieses Denken in Zyklen soll Scrum in feste Abläufe bringen. Doch bevor es nun an die Erklärung geht, wie die agile Softwareentwicklung abläuft, müssen wir klären, welche drei Rollen es in einem Scrum-Team gibt:
Product Owner
In jedem Prozess der Softwareentwicklung gibt es einen Auftraggeber, egal ob es sich dabei um ein Kundenprojekt oder ein internes Projekt handelt. In Scrum trägt der Auftraggeber den Titel Product Owner. Der Product Owner vertritt die fachliche Seite. Er stellt Anforderungen und beurteilt die Umsetzung seiner Wünsche. Insbesondere auf Funktionalität, Performance, Qualität und Usability legt er besonderes Augenmerk. Je nach Kapazitäten und KnowHow muss dieser nicht zwingend der Kunde selbst sein, lässt er sich beispielsweise durch einen Berater vertreten. Wichtig ist jedoch, dass der Product Owner sowohl zeitlich verfügbar, als auch entscheidungsbefugt ist. Anders kommt es erfahrungsgemäß zwangsläufig zu Entscheidungsstaus oder Unklarheiten (und damit vermeidbaren Mehraufwänden) in der Umsetzung.
Scrum-Master
Der Scrum-Master ist, wie der Name schon vermuten lässt, der Herr über die Prozesse. Er ist quasi der Moderator des Projekts, nicht aber der Manager. Er achtet darauf, dass aus der gewünschten Dynamik des Projekts nicht Chaos wird. Darüber hinaus vermittelt er zwischen Entwicklerteam und Product Owner und beseitigt Hindernisse, die dem Entwicklerteam im Weg stehen könnten.
Entwicklerteam
Das Entwicklerteam stellt den Kern im Scrum-Prozess dar. Es ist für die Umsetzung der Anforderungen verantwortlich und organisiert sich selbst, benötigt daher nach dem Scrum-Master also keinen Projektleiter. Es besteht aus mindestens drei, höchstens zehn Mitgliedern.
Der Ablauf
Jede Iteration beginnt mit der Sprint-Planung. Dabei werden im Wesentlichen zwei Fragen beantwortet:
1. Was kann im kommenden Sprint entwickelt werden?
Der Product Owner und das Entwicklerteam erarbeiten gemeinsam, welche Funktionalität nach dem nächsten Sprint erreicht werden soll. Dabei entscheidet das Entwicklerteam, wie viele PBIs (Product Backlog Item) es im nächsten Sprint umsetzen kann. Mit welcher Priorisierung die ausgewählten Anforderungen dann bearbeitet werden, obliegt aber wieder dem Product Owner. Gemeinsam im Scrum-Team wird das Sprintziel formuliert, das in der Regel die Fertigstellung eines Produktinkrements ist, das (zumindest theoretisch) an den Kunden ausgeliefert werden kann.
2. Wie wird die Arbeit im kommenden Sprint erledigt?
Der zweite Teil der Sprintplanung wird hauptsächlich vom Entwicklerteam organisiert. Jetzt geht es darum, im Detail zu planen, welche Aufgaben zum Erreichen des Sprintziels nötig sind. Dabei sollte der Product Owner aber immer für Rückfragen zur Verfügung stehen.
Die Aufgaben, die in diesem Teil der Sprintplanung festgelegt werden, werden dann im Sprint Backlog festgehalten und im Laufe des Sprints abgearbeitet.
Im täglichen Arbeitsalltag sollte es immer zu Beginn eines jeden Arbeitstages ein Daily-Scrum geben. Dieses Daily dauert maximal 15 Minuten und dient dem Informationsaustausch. In erster Linie geht es hierbei darum, die anderen Mitglieder des Entwicklerteams über den aktuellen Stand der Aufgaben zu informieren. Probleme sollten in einem zusätzlichen Meeting gelöst werden, betreffen sie nicht die vollständige Runde. Probleme und auch deren Lösungen sollten ebenso in den Tickets bzw. Stories nahe den Anforderungen festgehalten/dokumentiert werden.
Am Ende eines jeden Sprints gibt es dann eine Sprint-Review. Das gesamte Scrum-Team testet das entwickelte Produktinkrement und passt das Product Backlog an. Außerdem wird überprüft, ob das Ziel erreicht wurde und die Ergebnisse werden mit dem Kunden bzw. Product Owner besprochen.
Schließlich gibt es noch die Sprint-Retrospektive, bei der das Scrum-Team seine eigene Arbeitsweise reflektiert, um die in Zukunft noch zu verbessern. Wichtig ist es, Kritik und Probleme offen zu äußern und gemeinsam konstruktiv Lösungen zu erarbeiten. – Wie so eine Retrospektive (wenn auch nicht ausschließlich auf die Softwareentwicklung bezogen) bei uns abläuft, haben wir hier schon einmal erklärt.
Für uns ist die agile Arbeitsweise auf jeden Fall eine sehr gute Sache, die sich bewährt hat. So können wir nämlich flexibel auf die Wünsche unserer Kunden eingehen und Risiken im Entwicklungsprozess minimieren.