Lesedauer 5 Minuten

Obwohl der Begriff Scrum (engl. »Gedränge«) aus dem Rugby stammt, und es hier auch um Sprints gehen wird, dreht sich dieser Artikel nicht um Sport. Stattdessen geht es um ein agiles Vorgehensmodell in der Produktentwicklung – eben das Scrum Framework.

Doch was steckt dahinter?

Gefahren des Wasserfalls

Die klassische Wasserfall-Methode der Produktentwicklung läuft leider allzu oft auf Folgendes hinaus: Die Entwickler agieren innerhalb einer Black Box, um die Punkte des Lasten- und Pflichtenhefts zu verwirklichen. Gleichzeitig gehen Kunden und Auftraggeber auf Tauchstation, um erst am Ende zu reklamieren, was alles nicht passt.

Dann lassen sich Änderungswünsche jedoch meist nur noch mit großem Aufwand und noch größeren Kosten umsetzen. Agiles Vorgehen führt dazu, dass geänderte Anforderungen rechtzeitig geäußert werden und sich dann vergleichsweise unproblematisch realisieren lassen.

Wichtig: Agil bedeutet nicht, sofort auf jeden Zuruf zu reagieren. Auch hier gibt es klare Abläufe und Rollen, die respektiert werden müssen. Selbst wenn ein Auftraggeber die Telefondurchwahl eines Entwicklers kennt, darf er sich nicht mit jedem Anliegen direkt an ihn wenden. Und schon gar nicht sollte der Entwickler auf so einen Zuruf hin aktiv werden müssen.

Was ist Scrum?

Scrum ist kein vorgegebener Prozess und keine Methode. Es bietet jedoch einen Rahmen – ein Framework – innerhalb dessen die Beteiligten frei agieren. Festgelegt sind nur:

• 3 Rollen
• 3 Artefakte
• 4 (wiederkehrende) Ereignisse

Rollen

Team

Das Team wird auch als Umsetzungsteam bezeichnet und umfasst jene Leute, die direkt am Produkt arbeiten. Das sind nicht nur Entwickler und Designer, sondern auch Planer (»Architekten«) oder Tester. Letztlich zählt jeder zum Team, der selbst Hand anlegt.

Dabei wird das Team nach außen hin als Einheit betrachtet. Alle arbeiten mit, alle übernehmen Verantwortung. Bei Problemen wird nicht »der eine Schuldige« angeprangert, sondern es stehen alle dafür gerade.

Wichtig: Das Team ist selbstorganisiert. Vorgegeben ist nur ein Ziel, aber wie das Team daran arbeitet, ist seine Sache. Störungen von außen (Stichwort: Durchwahl zum Entwickler) sind unerwünscht.

Product Owner

Während das Team den fachlichen und technischen Erfolg eines Projekts verantwortet, ist der Product Owner für die geschäftliche Seite zuständig.

Selbst wenn ein Auftraggeber zufällig eines Mitglieds des Entwicklungsteams habhaft wird, sollte er das nicht als Gelegenheit sehen, seine aktuellen Wünsche zu besprechen. Dafür ist der ausschließlich Product Owner zuständig. Mit ihm wird über das Produkt gesprochen, er kommuniziert mit Kunden wie auch mit der eigenen Geschäftsführung.

Seine Aufgabe ist, es, die Anforderungen zu sammeln und, gemeinsam mit den Kunden, eine Priorität der einzelnen Punkte festzulegen. Und wenn das Team Ergebnisse liefert, ist er der Erste, der sie inspiziert und akzeptiert oder ablehnt.

Der Product Owner ist also die Schnittstelle zwischen dem Team und der Außenwelt.

Scrum Master

Der Scrum Master ist die Hand im Hintergrund. Seine Aufgabe ist es, das Scrum-Framework am Laufen zu halten. Er plant die Meetings und sorgt dafür, dass sie auch wirklich stattfinden. Gleichzeitig achtet er auch darauf, dass die (im Folgenden beschriebenen) Artefakte gepflegt werden.

Bei Konflikten im oder mit dem Team wird er aktiv. Dabei handelt er aber nicht Vorgesetzter oder ist gar mit disziplinären Kompetenzen ausgestattet. Stattdessen ist er Mentor und Coach, Mediator und Moderator.

Auch um Störungen oder Blockaden von außen kümmert er sich. Forderungen direkt ans Team, die am Product Owner vorbei gestellt werden, sind ein Beispiel dafür. Aber auch »von oben« verordnete Veränderungen wie z. B. das Abziehen eines Mitglieds kann das Team blockieren. Die Aufgabe des Scrum Masters ist es, solche Probleme anzusprechen und Lösungen zu schaffen.

An keiner anderen Rolle zeigt sich deutlicher, dass Scrum von allen Beteiligten akzeptiert werden muss, um zu funktionieren. Denn letztlich steht ein Scrum Master auf verlorenem Posten, wenn etwa die Geschäftsführung das selbstorganisierte Arbeiten des Teams nicht akzeptieren will.

Der Sprint

Der Sprint bezeichnet einen fixen Zeitraum, der eine Iteration des Scrum-Frameworks abbildet. Bewährt haben sich dafür zwei bis drei Wochen. Längere Zeiträume würden es nur erschweren, rasch – also agil – auf Veränderungen zu reagieren.

Am Ende des Sprints soll ein auslieferbares Produkt-Inkrement stehen, das an den Kunden weitergegeben werden kann.

Artefakte

Product Backlog

Das Product Backlog vereint gewissermaßen Pflichten- und Lastenheft in sich. Dabei werden alle Wünsche, Aufgaben und Features in möglichst kleine Teilaufgaben unterteilt.

Den Aufwand für die einzelnen Aufgaben schätzt das Team ab. Dabei spricht auch nichts dagegen, die Punkte noch weiter zu verkleinern. Z. B. könnte von der Aufgabe, ein Navigationsmenü zu erstellen, die darin enthaltene Suchfunktion als eigene Teilaufgabe abgespalten werden.

Die Hauptverantwortung für das Backlog trägt aber der der Product Owner. Er befüllt es gemeinsam mit den Auftraggebern und reiht die Punkte auch nach ihrer Wichtigkeit.

Sprint Backlog

Das Sprint Backlog ist eine Teilmenge des Product Backlogs. In ihm legen Product Owner und Team gemeinsam fest, was innerhalb eines Sprints erledigt werden soll, um an dessen Ende ein Produktinkrement zu erhalten.

Produktinkrement

Das Produktinkrement ist das Ergebnis eines Sprints. Es ist ein Teilaspekt des geplanten Endprodukts, der aber für sich selbst betrachtet funktionstüchtig ist. Obwohl es sich dabei um nichts Großes handeln muss, sollte es einen gewissen Mehrwert bieten. Ein Produktinkrement für einen Webshop könnte beispielsweise in der Möglichkeit bestehen, Artikel in den Warenkorb zu legen. Bezahl-Funktion und andere Features würden dann in späteren Sprints geliefert.

Auf diese Weise können Kunden und Auftraggebern bereits frühzeitig und gezielt Kritik und Wünsche äußern.

Ereignisse (Meetings)

Sprint Planung

Gemeinsam mit dem Product Owner legt das Team zu Beginn des Sprints fest, was umzusetzen ist, um das nächste Produktinkrement zu erhalten. Dabei liefert der Product Owner lediglich die Priorisierung, während das Team anhand der Aufwandsabschätzungen entscheiden, wie viel im Rahmen des Sprints schaffbar ist. In gewisser Weise wird ein »Vertrag« geschlossen: Das Team verpflichtet sich dazu, die Aufgaben auch wirklich zu erledigen. Im Gegenzug wird der Product Owner es vermeiden, mittendrin plötzlich mit neuen Wünschen auf der Matte zu stehen.

Sprint Review

Am Ende des Sprints wird das gelieferte Produktinkrement unter die Lupe genommen.

Wichtig: Hier werden auch Kunden in die Pflicht genommen. Denn sie müssen die Ergebnisse begutachten und sich dazu äußern. Erkenntnisse, die auf diesem Weg gewonnen werden, finden nun ebenso ihren Niederschlag im Product Backlog wie neue Wünsche.

Zwischenspiel: Backlog Refinement

Ein Backlog Refinement Meeting ist zwar kein expliziter Teil des Scrum-Frameworks, sollte aber bei Bedarf angesetzt werden. Wenn das Review zu Änderungen am Backlog führt, ist es oft nötig, dass die Aufgaben neu priorisiert und gewichtet werden. Dies erledigen Product Owner und Umsetzungsteam gemeinsam.

Daily Scrum

Das Standup-Meeting ist wohl der Punkt im Scrum, der nach außen am sichtbarsten ist. Täglich, möglichst zur gleichen Zeit, berichten treffen sich Product Owner und Umsetzungsteam und berichten über ihre Arbeit:

• Woran wurde gearbeitet und was wurde geschafft?
• Was ist bis zum nächsten Meeting geplant?
• Gibt es Probleme? (Da könnte ggf. der Scrum Master gefordert sein.)

Das Meeting sollte nicht länger als 15 Minuten dauern und, damit keiner Lust hat, es unnötig in die Länge zu ziehen, im Stehen abgehalten werden. Bei diesem Treffen geht es nicht um Problemlösungen, sondern nur um Transparenz für alle Beteiligten.

Sprint Retrospektive

Um Problemlösungen darf es in der Sprint Retrospektive gehen. Team, Product Owner und Scrum Master treffen sich, um den letzten Sprint Revue passieren zu lassen:

• Was ist gut gelaufen?
• Was ist nicht gut gelaufen?
• Welche Blockaden gab es?
• Wie können sie beseitigt werden?

Dadurch sollen die Prozesse innerhalb des Scrum-Frameworks verbessert und optimiert werden.

Kann das klappen?

Ja, es kann. Aber es braucht guten Willen von allen Seiten. Zum einen muss akzeptiert werden, dass ein Entwicklungsteam sich selbst organisiert. Mit Geschäftsführern und Managern, die zu Mikromanagement neigen, wird die Einführung vermutlich eine Herausforderung.

Auf der anderen Seite steht die Einbindung von Kunden und Auftraggebern. Für diese kann es eine neue Situation sein, alle zwei Wochen mit neuen Produkt-Versionen konfrontiert zu sein und sich damit befassen zu müssen. Doch letztlich werden auch sie davon profitieren, schon frühzeitige Ausblicke auf das fertige Produkt zu erhalten.