Zur Einleitung eine Metapher eines Softwareentwicklungsprojekts mit seinen jeweiligen Akteuren

Was ist Scrum eigentlich?

Nun ja, die Bedeutung von Scrum kann man auf zwei unterschiedliche Weisen erläutern. Einerseits ist Scrum definiert als agiles – also flexibles – Projektmanagementverfahren welches hauptsächlich in Softwareentwicklungsprojekten eingesetzt wird. Hierbei wird viel Wert auf Wissensmanagement – sprich die Weiterbildung der Mitarbeiter – gelegt. Der eigentliche Prozess besteht aus mehreren, verschachtelten Schleifen – sogenannten Sprints – in denen Feedback an den Projektleiter – ScrumMaster – zu bisherigen Ergebnissen gegeben wird. Andererseits ist Scrum einfach die deutsche Übersetzung für „Gedränge“, was möglicherweise mit den zahlreichen Projektmitgliedern und deren Koordination in einem Scrum-Projekt zu tun hat.

Entwickelt wurde Scrum durch Ken Schwaber, Jeff Sutherland und Mike Beedle. Beide haben das Vorgehensmodell erstmals 1995 auf der OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) in den USA vorgestellt und in den folgenden Jahren etabliert.

Aufgrund ihrer mangelnden Flexibilität sind die meisten Projektmanagement-Methode für Softwareentwicklungs-Projekte nur beschränkt geeignet. Abhängigkeiten zwischen einzelnen Teams oder Akteuren legen einen starren Zeitplan vor und verhindern Parallelarbeiten. Zusätzlich werden Prozesse, Pläne und Dokumentationen in klassischen Phasenmodellen hoch priorisiert, was wenig Raum für Kreativität und Innovationen lässt.

Im Februar 2001 wurde das Agile Manifest veröffentlicht, welches Werte für die Agile Softwareentwicklung enthält. Dieses Dokument bildet das Fundament der Prozessdefinition von Scrum. Das Agile Manifesst enthält folgende Kernpunkte:

1. Individuen und Interaktionen gelten mehr als Prozesse und Tools.
2. Funktionierende Programme gelten mehr als ausführliche Dokumentation.
3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.
4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans.

Welche Rollen existieren in Scrum-Projekten?

In einem Scrum-Projekt agieren viele Protagonisten miteinander, um den Projekterfolg zu garantieren. Für Gewöhnlich werden nur drei Rollen in Scrum-Projekten definiert (ScrumMaster, Team und Product Owner). Boris Gloger erweitert dieses Modell jedoch um die Akteure Manager, Customer und End User. Dieses Szenario wird im Folgenden vorgestellt und um diese Rollen sowie deren Verknüpfungen verständlicher darzustellen, wird hier die Metapher einer Filmproduktion verwendet.

1. ScrumMaster – Der Regisseur
Der ScrumMaster ist der Leiter des Teams und der Moderator der regelmäßigen Meetings. Er muss das Team vor von Außen einwirkenden Faktoren beschützen, die den Projektverlauf gefährden oder behindern könnten. Seine Aufgabe ist weiterhin, dass die agilen Richtlinien eingehalten und umgesetzt werden. Auf diese Weise steigert er die Produktivität seines Teams.

2. Team – Die Schauspieler
Das Team liefert das Endprodukt ab und ist verantwortlich für dessen Qualität. Die Anforderungen des Kunden und der End User werden aufgenommen und analysiert und im Anschluss daran umgesetzt. Im Grunde wird alles, das Design, die Funktionalitäten, die Tests, etc., vom Team implementiert und durchgeführt. Hierzu ist eine enge Zusammenarbeit mit dem Product Owner notwendig, um die strategische Ausrichtung des Softwareentwicklungsprojekts stetig neu zu definieren.

3. Manager – Der Studioboss
Das Management ermöglicht eine angemessene Umgebung für das Scrum-Team, definiert Strukturen und erzeugt Stabilität. Es arbeitet eng mit dem ScrumMaster zusammen um die Richtlinien, falls nötig, neu zu skizzieren.

4. Customer – Der Produzent
Der Kunde ist typischerweise die Person, welche vom Scrum-Team das finale Endprodukt überreicht bekommt. Kunden sind meist Manager in Unternehmen, welche externe Organisationen damit beauftragen, Produkte für sie zu entwickeln.

5. Product Owner – Der Drehbuchautor
Der Product Owner hat in gewissem Sinne die Unternehmens-Brille auf. Er hat eine klare Vision, wie das Produkt aussehen soll und welche Haupt-Charakteristika es erfüllen soll. Nach jedem Sprint wird das Ergebnis durch ihn begutachtet und abgenommen. Die Hauptaufgabe des Product Owners ist es sicherzustellen, dass das Team nur an den, für die Organisation wichtigsten Backlog Items arbeitet und sie dazu mit den notwendigen Informationen zeitnah zu versorgen. Er ist verantwortlich für den Return on Investment – also die Rentabilität.

6. End User – Das Publikum
Der End User kann anhand vieler, verschiedener Rollen definiert werden. Er kann eine Person aus der Marketing-Abteilung sein, ein Consultant oder ein Domain-Experte. Die Liste ließe sich beliebig lang erweitern, doch der Punkt ist, der End User kennt die Anforderungen, weil er sie selbst aufgestellt hat. Somit hat er eine gewisse Erwartungshaltung gegenüber dem Produkt und eine fundierte Wissensbasis in dessen Einsatzgebiet. Dieses Wissen gibt er an das Team weiter, welche es für die Umsetzung nutzen sollte.

Welche Artefakte gibt es in Scrum?

Um ein Scrum-Projekt erfolgreich abzuschließen, bedienen sich Scrum-Teams sogenannter Artefakte. Das sind Tools oder Ergebnisse von Aktivitäten welche im Projekt eine professionelle Arbeitsgestaltung ermöglichen. Die effizienteste und effektivste Form der Kommunikation in Projekten ist nach wie vor die face to face-Kommunikation, so dass in diesem Sinne Artefakte mit anderen Kommunikationsformen durch diese ersetzt werden. Die agile Softwareentwicklung beinhaltet ein Artefakt, auf das unter keinen Umständen verzichtet werden kann, nämlich auslieferbaren Code. Da sich die Film-Metapher auch hier zum näheren Verständnis eignet, wird sie auch auf diese Thematik angewendet.

1. Impediment Backlog – Die Fehlerliste
In dieser Liste werden Hindernisse und Risiken aufgezeichnet, welche dem Scrum-Team Probleme bereiten könnten. Dem ScrumMaster dient Auflistung dazu, seine nächsten Aktionen zu planen um diese Barrieren zu minimieren oder zu beseitigen.

2. Product Backlog – Das Drehbuch
Im Product Backlog werden Geschichten, Anforderungen, Funktionalitäten, etc. notiert. Diese Liste entspricht im Grunde einem Katalog an Kriterien, welche das Scrum-Team in Zukunft abliefern möchte. Die Backlog Items dieses Dokuments sind nach dem Wert für das Unternehmen und der Kapitalrendite (Return on Investment) sortiert.

3. Selected Product Backlog – Die Szenen
Eine Szene ist ein Teil des gesamten Films. So etwa kann man auch das Selected Product Backlog verstehen. Hier werden die Spezifikationen des Product Backlog aufgelistet, welche für den aktuellen Sprint umgesetzt werden müssen.

4. Potential Shippable Product Increment – Eine Episode
Am Ende eines Sprints liefert das Scrum-Team ein potentiell lieferfähiges Produkt-Inkrement ab, an dem nicht mehr gearbeitet werden muss. Falls die Entwicklung zu diesem Zeitpunkt eingestellt werden müsste, ist das ein bereits funktionsfähiger Teil des Prototypen, der bereits eingesetzt werden könnte.

5. Sprint Backlog – Der eigentliche Dreh
Der Sprint Backlog visualisiert die nächsten Aktivitäten für das Entwicklerteam und hilft dabei, diese zu synchronisieren, da das bei einer größeren Anzahl sehr schnell sehr unübersichtlich werden kann. Man muss aber immer im Hinterkopf behalten, dass anhand des Sprint Backlogs keine Vortschritte, sondern lediglich der aktuelle Status, bzw. die momentane Situation veranschaulicht werden.

Wie funktioniert das Tracking des Fortschritts in Scrum?

Hierbei dient einerseits das Burn Down Chart als bewährte Methode um Fortschritte zu visualisieren. Dies geschieht unüblicherweise durch das Team selbst. Jeweils ein Burn Down Chart wird für jeden Sprint hergenommen und täglich aktualisiert. Dabei repräsentiert die vertikale Achse die Anzahl der abzuarbeitenden Tasks und die horizontale Achse die Tage des aktuellen Sprints. Bei der Erstellung eines Burn Down Charts, sollte man besonders darauf achten, es einfach zu gestalten damit das Team die regelmäßigen Updates leicht eintragen kann.

Auf der anderen Seite kann man ergänzend zum Burn Down Chart noch das Task Board verwenden, um den Status des aktuellen Sprints festzuhalten. Hier gilt die selbe Regel wie beim Burn Down Chart, dass nur das Scrum-Team das Task Board pflegt und benutzt. Dieses Task Board kann entweder ein Software-Tool sein oder ein Whiteboard an der Wand.

Das Task Board lässt sich in vier Spalten unterteilen.

1. Selected Product Backlog (Stories)
Hier werden alle Product Backlog Items / Stories eingetragen, welche das Team in diesem Sprint erledigen möchte. Dabei wird – zur besseren Übersicht – auch gleich eine Priorisierung von Wichtigem nach Unwichtigem angewandt.

2. Tasks To Do
Die Tasks die noch nicht gestartet wurden aber noch erledigt werden müssen, haben ihren Platz in dieser Spalte. Sie ergeben sich aus den Sprint Planning Meetings oder während man den Sprint ausführt.

3. Work in Progress
Sobald ein Teammitglied einen Task beginnt, nimmt er die Karte mit diesem Task und bringt sie in der Spalte Work in Progress an. Ist eine Aufgabe seit dem letzten Daily Scrum in dieser Spalte, erhält sie eine Markierung, für gewöhnlich mit einem roten Punkt. Bleiben Tasks länger als einen Tag in Bearbeitung, kann man sie auch in Untertasks aufteilen. Verhindert etwas die Erfüllung eines bestimmten Tasks, wird die Karte auch mit einem roten Punkt markiert und das Hindernis dazu geschrieben.

4. Done
Sobald ein Task erledigt ist, wird die Karte vom jeweiligen Teammitglied in der Spalte Done angebracht. Im Anschluss daran wird die nächste Aufgabe in Angriff genommen. Was als „erledigt“ definiert wird kann vorher in einem Brainstorming spezifiziert werden.

Welche Meetings gibt es in Scrum-Projekten?

Wie in jedem gut organisierten Projekt ist ein guter Zeitplan das A und O und macht so einen Großteil des Erfolges aus. In Scrum wird das Projekt über den kompletten Zeitraum von einer Vielzahl unterschiedlicher Meetings und Meeting-Typen begleitet. Welche das sind, wird anhand folgender Grafik veranschaulicht und im Anschluss erläutert.

1. Estimation Meeting
Den Beginn eines jeden Sprints leitet das Estimation Meeting ein. Es dient dazu die Backlog Items und deren Größe kennenzulernen. Dabei schätzt das Team selbst ab, wieviel Arbeit es sich zumutet, so dass ein Optimum gefunden wird. Die Teammitglieder bekommen weiterhin einen Überblick darüber, was sie in den nächsten Projektphasen erwartet.

2. Sprint Planning Meeting – Part 1
Das Ziel des ersten Sprint Planning Meetings ist herauszufinden was der End User im Detail haben möchte. Dadurch haben die Entwickler ein klares Bild davon, was der End User braucht und somit, was implementiert werden soll.

3. Sprint Planning Meeting – Part 2
Im zweiten Teil des Sprint Planning Meetings geht es hauptsächlich um das Design der zu implementierenden Lösung. Am Ende dieses Meetings weiß das Entwicklerteam wie die benötigten Funktionalitäten umgesetzt werden können.

4. Daily Scrum
Das Daily Scrum ist ein relativ kurzer Statusbericht jedes Teams, in dem der aktuelle Stand sowie Hindernisse mit dem ScrumMaster besprochen werden. Dieser Termin findet – wie der Name bereits erahnen lässt – jeden Tag statt und dabei werden die täglichen Aktivitäten geplant. Als hilfreiche Tool lassen sich hier das Task Board und das Burn Down Chart empfehlen.

5. Sprint Review
Am Ende eines jeden Sprints wird dem End User im Rahmen des Sprint Review das aktuelle Ergebnis präsentiert und im Anschluss daran eine Feedbackrunde an das Entwicklerteam angesetzt. Die Rückmeldung nutzt das Scrum-Team nun um neue Backlog Items zu erstellen oder bestehende zu modifizieren.

6. Sprint Retrospective
Dieses letzte Meeting kann mit einer medizinischen Diagnose des Ergebnisses verglichen werden. Hier gilt es Themen zu finden bei denen Verbesserungsbedarf besteht. Dies lässt sich gut mit zwei Flipcharts machen, auf denen die Überschirften „What went well?“ und „What could be improved?“ notiert sind. Nun schreiben die Teammitglieder ihre Ideen dazu auf Post-Its und füllen so die Flipcharts, welche im Anschluss diskutiert werden.

Wo liegt der Unterschied zwischen Scrum und anderen Vorgehensmodellen im Projektmanagement?

Wie wir bereits im ersten Kapitel gelernt haben, ist Scrum ein agiles Projektmanagement-Vorgehensmodell. Das bedeutet, dass die Kreativität und Flexibilität der Mitarbeiter gefördert werden soll indem Regeln und bürokratische Aufwände auf ein Minimum reduziert werden. Die Frage nach dem richtigen Vorgehensmodell lässt sich ganz einfach beantworten, wenn man darüber nachdenkt was der Output des Projekts sein wird.  Hierzu soll uns das Beispiel der Schiffsentwicklung dienen. Inwiefern würde sich Scrum in einem solchen Vorhaben eignen? Nehmen wir an die Schiffbau-Ingeneure treffen sich täglich zu ihrem Daily Scrum Meeting und pflegen ein Task Board. Dabei können die meisten Arbeiter noch gar nicht beginnen, weil das Design des Schiffs noch nicht fertig ist. Das hat schließlich Auswirkungen auf Faktoren wie Material und Technik. Ist dieser Punkt abgeschlossen können die Mitarbeiter der Materialbeschaffung loslegen und werden die Teile geliefert ist als nächstes die Montage an der Reihe. Hierbei handelt es sich um ein klassisches Wasserfallmodell. Sobald ein Mitarbeiter seine Aufgabe abschließt, beginnt der nächste mit seiner.

In der Softwareentwicklung eignet sich ein solches Verfahren nicht, da meist Parallelarbeit möglich ist. Das ist das Spielfeld auf dem Scrum spielt. Es gibt jedoch weitere anerkannte Modelle in der Softwareentwicklung. Extreme Programming ist – wie Scrum – ein Vertreter der agilen Softwareentwicklung. Dabei werden fortlaufende Iterationen betrachtet, die eine schrittweise Annäherung an die Anforderung des Kunden zum Ziel haben.

Das Spiralmodell ist – im Gegensatz zu Scrum – kein agiles, sondern ein generisches Vorgehensmodell in der Softwareentwicklung. Dieses Modell muss man sich als Spirale welche in vier Quadranten aufgeteilt ist, vorstellen. Die vier Abschnitte beschreiben die Festlegung der Ziele, die Risikoanalyse, die Entwicklung und Test sowie die Planung des nächsten Zyklus. Das Ende jeder Iteration beschließt immer ein Prototyp.

Das V-Modell lässt sich nicht so leicht in eine Schublade zu generischen oder agilen Softwareentwicklungs-Vorgehensmodellen stecken da es Elemente beider Arten in sich vereint. Die Hauptmerkmale des V-Modells sind im absteigenden Ast die Spezifikation und die immer feinere Darstellung und im aufsteigenden Ast die Realisierung und Integration.

Warum ist Scrum wirtschaftlicher als andere Methoden?

Ist es nicht! Im Projektmanagement ist es wichtig immer das richtige Tool für eine bestimmte Aufgabe zu wählen. Manchmal ist Scrum genau das passende Werkzeug um das Projekt bestmöglich abzuschließen, allerdings gibt es Situationen in denen das eben nicht der Fall ist. Den größten Erfolg kann man in gewissen Projekten möglicherweise mit anderen agilen Vorgehensmodellen haben oder gar mit generischen wie dem Wasserfallmodell. So pauschal lässt sich das nicht sagen. Mit Scrum wurde hier ein sehr guter Ansatz vorgestellt, aber nicht die Universallösung für Softwareentwicklungsprojekte. Es erfreut sich momentan größter Beliebtheit und hat sich schon des öfteren als eines der besten Agilen Projektmanagement-Verfahren bewährt. Wenn man versucht einen Trend für die nächsten Jahre zu erkennen, so wird dieser ganz sicher in Richtung Agilität gehen.

Quellen

http://borisgloger.com/2008/07/23/scrum-rollen-das-team/
http://de.wikipedia.org/wiki/Scrum
http://scrum-fibel.de/
http://www.controlchaos.com/
http://www.scrum.org/
http://en.wikipedia.org/wiki/Ken_Schwaber
http://slides.liip.ch/scrum-liip-techtalk-20080923/title.html
http://de.wikipedia.org/wiki/Agile_Softwareentwicklung
http://de.wikipedia.org/wiki/Vorgehensmodell_zur_Softwareentwicklung
http://projektmanagement-definitionen.de/scrum-naechste-generation-projektmanagements/
http://de.wikipedia.org/wiki/Extreme_Programming
http://de.wikipedia.org/wiki/Spiralmodell