Agiles Projektmanagement mit Scrum

Rugby-Fans kennen Scrum als feststehenden Begriff, der eine sportliche Standardsituation beschreibt. Bei dem Gedränge drängen die beiden Mannschaften aufeinander, um den eierförmigen Ball jeweils zu ihren Gunsten zu befreien. Ein komplexer Vorgang mit vielen Beteiligten. Diese führt nur dann zum Erfolg, wenn sich das gesamte Team agil bewegt und effizient zusammenarbeitet. Das gleiche Verhalten erfordert die Methode, für die Scrum als Namenspate fungiert.

Wie alle agilen Prozesse ist auch Scrum zugleich iterativ und inkrementell. Das bedeutet einerseits, dass Verbesserungen am zu entwickelnden Produkt schrittweise durchgeführt werden und andererseits, dass es in Einzelteilen entwickelt und geliefert wird. Getrennt betrachtet sind diese Arbeitsweisen nicht besonders sinnvoll. In Kombination jedoch entwickeln sie ihr volles Potenzial.

In der Praxis bedeutet dies, dass das Produkt zu Beginn nur grob definiert ist. Deshalb eignet sich Scrum gut für Produkte, deren Anforderungen zu Beginn noch nicht bis ins Detail feststehen. Typisch beispielsweise für Software-Produkte, aber eben nicht nur. Wiederkehrende Schleifen sorgen dafür, dass das Produkt kontinuierlich Form annimmt und ständig optimiert wird.

Das Scrum Framework wird aus drei Rollen, vier Ereignissen und drei Artefakten geformt, die den Kern der Methode bilden und deshalb auch Scrum Core heißen. Welche Aufgabe diese Bestandteile habe, wird im „Scrum Guide“ erklärt.

Der Product Owner ist derjenige, der das Produkt, das entwickelt werden soll, verantwortet und letztlich auch die Verantwortung für den kommerziellen Erfolg trägt. Wenn die Entwicklung nicht inhouse erfolgt, handelt es sich also um den Auftraggeber. Er bestimmt die Eigenschaften des Produkts. Er definiert konkrete Anforderungen, aus denen sich die Funktionalitäten ergeben.

Aufgabe des Product Owners ist es zu priorisieren, welche Features am wichtigsten sind und als nächstes umgesetzt werden müssen. Dafür führt er eine Art Liste, den „Product Backlog“. Dieser stellt eine der drei Artefakte dar. Die Anforderungen werden durch ihn ständig aktualisiert und verfeinert. Den Prozess der fortlaufenden Pflege des Product Backlogs bezeichnet man als Grooming.

Der Product Owner inspiziert die regelmäßig gelieferten Ergebnisse und gibt dazu sein Feedback ab, das dem Team wiederum bei der Verbesserung hilft.

Das Entwicklerteam besteht aus denen, die das Produkt aktiv erstellen und somit die vom Product Owner definierten Anforderungen umsetzen müssen. Das Team kann sich aus ganz unterschiedlichen Fachkräften zusammensetzen. Das Besondere ist, dass es keinen Teamleiter gibt. Stattdessen organisiert sich die Gruppe selbst und trägt kollektive Verantwortung.

Je kleiner die Entwicklerteams, desto effizienter können sie kommunizieren. Und genau das ist ein wichtiger Aspekt beim Scrum. Schließlich muss man die eigene Arbeit ständig reflektieren und das Produkt kontinuierlich optimieren. Deshalb sollten alle Teammitglieder möglichst nahe beieinander sein. Im Idealfall sitzt es sogar in einem gemeinsamen Teamraum. Außerdem sollten alle möglichst Vollzeit arbeiten, damit jeder stets ansprechbar ist und nichts verpasst.

Mit den Rollen sind die folgend erläuterten direkten Beteiligten beim Scrum gemeint. Die Gesamtheit der Rollen bildet das Scrum Team. Dieses tritt mit den anderen Beteiligten in Kontakt, die als Stakeholder bezeichnet werden. Als Anspruchsberechtigte nehmen sie die Rollen außerhalb von Scrum wahr.

Der Scrum Master ist am ehesten mit einem Projektmanager vergleichbar. Seine Aufgabe ist es, die Einhaltung der Scrum Regeln sicherzustellen und den gesamten Entwicklungsprozess im Unternehmen zu optimieren. Als Coach, Moderator, Mentor, Trainer und Mediator konzentriert er sich dabei weniger auf den fachlichen Aspekt, sondern vor allem auf die am Entwicklungsprozess Beteiligten. So kümmert er sich beispielsweise darum, dass die Teamarbeit möglichst effizient erfolgt.

Er unterstützt das Team beim kontinuierlichen Lernen, indem er z. B. Transparenz schafft und die Reflektion fördert. Er entfernt Barrieren, die die Produktivität beeinträchtigen und oftmals erst durch die Scrum Methode sichtbar werden. Außerdem muss er zwischenmenschliche Probleme frühzeitig erkennen und durch seine Kommunikations- und Teamfähigkeit zeitnah lösen.

In Scrum wird nicht von Meetings oder Besprechungen gesprochen, sondern von Ereignissen oder Ritualen. Damit soll die Effizienz der Methode verdeutlicht werden.

Die vier nachfolgend erläuterten Ereignisse sind Bestandteile eines Arbeitsabschnitts der Sprint genannt wird. Ein solcher dauert normalerweise zwischen ein und vier Wochen und hat zum Ziel, dass innerhalb dieses Zyklus eine bestimmte, vorher festgelegte Menge an Funktionalität (Inkrement) vom Team geliefert wird.

Ein Sprint wird niemals verlängert. Alle haben die gleiche Länge und folgen unmittelbar aufeinander. Das jeweilige Ziel wird während eines laufenden Sprints nicht geändert, sondern stets verfolgt. Lediglich der Abbruch eines Sprints durch den Product Owner ist denkbar.

Das Sprint Planning ist eine Art Planungssitzung, die zu Beginn eines jeden Sprints stattfindet. Hier beginnt die Selbstorganisation des Teams. Es definiert gemeinsam die Ziele, die am Ende des Sprints erreicht sein sollen. Dafür nimmt man sich gemeinschaftlich einen Punkt nach dem anderen aus dem Product Backlog vor und bespricht ihn im Detail. So lange, bis das Team entscheidet, dass es nun genug Arbeit für den aktuellen Sprint hat.

Dabei entsteht das Sprint Backlog, in dem das Sprint Ziel und die Planung, wie es erreicht werden soll, festgehalten werden. Während des Sprint Plannings bedient man sich häufig eines Taskboards, das der Planungsvisualisierung dient.

Das Daily Scrum findet jeden Tag zur selben Zeit am selben Ort statt und dauert nie länger als 15 Minuten. Es hilft dem Team bei der Selbstorganisation, indem es seinen Fortschritt in Hinblick auf die Erreichung des Sprint Ziels transparent macht. Jedes Teammitglied beantwortet dabei kurz und knapp drei Fragen:

• Was habe ich gestern erreicht?
• Welche Probleme hatte ich dabei?
• Was habe ich mir heute vorgenommen?

Das Team kann sich beim Daily Scrum synchronisieren und abstimmen. Der Scrum Master übernimmt die Moderation und versucht Blockaden und Hindernisse zu erkennen und zeitnah aus dem Weg zu räumen.

Die Sprint Review findet am Ende eines jeden Sprints statt. Hier präsentiert das Scrum Team seine Arbeitsergebnisse den Stakeholdern, die dazu ihr Feedback abgeben, welches wiederum in die nächsten Sprints einfließt und zu einer kontinuierlichen Produktverbesserung führt. Die neuen Anforderungen der Stakeholder werden direkt ins Product Backlog aufgenommen.

Ebenfalls nach jedem Sprint findet als letzter Schritt die Retrospektive statt. Hier wird der letzte Sprint gemeinschaftlich betrachtet um den Prozess und seinen Erfolg zu analysieren und aus den gemachten Erfahrungen zu lernen. Ziel ist es konkrete Maßnahmen abzuleiten und zu beschließen, die zukünftigen Sprints verbessern.

Während das Framework beim Scrum klar vorgegeben ist, findet die eigentliche Arbeit im Entwicklungsteam selbstorganisiert statt. Das ständige Feedback führt zur schnellen Identifizierung von Verbesserungspotenzial – nicht nur beim Produkt, sondern auch im Team. Gerade die wiederkehrenden Schleifen in Form von Sprints, die das Rückgrat von Scrum bilden, unterscheiden diese Methode von linearen Entwicklungsmethoden wie der Wasserfallmethode. Erst die Sprints ermöglichen die ständige Inspektion und Adaption, die auch bei komplexen Projekten einen kontinuierlichen Fortschritt gewährleistet – Stück für Stück.