Teil 3: Agiles Projektmanagement – Scrum

Teil 3: So funktioniert Scrum

Im zweiten Teil der RFC Blogreihe zum agilen Projektmanagement haben wir uns mit dem Begriff „Agiles Projektmanagement“ beschäftigt. Dabei ging es um die agilen Werte und Prinzipien, sowie die agilen Techniken und Methoden. Aber was steckt eigentlich hinter dem Begriff Scrum und wie funktioniert eine der bekanntesten agilen Methoden? Diese Frage wollen wir in diesem Blog beantworten.

Bei Scrum geht es darum, Rahmenbedingungen für ein System zu schaffen, in dem viel Platz für Interaktion und benutzerdefinierte Anpassungen ist. Damit verbunden sind häufige Aktualisierungen und Umpriorisierungen von Anforderungen. Als Indikation für eine agile Vorgehensweise nach Scrum steht also ein dynamisches Umfeld mit instabilen Anforderungen und sich ändernden Rahmenbedingungen, oder sogar Projektzielen. Mit den Gründen, die immer häufiger ein agiles Vorgehen erfordern, haben wir uns ja bereits im 1. Blog beschäftigt (siehe Blogübersicht am Ende des Blogs).

Die Scrum-Rollen

Im Mittelpunkt von Scrum steht das selbstorganisierte Entwicklerteam, das ohne Projektleiter auskommt und direkt mit dem Produktverantwortlichen zusammenarbeitet. Die Selbstorganisation ist aber durchaus streng organisiert, im Sinne von klaren Rahmenbedingungen. Ein Entwicklerteam umfasst idealerweise interdisziplinär und Architekturschichten-übergreifend alle erforderlichen Fähigkeiten zur Produktentwicklung. Jedes Team hat genau einen Product Owner und einen Scrum Master. Die optimale Größe des Entwicklungsteams (ohne Product Owner und Scrum Master) liegt zwischen drei und neun Mitgliedern: klein genug, um ohne zu viel Koordinationsaufwand schnell und flexibel zu sein und groß genug, um alle wichtigen Arbeiten innerhalb eines Sprints eigenständig erledigen zu können.

Der Scrum-Master unterstützt als Methodenexperte das Entwicklerteam und den Product Owner dabei, Scrum richtig anzuwenden und die Arbeitsabläufe, die Arbeitsorganisation und die Kommunikation zwischen allen Beteiligten kontinuierlich zu verbessern. Er sorgt dafür, dass das Team ungestört in den Entwicklungszyklen (Sprints) arbeiten kann. Er ist für die Dokumentation und Beseitigung von Hindernissen bzw. Störungen aller Art (Impediments) zuständig, die während der Arbeit auftreten und einzelne Team-Mitglieder oder auch das gesamte Team an der effektiven Erledigung ihrer Aufgaben hindern.

Der Product Owner (Produktverantwortliche) gibt die Produktvision vor, die den Zweck und Kontext sowie das Projektziel des zu entwickelnden Systems bestimmen. Er hat die Aufgabe, alle Produktanforderungen – also einzelnen Funktionen und Anwendungsfälle – zu sammeln und zu definieren, sowie unter Einbeziehung der Interessen und Bedürfnisse aller relevanten Stakeholder zu priorisieren. Er verantwortet die fachlichen Entscheidungen und den wirtschaftlichen Nutzen der Produktentwicklung.

Die Anforderungen

Kaum etwas anderes steht beim Übergang zu agiler Vorgehensweise mehr im Weg als Perfektionismus. Die gezielte Unvollkommenheit (besser: Steuerung der Verständnistiefe) als notwendigen Optimierungsschritt zu akzeptieren, ist ein nicht selbstverständlicher Lernschritt. Die Anforderungen an das Projekt und damit auch die (potentiellen) Aufgaben für das ausführende Team, ergeben sich aus den sogenannten User Stories, die im Product Backlog gesammelt und priorisiert werden. Das Product Backlog enthält somit alle bekannten Anforderungen an das zu entwickelnde System. Große Anforderungen werden im agilen Framework als Epic (Arbeitsbereich) bezeichnet und vom Product Owner in kleinere User Stories zerlegt.

Für verschiedene Zwecke werden typischerweise ganz unterschiedliche Verständnistiefen der Anforderungen benötigt. Zu Beginn reicht eine relativ geringe Verständnistiefe aus, damit das Team die Aufwände in einer gewünschten Sicherheit beziehungsweise Genauigkeit schätzen kann. Der Product Owner kann dann neben dem geschäftlichen Mehrwert der Anforderung zusätzlich auch die Schätzung als Kriterium zur Priorisierung heranziehen. In regelmäßig stattfindenden Backlog Refinement-Meetings stellt der Product Owner dem Team (neue) User Stories vor, die idealerweise die sogenannten INVEST-Kriterien erfüllen sollten:

• • I – Independent (unabhängig):

Eine User Story soll unabhängig von anderen User Stories sein, damit diese unabhängig voneinander umgesetzt werden können.

• • N – Negotiable (verhandelbar):

Die Beschreibung einer User Story erfolgt zunächst nur grob. Sie dient Product Owner, Stakeholder und Entwicklerteam als Diskussionsgrundlage, um ein optimales Verständnis für die Anforderung zu erzielen. Die genaue Ausformulierung erfolgt später im Team.

• • V – Valuable (nützlich):

User Stories ohne Mehrwert sollen erst gar nicht umgesetzt werden.

• • E – Estimable (schätzbar):

Eine User Story sollte von der Größe her überschaubar bleiben. Das Team mun, Aufwände für die Realisierung zu schätzen.

• • S – Small (klein):

Eine User Story sollte grundsätzlich in einem Sprint realisierbar sein. Ist das nicht der Fall, dann ist es besser, diese nochmals in kleinere User Stories aufzusplitten.

• • T – Testable (testbar):

Jede User Story muss testbar sein, ansonsten kann sie nicht abgenommen werden. Hierbei geht es nicht darum, die gesamte Produktfunktionalität zu testen, sondern nur den vom Product Owner in der User Story explizit beschriebenen Umfang (Akzeptanzkriterien).

Durch eine gemeinsame Diskussion werden die User Stories hinterfragt und ausgearbeitet, um Klarheit zu schaffen (nur das „was“ wird hinterfragt und nicht das „wie“). Es werden Abhängigkeiten identifiziert, Rahmenbedingungen und Akzeptanzkriterien definiert und Aufwandsschätzungen vorgenommen. Dieser Termin liefert eine Indikation über die Größe vom Product Backlog bzgl. Gesamtaufwand und verkürzt das zu Sprintbeginn stattfindende Sprint Planning, da sich das Team bereits in den Backlog Refinement Meetings mit den User Stories beschäftigt hat.

Abbildung 1: Darstellung SCRUM-Vorgehen

Die Vorgehensweise

Im Gegensatz zum Wasserfall-Modell wird das Projekt nicht anhand eines langfristigen Plans durchgeführt, sondern mit Hilfe sogenannter Sprints, also kurzen Bearbeitungszyklen, in denen jeweils eine oder mehrere Anforderungen umgesetzt, getestet und mit „Produktionsreife“ abgeschlossen werden. Optimalerweise dauert ein Sprint maximal bis zu vier Wochen. Beim agilen Ansatz wird die Zeit (Sprints) am Projektanfang (fest) definiert (Time-Boxing), wobei die Ressourcen ein limitierender Faktor sind.

Zu Beginn jedes Sprints findet als Kick-Off das Sprint Planning statt. Das Team wählt anhand der vorgegebenen Liste eine realistische Anzahl an User Stories aus (Sprint-Backlog), um diese dann umzusetzen. Dabei dominiert auch innerhalb eines Sprints die flexible Herangehensweise. In täglichen, kurzen Meetings, den sogenannten Daily Scrums, werden die erledigten Aufgaben des vergangenen Tages bilanziert und die nächsten Schritte besprochen, sodass eine maximale Anpassungsfähigkeit gewährleistet ist. Am Sprintende präsentiert das Team im sogenannten Sprint-Review dem Product Owner und interessierten Stakeholdern die neue Produktfunktionalität. Die Teilnehmer begutachten die Sprintergebnisse und der Product Owner nimmt die fertiggestellten User Stories nach den definierten Akzeptanzkriterien ab. Nach jedem Sprint findet abschließend eine Sprint-Retrospektive im Projektteam statt, in der Verbesserungsvorschläge und Änderungswünsche besprochen und aufgrund der flexiblen Vorgehensweise in den nächsten Sprint aufgenommen werden können. Dies führt schnell zu einer effizienteren Arbeitsweise und einem besseren Projektergebnis.

Gegenüberstellung Wasserfall mit Scrum

In der nachfolgenden Tabelle erfolgt abschließend noch einmal eine Gegenüberstellung, von klassischer Vorgehensweise (Wasserfall) und der agilen Methode Scrum:

Abbildung 2: Tabelle – Wasserfall/klassisch vs. Scrum/agil

Fazit:

Scrum ist verhältnismäßig einfach zu lernen, lässt sich schnell einsetzen und kann somit den ersten Schritt darstellen, um Entwicklungsprojekte agil zu machen. Darüber hinaus definiert Scrum klare Rollen und einen gut strukturierten, aber dennoch flexiblen Entwicklungsprozess, mit hoher Transparenz bzgl. des Fertigstellungsgrades. Es lässt die Möglichkeit offen, Besonderheiten und Erfahrungen des eigenen Projektes zu berücksichtigen und sich so seinen individuellen Scrum-Prozess zu erarbeiten.

Dennoch ist es nicht immer ganz einfach bzw. häufig unbequem, agile Methoden erfolgreich einzuführen und auch durchzuhalten. Denn dazu muss man sich von alten Gewohnheiten trennen, neue Wege auskundschaften und immer wieder überprüfen, wie man sich noch weiter verbessern kann.

Ausblick:

Im vierten Teil der RFC Blogreihe zum agilen Projektmanagement wird die Frage beantwortet: Was ist Kanban. Wir beschäftigen uns mit den wesentlichen Unterschieden zwischen den beiden agilen Methoden Scrum und Kanban.

______________________________________________________________________________