Scrum – das kommende Framework im Projektmanagement

Scrum – das kommende Framework im Projektmanagement

Scrum ist ein Vorgehensmodell, welches vor allem in der Software-Entwicklung Anwendung findet, sich mittlerweile aber auch unternehmensweit etabliert hat. Im Gegensatz zu Modellen mit klassisch sequenziellem Ansatz, wie bspw. dem Wasserfall- oder dem Spiralmodell, beruht Scrum auf agilen, d.h. flexiblen Prozessen. Scrum geht davon aus, dass Softwareprojekte aufgrund ihrer Komplexität und den ständig fortlaufenden Anforderungen nicht im Voraus detailliert geplant werden können und bietet hier einen neuen, offenen Ansatz.

Innerhalb des Scrum-Modells gibt es drei interne Rollen:

  • Scrum Master: Dieser managt den Prozess und ist für sein Gelingen verantwortlich. Innerhalb dessen führt er bspw. die Scrum Regeln ein, leitet die Meetings und beseitigt Hindernisse und Störungen.
  • Product Owner: Der Product Owner ist für die strategische Produktentwicklung zuständig. Er stellt z.B. die fachlichen Anforderungen an die Produktvision, legt die zu entwickelnden Produkteigenschaften fest und priorisiert diese anschließend.
  • Entwicklungsteam: Das Team ist u.a. für die Lieferung der Produktfunktionalitäten verantwortlich.

Alle im Prozess beteiligten Rollen organisieren sich selbst. Es gibt keinerlei Vorgaben wer welche Aufgabe hat oder mit wem zusammengearbeitet wird. Lediglich der Scrum Master ist verpflichtet, den Selbstorganisationsprozess zu schützen. Jedoch obliegen diese drei Rollen vordefinierten Artefaktes und Meetings (dazu gehören Sprint Meeting, Daily Scrum, Sprint Review und Retrospektive). Diese Artefakte bilden den eigentlichen Scrum Prozess.

Bevor allerdings mit dem Scrum Framework begonnen werden kann, sollten einige Vorbereitungen getroffen werden, wie bspw. die Projektplanung, die Grobarchitektur und das Design. Wie bei jedem Projekt sollte ein grober Rahmen festgelegt werden, wodurch ersichtlich wird wer die Teilnehmer sind und welche Tools genutzt werden um das Projekt erfolgreich ans Ziel zu bringen. Sobald die Vorplanung steht, kann mit der eigentlichen Scrum Planung begonnen werden.

In einem ersten Meeting, welches als Sprint bezeichnet wird, erstellt der Product Owner User Stories (Nutzenbeschreibungen), die er dem Entwicklungsteam vorstellt und die im Product Backlog festgehalten werden. Die Reihenfolge der User Stories legt auch die Priorität der anstehenden Anforderungen fest, d.h. je höher eine Anforderung gelistet ist, desto höher ist auch die Priorität. Alle am Projekt beteiligten Personen tragen zur Umsetzung bei und dass nicht nur zu Beginn des Projekts, sondern auch fortlaufend. Sobald Änderungen bzw. neue Anforderungen auftreten oder gewünscht sind, werden diese übernommen. Diese grundlegende Offenheit führt zu einer hohen Adaptivität in der Entwicklung.

Anhand eines Beispiels soll das Szenario im Folgenden erläutert werden.  Ein Product Backlog kann folgendermaßen aufgebaut sein:

Priority User Storie Estimations Business Value
1 Import XML-Files 1 50
2 Single-Sign-On 13 40
3 Migration der Kundendaten 3 30
4 Javascript Performancetuning 1 10

Ein grob nach Nutzen und Aufwand priorisierter  Product Backlog ist das Ergebnis für die Release Planung. Diese Resultate dienen als Input für die Planung des nächsten Sprints.

Im ersten Sprint Meeting erläutert der Product Owner dem Team die jeweiligen User Stories. Das Team wiederum bestimmt anhand seiner bisherigen Kenntnisse und seiner Geschwindigkeit, ob die User Stories bis zum nächsten Sprint umgesetzt werden können.  Demnach wird im Sprint Planning folgendes vereinbart:

  • Ziel des Sprints, wofür sich das Team verpflichtet
  • Dauer des Sprints
  • Terminfestlegung des Daily Scrum Meeting (ein ca. 15-minütiges Treffen, dass immer pünktlich und am gleichen Ort stattfindet)

Wenn die Planung für die nächsten Sprints feststeht, werden die zugrundeliegenden User Stories in das Sprint Backlog aufgenommen, welches eine Übersicht der zu erledigenden Aufgaben für einen Sprint darstellt. Hat ein Sprint begonnen, treffen sich das Team und der Scrum Master zum Daily Scrum, im Rahmen dessen jedes Teammitglied beschreibt, wie weit die jeweiligen User Stories vorangeschritten sind. Hier werden auch etwaige Probleme und Hindernisse geklärt und ob diese bis zum nächsten Daily Scrum bewältigt werden können. Das Daily Scrum stellt keine Diskussionsplattform dar, sondern dient dem Informationstausch innerhalb des Teams.

Am Ende eines jeden Sprints erfolgt ein Review Meeting, in dem das Team dem Product Owner seine Ergebnisse vorstellt. Ebenfalls erfolgt auch die Retrospektive, welche die Zeit zwischen Review und neuem Sprint darstellt. Hier wird den Teammitgliedern die Möglichkeit gegeben über die gemachten Erfahrungen zu reflektieren und Verbesserungspotenziale für den nächsten Sprint zu identifizieren.

Wie bereits deutlich wurde, ist der Ansatz von Scrum iterativ, empirisch und inkrementell. Der größte Vorteil von Scrum ist, neue Anforderungen nach jeder Iteration, in jeden Sprint, einfließen zu lassen. Dieser offene Ansatz ermöglicht es auf Änderungen schnell und flexibel reagieren zu können. Da Scrum einen kollaborativen Ansatz hat, können zudem auch die Mitarbeiter mögliche Fehler schnell entdecken.

Nun stellt man sich vielleicht die Frage, wie sich hier die Gesamtentwicklung planen lässt (Time und Budget)? Die Antwort lautet, man kann es nicht planen. Wie bereits erwähnt, können mit dem Scrum-Modell Änderungen ständig aufgenommen werden, was eine feste Planung fast unmöglich macht. Man kann kein Kochrezept für Projekte entwerfen, jedoch aber den notwendigen Rahmen schaffen. Um eine Zeit- und Gewinnplanung vornehmen zu können wird nach dem Timeboxingverfahren gearbeitet. Das bedeutet, dass Zeit und Budget zur Verfügung gestellt wird und im Rahmen dessen ein bestimmter Vorgang innerhalb einer bestimmten Dauer abgeschlossen wird.

Ich habe die Erfahrung gemacht, dass unter Verwendung des Scrum-Modells eine höhere Motivation, Produktivität und Transparenz gefördert wird, verglichen mit den klassischen Methoden. Die Teams managen ihre Aufgaben so, dass die Team-Intelligenz besser genutzt werden kann. Es wird nicht darauf beharrt einen starren Plan einzuhalten, sondern Änderungen zuzulassen, da Abhängigkeiten zwischen den einzelnen Teams oder den Akteuren bestehen. Schwierigkeiten im Verständnis haben dabei die traditionellen Denkweisen, d.h. dass ein Backlog kein Projektplan ist und dass sich ein Releaseplan ständig ändern kann. Hier bleibt festzustellen, dass bei Scrum das funktionierende Produkt im Vordergrund steht. Ganz anders beispielsweise bei der Verwendung des Wasserfall-Modells, bei dem u.a. Prozesse, Pläne und Dokumentation stark priorisiert werden, wodurch wenig Spielraum für Innovation und Kreativität bleibt. Es wird darauf geachtet eine umfangreiche, durchdachte Dokumentation abzuliefern, welche jedoch selten umgesetzt werden kann. Erfahrungsgemäß besteht bei Dokumenten, wie z.B. Fachkonzepten immer die Gefahr, dass diese im Laufe der Zeit unvollständig werden und somit nicht mehr aktuell sind, da bspw. im Laufe des Projekts gewisse Teilfunktionalitäten hinzugekommen sind.

Wenn ich jetzt aber behaupten würde, dass jedes Projekt unter Anwendung des Scrum-Modells erfolgreich wird, wäre das nicht realistisch. Scrum kann genauso wenig wie andere Vorgehensmodelle eine Erfolgsgarantie bieten. Ein großer Vorteil liegt jedoch in der Transparenz, die dieses Modell bietet. Hierdurch ist es möglich schnell und flexibel auf Änderungen zu reagieren und auch innerhalb des laufenden Prozesses neue Erkenntnisse einfließen zu lassen – so kann das Produkt Schritt für Schritt zum Erfolg geführt werden.

Teile diese Nachricht
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •