Agile Software Development with Scrum (Schwaber/Beedle, Prentice Hall, 2002) Ein Lesebericht von Robert Hagedorn und Dr. Juho Mäkiö Was ist eigentlich Scrum und wie kann es erfolgreich in der Systementwicklung eingesetzt werden? - Das wird der Leser dem Buch Agile Software Development with Scrum von Ken Schwaber und Mike Beedle entnehmen können. 1
Aufteilung des Buches Das Buch ist in neun Kapitel unterteilt. 1. Einleitung (S.1-21) 2. Vorbereitung auf Scrum (S.23-29) 3. Übungen mit Scrum (S.31-54) 4. Srum anwenden(s.57-83) 5. Warum Scrum?(S.89-103) 6. Warum funktioniert Scrum?(S.105-121) 7. Fortgeschrittene Scrum-Applikationen (S.123-136) 8. Scrum und die Organisation (S.140-146) 9. Die Werte von Scrum (S.147-153) Die Autoren verdeutlichen direkt zu Beginn an einem Fallbeispiel die Entstehung von Scrum. Anhand von weiteren Fallbeispielen lässt sich Funktionalität und Anwendung von Scrum sehr praxisnah nachvollziehen, was bereits in den ersten Kapiteln zu einem schnellen und guten Verständnis der Materie führt. Die Autoren beschreiben des Weiteren ihre Erfahrungen bei der Nutzung von Scrum zur Systemerstellung. Weitere Fallstudien vermitteln dem Leser ein praxisbezogenes Gefühl für Scrum-basierte Projekte und deren Management. Laut den Autoren ist Scrum ein radikal andersartiger Ansatz für den Prozess der Systementwicklung. Scrum implementiert einen empirischen Ansatz, der auf Prozesskontrolltheorie basiert. Dieser empirische Ansatz führt Flexibilität, Anpassungsvermögen und Produktivität wieder in die Systementwicklung ein. Mit Scrum ist es möglich, schnell, direkt und kostengünstig ins Stocken geratene und problematische Projekte wieder zu beleben sowie erfolgreich zu beenden. Solch eine Problematik wird gleich im ersten Fallbeispiel sehr anschaulich behandelt. Scrum ist ein Management- und Kontrollprozess, der die Aufmerksamkeit gezielt auf die Vereinbarkeit von Softwareentwicklung und Wirtschaftlichkeit lenkt. Scrum wurde beispielsweise auch zur Entwicklung von Extreme Programming (XP) verwendet. Die Kernelemente von Scrum sind: Product Backlog Product Owner Scrum Teams Sprint Scrum Master Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting 2
Diese Kernelemente werden im Folgenden näher erläutert. Product Backlog Das Product Backlog ist eine Liste, in der alle das Projekt betreffenden Aufgaben und Ideen festgehalten werden. Zusätzlich wird die Liste durch eine Prioritätenabfolge jedes einzelnen Elementes geordnet. Neue Ideen und Aufgaben werden ebenfalls nach Prioritäten geordnet und in die Product Backlog aufgenommen. Eine wichtige Eigenschaft dieser Liste ist, dass sie niemals statisch abgeschlossen wird. Sogar im Gegenteil: Aufkommende Aufgaben werden während des Projekts dynamisch eingepflegt. Das heißt, dass nicht vor Beginn einer Implementierung eine finalisierte Aufgabenliste bestehen muss. Die Product Backlog entwickelt sich also parallel zum eigentlichen Projekt weiter. Deren Inhalt kann grundsätzlich jeder, der direkt oder indirekt an dem betreffenden Projekt beteiligt ist, beisteuern (Also: Nutzer, Kunden, Verkaufsabteilung, Marketing- Abteilung, Customer Service, Entwicklungsabteilung). Weiterhin ist das Product Backlog für alle Mitarbeiter einsehbar abgelegt, sodass für jeden Interessenten die aktuell wichtigsten Elemente ersichtlich sind. Des Weiteren gibt das Product Backlog darüber Auskunft, welche Aufgaben gerade von den Scrum Teams bearbeitet werden. Product Owner Der Product Owner ist diejenige Person, die Aufgaben und Ideen entgegen nimmt, diese nach Prioritäten ordnet und sie in die Product Backlog einfügt. Nur der Product Owner ist ausdrücklich dazu berechtigt. Er entwickelt dadurch einen effektiven Entwicklungsablauf. Scrum Teams Als Scrum Team wird eine kleine, funktionsübergreifende Gruppe von Entwicklern bezeichnet. Dieses Team führt sämtliche Entwicklungsarbeiten durch. Das Scrum Team entscheidet selbst, wie viele Aufgaben es aus dem Product Backlog in einem Sprint bearbeitet. Sprint Unter einem Sprint wird ein auf 30 Tage festgelegter Zeitraum verstanden, der auch als Iteration bezeichnet wird. In diesem Zeitraum arbeitet das Scrum Team isoliert und ausschließlich an den Aufgaben, die es sich aus dem Product Backlog heraus gesucht hat. Verschiedene Teams arbeiten parallel und alle ausschließlich an Elementen aus dem Product Backlog. Eine Beschränkung der Teams findet nur durch Organisationsstandards, Konventionen und den Rahmen des Product Backlog, den das Team ausgewählt hat, statt. Jeder Sprint muss mit Fertigstellung von neuen ausführbaren Produktfunktionalitäten enden. Während eines Sprints finden drei verschiedene Meetings statt. Zu Beginn wird das Sprint Planning Meeting abgehalten: Während der Sprintphase das Daily Scrum und am Ende eines Sprints das Sprint Review Meeting. Scrum Master Der Scrum Master ist dem Management zugehörig und übernimmt die Verantwortung für Erfolg und Misserfolg von Scrum. Er stellt den Puffer zwischen dem Sprint Team und der restlichen Unternehmensumgebung dar. Das heißt, dass er nach außen sowohl das Team als auch das 3
Management vertritt. Er übernimmt alle organisatorischen Funktionen, damit das Team sich so gut wie möglich auf seine festgelegten Aufgaben im Sprint konzentrieren kann. Er stellt den Ansprechpartner für das Team dar, kümmert sich um die Beseitigung sämtlicher vom Team genannten Hindernisse, hält potentielle Störer fern und überwacht das Team bei der Entwicklung. Während eines Sprints ist der Scrum Master die einzige Person, die das Sprint Team beeinflussen darf. Der Scrum Master hält alle Meetings ab, die den aktuellen Sprint betreffen (Sprint Planning Meeting, Daily Scrum Meeting, Sprint Review Meeting). Er hat sicherzustellen, dass jedes Meeting wie geplant stattfinden kann und legt Regeln fest, damit Meetings störungsfrei stattfinden können. Auf etwaige Regeln wird später noch eingegangen. Der Scrum Master arbeitet mit allen beteiligten Institutionen zusammen. Er formt zusammen mit dem Management das Team, erstellt mit dem Kunden zusammen Teile des Product Backlog für die jeweiligen Sprints, plant und initiiert diese auch schließlich. Der Scrum Master ist - kurz gesagt - derjenige, der den Überblick über den Sprint hat, diesen koordiniert und zielstrebig vorantreibt. Sprint Planning Meeting Kunden, Nutzer, Management, Product Owner und das Scrum Team bestimmen in diesem Meeting das Ziel für den nächsten Sprint. Anschließend werden die ausgewählten Aufgaben, welche bis zum nächsten Product Increment 1 bearbeitet werden müssen, auf die Mitglieder im Team verteilt. Dieses Meeting wird noch einmal in zwei Teile unterteilt. Im ersten Teil sind alle aufgezählten Parteien zur Bestimmung des Zieles anwesend, während im zweiten Teil nur noch die Mitglieder des Scrum Teams zusammen kommen, um ihr weiteres Vorgehen zu planen. Wichtigste Grundlage dieses Meetings ist das Product Backlog und vor Allem dessen Punkte von hoher Priorität. Sprint Backlog Die Erstellung des so genannten Sprint Backlog ist Bestandteil des Sprint Planning Meeting und findet nach der Zieldefinition im Sprint Planning Meeting des aktuellen Sprints statt. Im Sprint Backlog werden noch einmal die durchzuführenden Aufgaben aufgeführt. Jeder so genannte Task muss detailliert beschrieben werden und seine Umsetzung sollte auf vier bis 16 Stunden ausgelegt sein. Dieses Sprint Backlog ist ebenfalls nicht statisch, sondern verändert sich dynamisch während des Sprints. So werden zum Beispiel Aufgaben, die sich neu ergeben, eingefügt oder Tasks verändert, wenn deren Bearbeitung weniger oder mehr Zeit als veranschlagt beansprucht. Eine Veränderung des Inhalts des Sprint Backlog darf während eines Sprints nur von dem jeweiligen Scrum Team durchgeführt werden. Das Sprint Backlog gibt für alle sichtbar in Real-Time den aktuellen Stand der Bearbeitung durch das Scrum Team wieder. Daily Scrum Meeting Das Daily Scrum Meeting ist ein tägliches Status-Meeting, in dem der aktuelle Verlauf besprochen wird, Hindernisse identifiziert und anschließend durch das Management beseitigt werden. Für den Scrum Master bietet sich hiermit eine gute Gelegenheit, den Level des Fortschritts zu beobachten, den das Team erreicht. Der Zeitpunkt sowie der Ort dieses Meetings sollten immer gleich sein, um unnötigen Organisationsaufwand zu vermeiden. Eine weitere wichtige Eigenschaft dieses Meetings 1 Product Increment: engl.: Produkterweiterung, Output am Ende eines Sprints 4
ist, dass es eine genau festgelegte Dauer und einen festgelegten Ablauf hat. Ein Daily Scrum dauert demzufolge circa 15 Minuten. Während des Meetings dürfen nur Mitglieder des Scrum Teams sprechen und nur die folgenden drei Gesprächsthemen sind erlaubt: Was wurde seit dem letzten Meeting getan? Was soll bis zum nächsten Meeting getan werden? Und: Was hat die Arbeit behindert oder was wird sie noch behindern? Weiterhin ist die Reihenfolge der Redner festgelegt. Im Uhrzeigersinn berichtet jedes Team- Member, bis jedes mindestens einmal berichtet hat. Die großen Vorteile des Meetings sind, dass viele einzelne Status-Meetings entfallen, das Lesen unzähliger Reports entfällt und Fortschritt, Probleme und Entscheidungen täglich nur 15 Minuten in Anspruch nehmen. Sprint Review Meeting Nach einem durchgeführten Sprint kommen die Parteien wieder zusammen, die sich bereits im Sprint Planning Meeting gegenüber saßen. In diesem Meeting präsentiert nun das Team dem Management, den Kunden, Nutzern usw. die im Sprint entwickelte Produkterweiterung (Product Increment). Die Autoren beschreiben in ihren Ausführungen zu diesem Thema, dass in diesem Meeting die Mitglieder des Scrum-Teams über ihre Erfahrungen während des Sprints berichten und darauf eingehen, welche Probleme sie hatten, aber auch, welche Aufgaben erfolgreich nach Plan bearbeitet werden konnten. Weitere Kapitel des Buches In der zweiten Hälfte des Buches werden im Wesentlichen die folgenden Themen behandelt: Wie Scrum in einem Unternehmen implementiert werden kann, warum man sich zur Einführung von Scrum entscheiden sollte, warum Scrum so erfolgreich funktioniert, wie Scrum in großen Projekten verwendet werden kann und welche Auswirkungen Scrum auf das jeweilige Unternehmen hat. Die Autoren bieten zur Veranschaulichung etliche Fallstudien, womit ihre Methoden glaubhafter gemacht werden. Darüber hinaus sind diese leicht verständlich und können gut nachvollzogen werden. Die Ausführungen sind zu jedem behandelten Kapitel sehr detailliert, mit Referenz zu den jeweiligen Beteiligten. Schwaber und Beedle können auf einen reichhaltigen Erfahrungsschatz zurückgreifen, an dem sie den Leser in ihrem Buch umfangreich teilnehmen lassen. Sie weisen auf viele Fehler und mögliche Lösungen hin, die bei der Anwendung von Scrum aufkommen können. Gerade deswegen ist es bei Komplikationen sehr hilfreich, diese Lektüre heranzuziehen. Es finden sich oft Wiederholungen aus vorangegangenen Kapiteln, die dem eiligen Leser ermöglichen, auch ohne detaillierte Vorkenntnisse in einem weiter fortgeschrittenen Kapitel des Buches einzusteigen. Die Autoren verwenden ebenfalls einige Grafiken, um gewisse Prozesse zu verdeutlichen. Falls dem interessierten Leser die vorhandenen Grafiken nicht genügen sollten, lassen sich mit Bildersuchmaschinen im Internet leicht weitere gute Grafiken finden, die zum 5
besseren Verständnis herangezogen werden können. Fazit Abschließend ist zu konstatieren, dass das Buch Agile Software Development with Scrum von Ken Schwaber und Mike Beedle einen gelungenen Einstieg in Scrum bietet. Besonders hilfreich für den Leser sind die vielen realen Fallbeispiele aus den praktischen Erfahrungen der Autoren sowie der hohe Grad der Detailgenauigkeit bei den Ausführungen. Dadurch erhält man einen schnellen und umfangreichen Einblick in die Geschichte, den Anwendungsbereich und die Möglichkeiten von Scrum. 6