Das Scrum Framework – Oder: „A project is what happens while you’re busy making Plans“

Kurz gefasst: Viele Projekte sind zu komplex, um sie vor Projektbeginn bis ins Detail planen zu können – zu viele Unbekannte, zu viele Schätzungen hindern die Projektverantwortlichen daran, konkrete Aussagen zu treffen. In diesem Beitrag lest ihr, wie die agile Scrum-Mathode dieses Problem für bestimmte Projekte lösen kann.

Ken Schwaber beschrieb es als einer der ersten öffentlichen Vertreter auf einer Konferenz wie folgt: „Scrum akzpeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und Qualität.“¹

Seine Wortwahl macht es deutlich: Ursprünglich wurde Scrum für Entwicklungsprojekte von Softwareprodukten eingeführt. Das Scrum Framework ist aber auch auf andere Projekte übertragbar.

Eigenverantwortung und learning by doing

Was ist Scrum also nun? Es handelt sich dabei um einen agilen Projektmanagement-Ansatz, der auf die Eigenverantwortung der Projektbeteiligten setzt. Es gibt ein übergeordnetes Ziel und das Scrum Framework, das es einzuhalten gilt. Agile Projektmanagement-Methoden ermöglichen eine Aufteilung der Reportingpflichten, die allen Projektbeteiligten in die Karten spielt: Weniger Aufwand für einzelne Mitarbeiter,

Scrum sieht vor, dass die Projektmitarbeiter ihr Ziel auf ihre Weise erreichen, Probleme auf ihre Art lösen und aus gemachten Erfahrungen lernen. Somit zählen ein funktionierendes Teamwork und kontinuierliches Lernen zu den wichtigsten Erfolgsfaktoren des Scrum Ansatzes.

Iterative Abgleiche der Plan- und Ist-Daten nach einzelnen Arbeitsabschnitten erleichtern allen Beteiligten, Ressourcenbedarfe immer präziser zu konkretisieren.

Die wichtigsten Begriffe im Scrum Framework

Product Owner: Der Scrum Product Owner ist für das Projektergebnis und dessen wirtschaftlichen Erfolg zuständig. Aus seiner Feder stammen die definierten Endergebnisse des Projektes. Er behält zudem den Überblick über den Projektfortschritt und die Kosten.

Entwicklungsteam: Das Entwicklungsteam ist für die operativen Aufgaben zuständig und hat dabei die Aufgabe, vordefinierte Qualitätskriterien einzuhalten. Dabei verfolgt es das Ziel, die im Product Backlog definierten Ziele zu erfüllen – allerdings ohne Vorgaben, wie diese Ziele erarbeitet werden sollen. Das Entwicklungsteam handelt somit völlig eigenverantwortlich, jedoch mit einer Konkreten Zielvorgabe.

Scrum Master: Der Scrum Master arbeitet mit dem Entwicklungsteam, allerdings nicht operativ. Er ist dafür zuständig zu gewährleisten, dass das Scrum Framework eingehalten wird. Sobald softe oder harte Faktoren zu einer Störung der Abläufe führen, greift der Scrum Master ein, beseitigt Kommunikationsfehler oder Konflikte und gewährleistet so optimale Arbeitsbedingungen. Anstelle einer Führungskraft mit Weisungsbefugnis ist der Scrum Master als ein Coach für das Entwicklungsteam zu verstehen.

Scrum Team: Umfasst den Scrum Master, das Entwicklungsteam und den Scrum Product Owner.

Daily Scrum: Tägliche kurze Zusammenkunft, bei dem sich vor allem das Entwicklerteam austauscht und einen Überblick über den aktuellen Arbeitsfortschritt gibt. Entstehen im Daily Scrum Fragen, die nicht auf die Schnelle Beantwortet werden können, werden diese an den Scrum Master übergeben, der damit für ihre Klärung zuständig wird.

Epic: Grobe Anforderungsbeschreibungen des Projektes.

User Stories: Einzelne Anwendungsberichte, aus denen sich ein Epic zusammensetzt.

Product Backlog: Langfristiger Plan in Form eines flexiblen Dokuments, das kontinuierlich angepasst und optimiert wird. Das Product Backlog enthält alle Anforderungen an das Endergebnis, die vom Scrum Team definiert werden.

Sprint: Ein Arbeitszyklus. Im Gegensatz zu den flexiblen Vorgaben, die das Product Backlog enthält, sind die Vorgaben für den Sprint einzuhalten. Sprints können Zeitabschnitte von einer bis vier Wochen umfassen. Alle Sprints eines Projektes sollten etwa gleich lang sein.

Sprint Backlog: Detailplan, der immer nur jeweils für einen Sprint erstellt wird und der innerhalb des Sprints einzuhalten ist.

Fazit: Wann ist Scrum sinnvoll?

Die agile Methode eignet sich für Teams mit bis zu 9 motivierten, kompetenten Projektmitarbeitern, die die nötige Initiative zeigen und eigenverantwortlich auf ein Ziel hinarbeiten. Bei Teams ab 10 Mitarbeitern sollten verwandte Ansätze angewandt werden, die auf eine größere Personenanzahl ausgelegt sind.

Der agile Ansatz ermöglicht den Projektbeteiligten, ihre Angaben zum Projekt in kürzeren Abständen zu hinterfragen und zu korrigieren. So fördert Scrum die Eigeninitiative und nimmt gleichzeitig die Angst davor,  vorab entgültige Zahlen für die Umsetzung eines Projektes zu nennen.

¹Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 19.