Projektmanagement mit Scrum
comment
Feature

Projektmanagement mit Scrum

Gelernte Strukturen über Bord werfen? Für viele Teams ein schwieriger Schritt, doch bei konsequenter Umsetzung bietet Scrum echte Chancen für gewaltige Verbesserungen von Entwicklungsprozess und -ergebnis.

Christopher Schmitz (Ubisoft) erklärt Ihnen, wie Sie die Software gewinnbringend einsetzen und so kommunikativ zum Erfolg kommen.

Making Games

@ Facebook

Making Games

@ Twitter

Scrum ist eine der wichtigsten Methoden der agilen Softwareentwicklung. Projektteams, die den Scrum-Prozess bei sich einführen,um ihre Entwicklungsprozesse zu steuern, werden den Fun-Faktor und die Qualität ihres Produktes sehr früh erkennen. Weiter erlaubt es Scrum, viel flexibler auf Änderungen zu reagieren, die durch Marktbewegungen, den Auftraggeber oder aufgrund von neuen technischen bzw. designtechnischen Herausforderungen notwendig werden. Teamseitig wird der Scrum-Prozess eine bessere Arbeitsatmosphäre erzeugen, weil der Crew viel mehr Verantwortung übergeben wird, die Mitglieder so ein ausgeprägtes Gefühl von Produkt-»Ownership« entwickeln und sich dadurch stärker für die Zielerreichung einsetzen werden.

In diesem Artikel werden folgende Themen behandelt:

  • Was ist Scrum und was bedeutet agil?
  • Warum sollte man Scrum benutzen?
  • Das Agile Manifesto
  • Methoden der empirischen Prozessund Projektkontrolle
  • Der Scrum-Prozess im Detail



Ein Tool?


In Bezug auf Scrum wird immer wieder diese Frage gestellt: »Scrum, ist das so etwas wie MS Project?« Um dies am Anfang klarzustellen: Scrum ist ein Management-Prozess und kein Softwaretool. Sicherlich gibt es diverse Tools, um den Scrum-Prozess abzubilden und zu unterstützen. Diese sind zwar nützlich, aber man kann auch einfach mit Excel arbeiten. Scrum ist also kein Werkzeug, sondern eine Herangehensweise, auf deren Basis das Projektteam die tägliche Arbeit organsiert.


Der Entwickler des Scrum-Prozesses

Im Folgenden wird der Scrum-Prozess so dargestellt, wie ihn Ken Schwaber, einer der Entwickler von Scrum, ursprünglich definiert hat. Ken Schwaber betont stets, dass eine Anpassung seines Prozesses möglich und in bestimmten Situationen auch wünschenswert sei. Daher arbeiten viele Teams mit mehr oder weniger stark modifizierten Implementierungen von Scrum. Wichtig dabei ist, die Grundprinzipien stets einzuhalten und sich von der ursprünglichen Idee von Scrum nicht zu weit zu entfernen.

Warum Scrum?


Die grundlegende Frage ist: Warum sollte man sich einen Management-Prozess wie Scrum überhaupt ansehen oder ihn gar ausprobieren? Viele Teams arbeiten heutzutage immer noch im »Freestyle «, und das Resultat ist – in Bezug auf Zeit, Budget und Qualität – oft eher Glückssache oder von wenigen wichtigen Teammitgliedern abhängig. Scrum dagegen ist ein klar geregelter und strikter Prozess, der dem Team viel Verantwortung übergibt und dabei allen Beteiligten Disziplin und vor allem Eigen initiative abverlangt.

Grundlegende Vorteile von Scrum sind:

  • Die ersten spielbaren Produktversionen sind schnell verfügbar.
  • Die Qualität des Produktes kann deshalb in der Entwicklung besser überwacht und gesteuert werden.
  • Außerdem können so Designideen sehr früh auf ihren Spaßfaktor hin überprüft werden.
  • Durch den iterativen Charakter und das Prinzip des wachsenden »Vertical Slice« (also komplett fertige und getestete Teile eines Spiels wie zum Beispiel einen Level) gibt es viel weniger Bugs; die Masterphase am Ende des Entwicklungszyklus' wird deshalb deutlich entspannter.
  • Ebenso können Reaktionen auf Änderungen im Markt sehr schnell erfolgen und dadurch neue Trends jederzeit abgefangen werden. Auch das Focus- bzw. Markt-Testing kann erheblich früher beginnen, eine bessere finale Produktqualität ist die Folge.


Scrum ist eine der wichtigsten agilen Methoden

Scrum ist ein Management-Prozess, der auf der Annahme der »empirischen Prozesskontrolle« basiert. Das heißt, dass alle Prozesse und Planungen innerhalb des Projekts immer empirisch prüfbare Ergebnisse produzieren müssen. Einzelheiten dazu folgen. Scrum besteht aus wenigen, geradezu trivialen Regeln und ist für jeden schnell und leicht zu erlernen. Das bedeutet allerdings nicht, dass Scrum für jeden auch leicht anzuwenden ist. Besonders für Scrum gilt: »Easy to access but hard to master«. Einer der großen Vorteile von Scrum ist der iterative Ansatz, der in kurzen Abständen immer wieder neue Versionen des Produktes liefert, die dann um neue Features und einen neuen Content gewachsen sind. Das Produkt wächst »Scheibe für Scheibe«, also »slice by slice«, sodass der Fortschritt der Entwicklung stets empirisch prüfbar ist. Einer der großen Vorteile von Scrum ist der explizite Teamansatz, indem die Verantwortung der Entwicklung an die Teammitglieder übergeben wird. Die Projektmitarbeiter tragen im Rahmen des Scrum-Prozesses somit selbst die Verantwortung für das Produkt und für eine erfolgreiche Entwicklung – und sie tragen diese Verantwortung zusammen als Team. Dies kann zu einer enormen Teamdynamik führen.


Die empirische Prozesskontrolle

Wie schon erwähnt, basiert Scrum auf der Annahme der empirischen Prozesskontrolle. Diese fußt auf drei Säulen: Sichtbarkeit (Visibility), regelmäßige Überprüfung (Inspection) und Anpassung (Adaptation).

Visibility: Alle Aspekte der Prozesse, die den erfolgreichen Ablauf sicherstellen, müssen sichtbar und damit prüfbar sein.
Inspection: Regelmäßige Prüfung des tatsächlich erreichten Status' und Diskussion desselben.
Adaptation: Anpassung an neue Situationen und Erkenntnisse. '

DieserAnsatz ist verwandt mit dem traditionellen Management Circle (auch als »Demming Circle« bekannt), ein Basisverfahren der modernen Mangagement-Therorie.

Das Team

Ein Scrum-Team besteht aus fünf bis neun Projektmitarbeitern, die verschiedene Rollen einnehmen. Es besteht in erster Linie aus den Mitarbeitern, die die Basisfunktionen jeder Spieleentwicklung erfüllen – also Programmierern, Grafikern, Designern, der QA und so weiter. Wichtig ist, dass ein Scrum-Team normalerweise »cross-functional« ist. Das bedeutet, dass es keine Scrum-Teams gibt, in denen nur Programmierer oder nur Grafiker arbeiten. Jedes Scrum-Team bekommt einen Teil des Projekts als Ziel zugewiesen. Dieses muss es autark erreichen – ohne eine solche Struktur wäre das kaum möglich.


Der Scrum-Master


Der Scrum-Master stellt sicher, dass das Team den Scrum-Prozess stets befolgt. Allerdings hat diese Position keine Leitungsfunktion im klassischen Sinne des Managements. Der Scrum- Master ist weder befugt, ein Ziel zu definieren, noch darf er die Zielerreichung überprüfen. Er stellt lediglich sicher, dass die vorgeschriebenen Regeln des Scrum-Prozesses eingehalten werden und schreitet sofort ein, wenn das Team von diesem Pfad abdriften sollte. Er achtet auf die Durchsetzung des Scrum-Prozesses und räumt gemeldete Probleme aus dem Weg. Er ist folglich ein wichtiger Faktor für die Zielerreichung. Die Scrum-Master-Position kann durch jeden Mitarbeiter im Team oder auch durch externe Mitarbeiter wahrgenommen werden. Wichtig ist allerdings, dass sich dieser Mitarbeiter mit dem Scrum-Prozess sehr gut auskennt und dass er sowohl über ausgeprägte Teamfähigkeiten als auch eine gewisse Durchsetzungskraft verfügt.


Der Product Owner

Der Product Owner ist der geistige Besitzer des Produktes. Er beauftragt das Team, spezifiziert vor jeder kommenden Iteration – dem sogenannten Sprint – jedes Detail und nimmt die erreichten Ziele am Ende des Sprints ab. Er erstellt den Product Backlog Katalog und priorisiert diesen für die folgende Produktentwicklung. Ein typischer Product Owner ist der Producer des Projekts, da er für den wirtschaftlichen Gesamterfolg verantwortlich ist und daher als einer der wenigen die Priorisierung verantwortlich durchführen kann.


Der Product Backlog

In Abbildung 2 ist die Methode im Detail aufgeführt. In der Planungsphase wird vom Product Owner zusammen mit dem Scrum-Team der Product Backlog Katalog erarbeitet. In dieser Phase wird das komplette Design geschrieben und danach in einen Produktstrukturplan (PBS) überführt. Dieser PBS beinhaltet in einer strukturierten Form den gesamten Content sowie alle Features des zu entwickelnden Produktes. Nachdem dies abgeschlossen wurde, wird jedes Detail des erstellten PBS durch den Product Owner nach der »Business Value« priorisiert. Das bedeutet, dass besonders wichtige oder kritische Features mit einer hohen Priorität sehr früh ins Spiel implementiert und we niger wichtige Punkte später erarbeitet werden. Dies hat zur Folge, dass die kritischen Punkte sehr früh erledigt werden und damit das Risiko des Projekts mit jeder neuen Iteration weiter gesenkt wird. Falls sich die grundlegende Idee des Spiels also als nicht nachhaltig erweisen sollte, dann wird dies bereits auffallen, wenn erst wenig Budget ausgegeben wurde. Im typischen »Wasserfallprozess« kommt für gewöhnlich alles am Ende zusammen, und wenn sich dann herausstellt, dass das Spiel als Ganzes nicht funktioniert, dann ist das Kind schon in den Brunnen gefallen. Beim Scrum- Prozess sollten diese Probleme schon nach wenigen Iterationen auffallen, sodass Lösungen noch innerhalb des geplanten Budgets wahrscheinlich erscheinen.

Zusammenfassung:
Der Product Backlog Katalog ...

  • wird erstellt durch den Product Owner.
  • enthält die gesamte Funktionalität des Produktes.
  • enthält ebenso Teile, die keine Funktionen beschreiben.
  • ändert sich im Laufe des Projektes durch Anpassungen.
  • Punkte werden von Product Owner priorisiert.


Der Sprint Backlog

Fangen wir nun mit dem Scrum-Prozess an. Wie schon geschildert, besteht eine Produktentwicklung bei Scrum aus vielen einzelnen Sprints, in denen jeweils ein »Increment of product value«, also ein komplett abgeschlossener Teilaspekt des Projekts mit sichtbarem Wertzuwachs, erschaffen werden soll. Ein Sprint startet stets mit dem »Sprint Planning Meeting«. Im Sprint Planning Meeting nehmen alle Mitglieder des Scrum-Teams, der Scrum-Master und der Product Owner obligatorisch teil. Optional können weitere Projektmitwirkende an dem Meeting teilhaben, wenn sie Interesse an dem Sprint haben. Einer der Grundpfeiler von Scrum ist das sogenannte »Timeboxing«. Das heißt, dass Meetings oder auch Sprints stets nur mit einer maximalen möglichen Dauer abgehalten werden dürfen und dann auf jeden Fall beendet werden müssen. Dies dient dazu, endlose Meetings oder auch Projektverspätungen bei Sprints zu vermeiden. Scrum hat einen stark explorativen Charakter, und daher ist es wichtig, nach einer bestimmten Zeit »Schluss« zu machen, um feststellen zu können, welche Ergebnisse erreicht wurden. Im Fall des Sprint Planning Meetings werden zwei Meetings von jeweils maximal vier Stunden Dauer angesetzt, die beide ihren eigenen Zweck verfolgen.



Phase 1

Im ersten Meeting präsentiert der Product Owner seinem Team den aktualisierten und priorisierten Product Backlog und erklärt auf Anfrage alle Details, die notwendig sind, damit sich jedes Teammitglied einen Teil des Backlogs für den folgenden Sprint aussuchen kann. Bei der Wahl ist das Team an die Priorisierung gebunden, es darf also keine Punkte für den folgenden Sprint wählen, die eine niedrigere Priorisierung haben. Allerdings steht es allen Teilnehmern frei, von Punkten mit gleicher Priorisierung einige auszusuchen und andere für den nächsten Sprint zu übergehen. Wichtig ist, dass es ihnen überlassen wird, wie viele Punkte sie aus dem Produktstrukturplan (PBS) für den folgenden Sprint auswählen, da sich das Team als Ganzes auf die Zielerreichung verpflichten soll und dies nur möglich ist, wenn es mit den Vorgaben auch einverstanden ist. Die vom Team ausgewählten Punkte werden nun zwischen Team und Product Owner im Detail besprochen, sodass am Ende des Meetings jedem Teilnehmer das Ziel der nächsten Iteration ganz klar sein sollte.

Phase 2

Im zweiten Meeting bespricht das Team die Umsetzung der im ersten Meeting ausgewählten Punkte aus dem PBS. Die Teilnehmer sind wieder dieselben, jedoch ist der Product Owner diesmal nur als Informationsgeber mit dabei, falls das Team in der Planungsphase des kommenden Sprints weitere Fragen zu den ausgesuchten Punkten aus dem PBS hat. Zweck dieses Meetings ist es, alle Arbeitspakete, die zur Zielerreichung notwendig sind, zu definieren, zu notieren, zeitlich einzuschätzen und dann den einzelnen Teammitgliedern des Scrum- Teams zuzuweisen. Als Ergebnis liegt am Ende des Meetings der Sprint Backlog vor, der den Projektplan für die kommenden Wochen darstellt. Wichtig ist, dass dieser Sprint Backlog täglich vom Scrum-Team gepflegt wird sowie neue Arbeitspakete, die oft noch hinzukommen, auch wirklich erfasst und geschätzt werden.

Zusammenfassung:
Der Sprint Backlog ...

  • wird erstellt durch das Team im Sprint Planning Meeting.
  • enthält alle Tasks des Sprints mit Zeiteinschätzung.
  • ändert sich im Laufe des Sprints.
  • Verbleibende Arbeitszeit wird täglich aktualisiert.
  • Tasks werden abgeleitet aus Product Backlog.
  • Tasks werden durch Team eingeschätzt.


Der Sprint

Der Sprint Backlog steht, und jetzt kann endlich entwickelt werden. Wie im Schaubild zu sehen, gehen wir nun in den Sprint über, der in der Scrum-Definition mit 30 Kalendertagen angesetzt wird. Dies kann aber je nach Projekt angepasst werden. So arbeiten viele Teams mit Sprintphasen von nur ein oder zwei Wochen, um die Iterationen noch enger zu fassen und schneller auf neue Erkenntnisse und Änderungen reagieren zu können. Das ist zum Beispiel bei komplizierter Technologie oder auch bei KI-Sprints üblich und angebracht. Der Sprint ist wie die beiden Meetings »Time Boxed « und endet auf jeden Fall nach 30 Tagen. Egal, ob das Sprint-Ziel erreicht wurde oder nicht, am Ende steht ein »Increment of Product Value«, also eine voll funktionsfähige und prüfbare Version, die dann durch den Product Owner im Review Meeting abgenommen werden kann. Das Scrum-Team arbeitet während dieses Sprints vollständig autonom und darf von außen nicht gestört werden. Jede Art von Einmischung ist explizit verboten, und neue Anweisungen oder Ziele zu setzen, ist völlig ausgeschlossen. Der Grund hierfür liegt in der Selbstverpflichtung des Teams, das ausgewählte Ziel zu erreichen. Wenn es legitim wäre, innerhalb eines Sprints neue Anweisungen zu erteilen, dann würde die aufgebaute Motivation unterlaufen und die Selbstverpflichtung aufgeweicht werden. Im Falle eines Falles, in dem ein externes Einschreiten unbedingt notwendig wird, kann der Sprint nur abgebrochen und dann später neu aufgesetzt werden. Wenn also ein externer Projektbeteiligter in die Entwicklung einschreiten muss, dann ist dies nur auf dem Wege eines vollständigen Sprint-Abbruchs möglich. Falls dies nicht passiert, endet nach 30 Tagen der Sprint mit dem »Sprint Review Meeting«. Für eine Rückschau und um einen kontinuierlichen Verbesserungsprozess zu erreichen, wird zum Abschluss noch ein »Sprint Retrospective Meeting« durchgeführt, in dem allgemeine Manöverkritik geäußert werden kann und die Vorgehensweise für den kommenden Sprint angepasst wird.

Zusammenfassung:
  • Entwicklung beginnt
  • Aufgeteilt in Sprints
  • Startet mit dem Sprint Planning Meeting
  • Maximale Länge: 30 Tage
  • Ergebnis ist immer ein »Increment of Product Value« / »Vertical Slice«
  • Team arbeitet während Sprint autonom und darf von außen nicht gestört werden
  • Endet mit dem Sprint Review Meeting des Increments
  • Wird abgeschlossen mit Sprint Retrospective Meeting


Das Daily Scrum Meeting


Der empirischen Prozesskontrolle und dem Agilen Manifesto (»people and communication over processes and project management tools«) folgend, wird täglich das Daily Scrum Meeting durchgeführt. Auch dieses Meeting ist in seiner Dauer beschränkt, und zwar auf lediglich 15 Minuten, in denen jedes Teammitglied des Scrum- Teams drei Fragen beantworten muss:

  • Was wurde seit dem letztem Daily Scrum Meeting erreicht?
  • Was soll bis zum nächsten Daily Scrum Meeting erreicht werden?
  • Was behindert meine Arbeit?

Das Daily Scrum Meeting dient dazu, den täglichen Status festzustellen und soll für eine teamweite Transparenz sorgen, sodass mögliche Probleme schnell aufgedeckt werden können und jeder über den Status der anderen Teammitglieder Bescheid weiß. Die Aufgabe des Scrum- Masters ist es nun, die genannten Probleme anzugehen und bei der Lösung zu helfen. Teilnehmen kann in diesem Meeting jeder interessierte Projektbeteiligte – sprechen dürfen aber nur die Mitglieder des Scrum-Teams. Alle anderen Teilnehmer haben absolutes Redeverbot.

Zusammenfassung:
  • Tägliches Meeting
  • Time Boxed: 15 Minuten
  • Jedes Teammitglied beantwortet:
    - Was wurde seit dem letztem Daily Scrum erreicht?
    - Was soll bis zum nächsten Daily Scrum erreicht werden?
    - Was behindert meine Arbeit?
  • Dient zum täglichen Sync des Teams untereinander
  • Scrum-Master kümmert sich um die genannten Probleme


Ergebnis des Sprints und das Review Meeting

Nach 30 Tagen wird der Sprint beendet; auch dann, wenn die Ziele nicht oder nicht vollständig erreicht wurden. Vor allem am Anfang der Scrum-Einführung verschätzen sich die Teams für gewöhnlich gnadenlos und wählen viel zu viele Punkte aus dem Product Backlog aus, sodass sie am Ende nur einen kleinen Teil der vorgenommenen Aufgaben für die Abnahme präsentieren können. Dies ist ein völlig normaler Verlauf, und die Schätzungen werden von Sprint zu Sprint besser. Denn der Scrum-Prozess hilft den Teams, die eigene Einschätzung zu verbessern und früher oder später realistische Ziele zu wählen. Der Sprint wurde also beendet und das Sprint Review Meeting angesetzt. Hierfür bereitet das Team die Ergebnisse, die erreicht werden konnten, vor und präsentiert diese dem Produkt Owner sowie allen anderen interessierten Beteiligten. Der Produkt Owner prüft die einzelnen Punkte im Detail und nimmt diese als erfüllt ab. Falls die im Sprint erreichten Ergebnisse nicht den Erwartungen entsprechen sollten, lehnt er das jeweilige Ergebnis ab und schickt es in die nächste Iteration. Dieses Meeting vollendet den Demming Circle (siehe Abbildung 3) und stellt sicher, dass der Auftraggeber immer am Puls des Projektes ist und die Entwicklung nicht in eine falsche Richtung läuft. Schließlich zahlt der Auftraggeber für das Produkt und hat damit das Recht, die Ergebnisse einzufordern. Zusammenfassung: Ergebnis des Sprints ist ein »Increment of potentially shippable product functionality«. Gewählte Backlog Items sind am Ende des Sprints. vollständig funktionsfähig vollständig getestet vollständig refactored vollständig den Guidelines und Konventionen des Unternehmens entsprechend Das Ergebnis stellt einen Vertical Slice dar.


Burndown Graph

Alle Arbeitspakete werden am Anfang des Projekts zeitlich eingeschätzt und dann zu einer gesamten Arbeitszeit addiert. So weiß das Projektteam, wie viel Arbeitszeit für den Sprint noch zu erbringen ist und kann jederzeit überprüfen, ob es in der Zeit liegt oder nicht. Hierfür dient der »Burndown Graph«. Täglich wird die Anzahl der noch benötigten Arbeitsstunden errechnet und als Chart in eine Kurve eingezeichnet. So wird der Sprint-Verlauf anschaulich gemacht, und es lässt sich gut abschätzen, ob das Sprint-Ergebnis erreicht werden wird oder nicht. Für die maximale Transparenz im Team sollte dieser Burndown Graph zusammen mit dem täglich aktualisierten Sprint Backlog im Intranet jedem zugänglich gemacht oder gar am schwarzen Brett ausgehängt werden. Am Gefälle des Graphen kann sogar die Sprint-Geschwindigkeit abgelesen werden – als Indikator für den Verlauf der aktuellen Iteration.

Zusammenfassung:
Der Burndown Graph ...

  • visualisert die Summe der noch zu erledigenden Arbeit für den Sprint.
  • wird abgleitet aus dem Sprint Backlog.
  • sollte immer öffentlich im Intranet oder auf einer Tafel zugänglich sein.
  • ist ein Indikator dafür, ob das Sprintziel geschafft wird.
  • gibt Auskunft über die Geschwindigkeit (»Velocity«) des Fortschritts.


Skalierung eines Scrum-Projekts

Am Anfang wurde bereits erwähnt, dass ein Scrum-Team aus fünf bis neun Mitarbeitern besteht. Ist Scrum also für größere Projekte ungeeignet? Nein, Scrum ist selbst für sehr große Projekte geeignet, jedoch muss das große Ganze in kleinere Teilprojekte aufgeteilt werden. Dies ist die Skalierung im Scrum-Prozess. Durch Analyse des Project Backlog werden einzelne, in sich geschlossene Bereiche identifiziert; für jeden dieser Bereiche werden einzelne Scrum-Teams gebildet. So kann ein großes Projekt auch mal aus fünf, zehn oder mehr Scrum-Teams bestehen. Es arbeitet also eine große Anzahl an Scrum-Teams an ihren jeweiligen Zielen – und das parallel. Um diese einzelnen Scrum-Teams zu koordinieren, findet vergleichbar mit dem Daily Scrum Meeting zusätzlich das »Scrum of Scrums»-Meeting statt, in dem die Scrum-Master der jeweiligen Teams sich zusammensetzen und den Status sowie die Probleme der einzelnen Teams besprechen und koordinieren.

Zusammenfasssung:
  • Ein Scrum-Team sollte aus maximal neun Mitgliedern bestehen.
  • Große Projekte werden daher aufgeteilt in verschiedene Teilprojekte.
  • Jedes Scrum-Team bearbeitet einen Teil des Projekts.
  • Koordinierung wird abgewickelt über »Scrum of Scrums«, dem täglichen Daily Scrum der Scrum-Master.


Aufgrund des begrenzten Umfangs des vorliegenden Artikels ersetzt diese kurze Einführung in Scrum nicht die Lektüre eines entsprechenden Fachbuches. Falls Sie neugierig geworden sind, empfehle ich ein Studium des Buchs »Agile Project Management with Scrum« von Ken Schwaber oder »Agile Estimating and Planning« von Mike Cohn.
Christopher Schmitz

Zum Autor: Christopher Schmitz ist bei Ubisoft als Executive Producer tätig. Er begann seine Laufbahn in der Spielebranche vor 19 Jahren und übernahm unter anderem verschiedene leitende Positionen im Bereich Programmierung und Projektmanagement bei Firmen wie 10tacle Studios, CDV oder TDK und hat sich hierbei auf Projektmanagement-Methoden spezialisiert. Er ist gelernter Betriebswirt und Mitglied der International Project Management Association (IPMA).