Guide: Agiles Projektmanagement mit Scrum

Effektiver Prozess mit klarer Struktur: Scrum zählt nicht ohne Grund zu den derzeit bekanntesten und beliebtesten Projektmanagement-Methoden. Durch die agile Vorgehensweise wird Stück für Stück ein funktionierendes Produkt erstellt, bei dem Änderungen und Verbesserungen kontrolliert miteinfließen und so einen kontinuierlichen Fortschritt ermöglichen.

Die Arbeit erfolgt dabei in multidisziplinären Teams, durch die Projekte schneller und effizienter umgesetzt werden können. Regelmäßige Feedbacks und ein eigenes Wertesystem fördern eine enge Zusammenarbeit und machen Scrum mit seiner Flexibilität und Anpassungsfähigkeit auch für Fachgebiete abseits der Softwareentwicklung interessant.

Scrum ist ein Framework für agiles Projektmanagement, das vornehmlich in der Softwareentwicklung eingesetzt wird, aber auch im Rahmen der Organisation und bei der Entwicklung innovativer Produkte und Dienstleistungen verwendet wird. Dabei wird ein iterativ-inkrementeller Ansatz verfolgt, das bedeutet, mit jeder zeitlich begrenzten Iteration (den sogenannten Sprints) wird ein fertiges und benutzbares Teilstück des Gesamtproduktes („Iteration“) entwickelt.

Bei den Iterationen handelt es sich normalerweise um kurze Zeitabschnitte, die sich in einem Rahmen zwischen einer Woche und einem Monat bewegen, und innerhalb derer das Team die notwendigen Arbeiten für die Herstellung von funktionsfähigen Elementen erledigt, die anschließend in die Produktion überführt werden. Die beteiligten Teams sind interdisziplinär zusammengesetzt und organisieren sich während des Prozesses selbst, das bedeutet, dass sie auch mehrere Aufgaben übernehmen können.

Richtung und Gesamt-Ziel des Projektes sind bei Scrum zwar vorgegeben, durch die hohe Flexibilität und Anpassungsfähigkeit (z.B. bei kurzfristigen Veränderungen) können die einzelnen Weg-Abschnitte von den Teams aber völlig frei gestaltet werden.

Der Begriff „Scrum“ stammt ursprünglich aus dem Rugby-Sport und bezeichnet den Neustart eines Spieles nach einer kleinen Regelverletzung. Die Anfänge der gleichnamigen Projektmanagement-Methodik lassen sich bis ins Jahr 1986 zurückverfolgen: In Ihrem Artikel „The New New Product Development Game“ (Harvard Business Review) beschreiben die beiden japanischen Professoren Ikujiro Nonaka und Hirotaka Takeuchi einen teambasierten, skalierbaren Ansatz für eine ganzheitliche Produktentwicklung, mit dem Konzerne wie Canon, Fuji oder Honda beeindruckende Ergebnisse erzielen konnten.

Darauf aufbauend beschäftigten sich die US-Softwareentwickler Ken Schwaber und Jeff Sutherland in den frühen 90igern (erst unabhängig voneinander und später gemeinsam) mit der Frage, wie Produkte insgesamt schneller und flexibler entwickelt werden konnten.

2001 erschien mit „Agile Software Development with Scrum“ das erste Buch über Scrum, das aus einer Zusammenarbeit von Ken Schwaber und Mike Beedle entstand. 2003 legte Schwaber als Solist mit „Agile Project Management with Scrum” nach, und bildete im gleichen Jahr auch den ersten zertifizierten Scrum-Master aus. In seinem dritten Buch “The Enterprise and Scrum” befasste er sich dann nicht mehr nur mit der Einführung von Scrum in Development-Teams sondern dem Rollout im  kompletten Unternehmen.

Die Zusammenarbeit in einem agilen Projekt ist auch immer eine Frage der Einstellung. Um kontinuierliche Lernprozesse anzustoßen, basiert Scrum auf einem Wertesystem, das zur Übernahme von Verantwortung und eigenständigem mitdenken auffordert.

Die fünf Werte von Scrum sind:

Dabei sollten nicht alle Werte blind verfolgt werden, obwohl sie gleichwohl natürlich alle Ihre Berechtigung haben. Sie stellen lediglich ein Rahmenwerk dar, das von Handlungsmöglichkeiten bis hin zu konkreten Handlungsanweisungen reicht, und tragen so in Kombination zu mehr Erfolg im Team und einer effizienteren Arbeitsweise bei.

Die oben genannten Werte besagen, dass eine unzureichende Flexibilität in Bezug auf die Prozesse und die Zeitplanung sowie eine mangelhafte Kommunikation nicht zu einem Erfolg des Projektes führen können. Scrum konzentriert sich hingegen auf den Entwicklungsprozess von Produkten mit dem Ziel einer größtmöglichen Kundenzufriedenheit bei einer maximalen Wertschöpfung und passt sich durch seine agile Vorgehensweise kontinuierlich an Veränderungen an.

Im Vergleich zu anderen Projektmanagement-Framworks ist Scrum ein echtes Leichtgewicht, das lediglich aus

besteht, die wir Ihnen im folgenden Abschnitt noch einmal detailliert erklären.

Ein Scrum-Projekt besteht in der Regel aus einem oder mehreren Teams, die sich wiederum jeweils aus den drei Scrum-Rollen zusammensetzen:

Der Product Owner ist in der Scrum die zentrale Anlaufstelle für alle Anliegen, die die Produktentwicklung betreffen. Er übernimmt die fachliche Führung und vertritt die Auftragegeberseite und die Stakeholder. Der Product Owner entscheidet, wie die Funktionalitäten und Eigenschaften des Produktes auszusehen haben und in welcher Reihenfolge sie geschaffen werden.

Er trägt außerdem die Verantwortung hinsichtlich der Qualität und muss dafür sorgen, dass die Arbeiten immer Zeit bestmöglich ausgeführt werden. Der Product Owner arbeitet eng mit dem Scrum Master und dem Entwicklungsteam zusammen und muss jederzeit für Rückfragen zur Verfügung stehen.

Die Hauptaufgaben und Verantwortlichkeiten des Product Owners sind:

Der Scrum Master ist die vielschichtigste Rolle innerhalb eines Scrum-Teams. Er hilft allen Beteiligten, die Werte, Prinzipien und Praktiken von Scrum anzunehmen und einzuhalten, damit die Dynamik des agilen Prozesses ihnen am Ende nicht um die Ohren fliegt.

Die Rolle des Scrum Masters ist klar getrennt von der des Product Owners, die beiden Rollen arbeiten aber eng zusammen bzw. unterstützen sich gegenseitig bei ihren Aufgaben.

Für die Rolle des Scrum Masters kommen nur Personen in Frage, die über eine ausgezeichnete Expertise in Scrum verfügen, da sie ein breites Spektrum an Tätigkeiten beinhaltet.

Die Hauptaufgaben und Verantwortlichkeiten des Scrum Masters sind:

Das Entwicklungsteam ist für die Umsetzung des Projektes verantwortlich und besteht in der Regel aus fünf bis neun Entwicklern und Fachkräften, deren Aufgabe die Lieferung der vom Product Owner definierten Funktionalitäten in der festgelegten Reihenfolge ist.  

Das Entwicklungsteam organisiert sich selbst, um den besten Weg für die Zielerreichung zu ermitteln und muss dazu in der Lage sein, die Sprintziele auch ohne Abängigkeiten von anderen Teilnehmern zu erreichen.

Die Zusammenstellung erfolgt cross-funktional, das bedeutet, das Generalisten mit Spezialisten (z.B. Programmierern, Architekten, Datenbankadministratoren etc.)

durchmischt werden. Dadurch können die Teammitglieder Ihre unterschiedlichen Fähig- und Fertigkeiten in das Projekt einbringen und sich bei Bedarf auf bestimmte Aufgabenbereiche spezialisieren.

Die Hauptaufgaben und Verantwortlichkeiten des Entwicklungsteams sind:

Die Artefakte dienen in Scrum zur Steuerung, zur Bewahrung des Überblickes und der Erreichung einer maximalen Transparenz beim Austausch von Schlüsselinformationen innerhalb des Projektes.

Das Product Backlog ist eine geordnete Liste aller Anforderungswünsche, die in Zusammenarbeit mit den internen und externen Stakeholdern erstellt wird, und das zu entstehende Produkt reflektiert. Es liegt gänzlich in der Verantwortung des Product Owners und entwickelt sich zusammen mit dem Produkt oder Projekt kontinuierlich weiter, das bedeutet, dass es niemals wirklich vollständig ist.

Das Product Backlog setzt sich aus einzelnen Backlog Items (z.B. User Stories, Epics, Spezifikationen oder Bugs) zusammen, die die Anforderungen aus Kundensicht und in einer für diesen verständlichen Sprache beschreiben. Die Punkte werden nach wirtschaftlichem Nutzen, Risiko, Aufwand und Notwendigkeit priorisiert, wobei die am höchsten gewichteten ganz oben auf der Liste stehen.

Beim Sprint Backlog handelt es sich um eine Liste, die während des Sprint Plannings erstellt wird und in der Verantwortung des Entwicklungsteams liegt. Sie enthält alle Backlog Items, die für den aktuellen Sprint ausgewählt wurden, sowie die dazu gehörenden Tasks und kann während des laufenden Sprints jederzeit erweitert oder ergänzt werden.

Das Sprint Backlog gibt fortlaufend den Stand der vom Entwicklungsteam geplanten Arbeiten wider, die zur Erreichung des Sprintziels noch geleistet werden können. Es stellt somit eine Art Realtime-Reporting-Tool für das Projekt und die Team-Mitglieder dar.  

Das Inkrement (deutsch: „vergrößern“ oder „Zuwachs“) ist ein Teilergebnis des Projektes, das am Ende eines Sprints in einem nutzbaren (auslieferbaren) Zustand sein muss und der Definition of Done entspricht. Es enthält die Summe aller Product Backlog Einträge, die im Sprint umgesetzt wurden.

Last but not least werfen wir noch einen Blick auf die fünf Aktivitäten in Scrum. Diese laufen jeweils in einem festgelegten Zeitrahmen, den sogenannten „Timeboxes“ ab.

Wie bereits erwähnt, basiert Scrum auf einem iterativ-inkrementellen Vorgehensmodell, das sich durch regelmäßige und wiederholbare Arbeitschritte auszeichnet, die wiederum aufeinander aufbauen. Diese zeitlich beschränkten Interationen oder Zyklen werden als Sprints bezeichnet und können von wenigen Tagen bis zu einem Kalender-Monat reichen. Sie haben immer ein festes Start- und Enddatum und folgen nahtlos aufeinander.

Ziel eines Sprints sind die Entwicklung, Erstellung und das Testen eines funktionsfähigen Zwischenproduktes (Inkrement).

Beim Sprint-Planning kommen die Mitglieder des Scrum Teams (Product Owner, Scrum Master, Entwicklungsteam) zusammen, um die Aufgaben für den kommenden Sprint zu besprechen und zu planen. Bei einem vierwöchigen Sprint beträgt die Timebox für die Planung maximal acht Stunden und setzt sich aus zwei gleich langen Teilen zusammen:

Das Daily Scrum ist ein täglich stattfindendes Status-Meeting zwischen den Mitgliedern des Scrum-Teams mit einer Dauer von höchstens 15 Minuten. Es findet immer zur selben Zeit am selben Ort statt und dient zur Abstimmung und Synchronisation der Arbeiten innerhalb des aktuellen Sprints und zur Überprüfung der Ziel-Erreichbarkeit.

Die Mitglieder des Entwicklungsteams beantworten im Daily Scrum die folgenden drei Fragen:

Das Sprint Review findet immer am Ende eines Sprints statt und dient zur Präsentation und Abnahme der Sprint-Ergebnisse. Die neuen Funktionalitäten des Produktes werden detailliert anhand der Abnahmekriterien erläutert und demonstriert.

Neben dem Scrum Team kommen hier auch zukünftige Anwender, Investoren, Vertreter des Managements und andere Stakeholder zusammen, um sich über den Projektverlauf zu informieren, Feedback einzuholen oder Änderungswünsche einzubringen. Ideen für weitere Funktionalitäten werden von allen Beteiligten gemeinsam besprochen.

Nach dem Sprint Review und vor dem nächsten Sprint Planning steht die Retrospektive. Dabei überprüft das Scrum Team seine bisherige Arbeitsweise und bekommt Gelegenheit, diese zu untersuchen und gegebenenfalls zu adaptieren. Der Fokus liegt dabei auf der kontinuerlichen Prozessverbesserung und der Steigerung von Effizienz und Effektivität in den zukünftigen Sprints.

Die in der Sprint Retrospektive erarbeiteten Maßnahmen werden geplant und dokumentarisch festgehalten. Bei einem vierwöchigen Sprint sollte sie maximal 3 Stunden beanspruchen.

Scrum ist ein agiles Verfahren zur Entwicklung komplexer Systeme, das dafür ausgelegt ist, sich schnell an Veränderungen anzupassen. Dadurch können neue Ansätze und Ideen sehr zeitnah umgesetzt werden, in der täglichen Praxis erfordert das aber eine gewisse Konsequenz. Als Kombination von Planbarkeit und agilen Ansätzen ist Scrum aber durchaus eine gute Alternative zu den etablierten Projektmanagement-Methoden, die mit ihrer Flexibilität auch mehr dem modernen Zeitgeist entspricht.