Das Scrum Framework

Scrum ist ein Framework für das Projektmanagement von Projekten im komplexen Umfeld. Also besonders dann für Dich interessant, wenn Deine Projekte so aussehen, dass Du ständig das Gefühl hast, Deinen Projektplan anpassen zu müssen, weil entweder die Stakeholder ständig neue Anforderungen an Dein Projekt haben oder das Umfeld Deiner Projekte sich permanent ändert.

Klassische Projektmanagementmethoden passen nicht zu Deiner Welt. Sie brauchen Konstanz. Also vergiss Deinen Projektplan mit Gantt Chart, Pflichten- und Lastenheft für eine Weile und lies hier von einer hoffentlich hilfreichen Alternative aus der Welt der agilen Methoden.

Die Grundidee von Scrum ist ganz einfach. Man kann den gesamten Prozess übersichtlich auf einem einzigen Bierdeckel skizzieren! Ich habe das oben auf dieser Seite einfach mal gemacht. Wir gucken uns das jetzt gemeinsam an:

Im Zentrum des Prozess-Bildes siehst Du eine Art Schleife. Sie symbolisiert den sogenannten Sprint. Das ist ein Zeitraum von mindestens einer und maximal vier Wochen. Das Projekt wird iterativ bearbeitet. Also Sprint für Sprint vervollständigt.

Oben Links steht eine Person, die im Scrum Prozess für die Anforderungen an das Projekt zuständig ist. Der Product Owner – kurz PO genannt. Der PO sammelt von allen Stakeholdern die Anforderungen an das Projekt ein und notiert diese in einer langen Liste. Dem Product Backlog. Für dieses Backlog ist der PO verantwortlich. Er kennt also alle Anforderungen an das Projekt aus erster Hand und notiert sie in Form von Aufgaben so, dass auch andere sie verstehen können.

Diese Aufgaben werden im Product Backlog so angeordnet, dass ganz oben die Aufgaben stehen, die als erstes erledigt werden sollen. Je weiter unten eine Aufgabe im Product Backlog steht, desto weniger dringend muss sie umgesetzt werden. Deshalb sind auch die dringendsten Aufgaben – also die, die voraussichtlich in den nächsten Sprints umgesetzt werden – deutlich präziser und detaillierter formuliert, als die Aufgaben weit unten auf der Liste. So vermeidet der PO unnötige Detailarbeit in Anforderungen zu stecken, die bis zur Umsetzung ohnehin vermutlich noch ein paar Mal geändert werden.

Der PO kennt zwar alle Anforderungen, kann sie aber nicht selbst umsetzen. Dafür gibt es das Development Team. In der Skizze ist es innerhalb der Sprint Schleife dargestellt. Das Team heißt immer Development Team, auch dann wenn Dein Projekt kein Projekt für Entwickler ist. Das liegt daran, dass Scrum ursprünglich für Software-Entwickler entwickelt wurde. Es besteht aus mindestens drei und höchstens neun Personen. Ein noch kleineres Team hätte vermutlich nicht alle Fähigkeiten in sich vereint, um das Projekt umsetzen zu können. Bei mehr als neun Personen steigt die Komplexität der Beziehungsgeflechte zwischen allen Teammitgliedern so sehr, dass sie nicht mehr produktiv zusammenarbeiten können.

Eine Sache ist besonders an diesem Team: Es ist selbstorganisiert! Es gibt niemanden, der ihm sagt, was es zu tun hat. Was das heißt? Lies weiter!

Jeder Sprint beginnt mit einem Meeting. Dem Planning Meeting. In diesem Meeting kommt das gesamte Scrum Team zusammen. Der Product Owner vereinbart mit dem Development Team ein Ziel für den Sprint. Das Ziel beschreibt, was am Ende des Sprints anders ist, als vorher. Also welcher Kundennutzen erzielt werden soll.

Außerdem stellt er dem Development Team die im Product Backlog enthaltenen Aufgaben vor. Das Team wählt daraus in absteigender Reihenfolge der Priorität so viele Aufgaben, wie es meint im kommenden Sprint umsetzen zu können. Es bestimmt also selbst, mit welchen Aufgaben es den nächsten Sprint füllen möchte. Es verpflichtet sich, diese selbst gewählten Aufgaben umzusetzen und so das Sprint-Ziel zu erreichen.

Mit den Aufgaben aus dem Planning Meeting füllt das Development Team ein eigenes Backlog. Das Sprint Backlog. Im Gegensatz zum Product Backlog, für das der Product Owner verantwortlich ist, ist für das Sprint Backlog das Development Team verantwortlich. Im Sprint Backlog ist also dokumentiert, was das Development Team zu liefern verspricht. Es ist für die Dauer des Sprints fixiert! So limitiert das Team die zu leistende Arbeit – die „Work in Progress“.

Während des Sprints bearbeitet das Team sämtliche Aufgaben aus dem Product Backlog. Damit alle Teammitglieder immer wissen, wer gerade woran arbeitet und wie der Fortschritt der Bearbeitung der Aufgaben ist, trifft es sich täglich zur selben Zeit am selben Ort zu einem kurzen Meeting. Das Daily Standup findet im Stehen statt und dauert maximal 15 Minuten. Das Team tauscht sich darin darüber aus, wer gerade woran arbeitet. Welche Fortschritte gemacht werden und wo es Schwierigkeiten gibt. So kann sich das Team gegenseitig unterstützen.

Eine Rolle im Scrum Team habe ich noch nicht beschrieben. Der Scrum Master unterstützt das Team, indem er ihm Methodenwissen vermittelt. Außerdem moderiert er die Termine, die der Scrum Prozess vorsieht und schützt das Team vor Störungen von außen, zum Beispiel davor, dass ein Stakeholder versucht am PO vorbei zusätzliche Aufgaben im Sprint zu platzieren, die das Team nicht im Planning Meeting zugesagt hat. Kurz: Er sorgt dafür, dass im Scrum Prozess alles im Sinne der Scrum Idee läuft.

Das hier ist natürlich nur die Kurzfassung.

Am Ende des Sprints liefert das Development Team die zugesagten Aufgaben ab. Das Product Increment. Durch diese Lieferung sollte das Sprint-Ziel erreicht worden sein.

Im Review Meeting präsentiert das Development Team allen Interessierten die im Sprint erreichten Ergebnisse. Eingeladen sind nicht nur alle Mitglieder des Scrum Teams, sondern auch Stakeholder und andere interessierte Kollegen. Der Product Owner entscheidet in diesem Meeting, ob er das vom Development Team gelieferte „potentiell auslieferbare Produkt“ tatsächlich an die Kunden ausliefert. Eventuell entscheidet er auch, dass noch ein oder mehrere weitere Sprints nötig sind, bis das Produkt tatsächlich ausgeliefert werden kann. Es geht aber nicht darum, dass die Kunden nur ein perfektes und komplett fertiges Produkt ausgeliefert bekommen sollen. Es ist absolut im Sinne der Scrum Idee, den Kunden auch frühe, prototypische Varianten des Produktes zur Verfügung zu stellen. Anhand des darauf erhaltenen Feedbacks kann dann das Product Backlog für die nächsten Sprints angepasst werden.

Den Abschluss des Sprints bildet nach dem Review Meeting die Retrospektive. An ihr nimmt ausschließlich das Scrum Team, also Development Team, Product Owner und Scrum Master, teil. Sie wird vom Scrum Master moderiert. Sie hat das Ziel, dem Team eine Chance zu geben, aus der Vergangenheit für die Zukunft zu lernen. Nach der Retrospektive beginnt direkt der nächste Sprint mit seinem Planning Meeting.

Soweit mein Versuch, Scrum kurz und knapp zu beschreiben. Willst Du es genauer wissen, kannst Du den Scrum Guide lesen. Er beschreibt die exakte Definition von Scrum.

Insbesondere dann, wenn sich das Team voll auf ein Projekt konzentrieren kann und wenn die Anforderungen oder das Umfeld des Projektes sich häufig verändern und komplex sind, kann Scrum seine volle Stärke ausspielen. Wenn Du überlegst, Scrum in Deinem Team einzusetzen, sorge bitte dafür dass das Team von jemanden unterstützt wird, der Erfahrungen damit hat! Ohne Unterstützung ist die Wahrscheinlichkeit groß, das etwas entsteht, was zwar nach Scrum aussieht, aber nicht wirklich nützlich ist.

Vielleicht fragst Du Dich jetzt, wie Dir eine Methode helfen kann, die mit Aufgabenpaketen umgeht, die über einen Zeitraum von einigen Wochen stabil sind. Du hast doch permanent neue Themen, die im Scrum Prozess eine Störung darstellen würden! Nächste Woche stelle ich Dir Kanban vor. Das könnte in so einer Situation eine gute Alternative zu Scrum sein.

Wenn Dir mein Blog gefällt, teile den Artikel gerne mit Deinen Kontakten! Hast Du eine Frage, Anregung oder Ergänzung, dann nutze die Kommentarfunktion hier im Blog.