Scrum

Scrum ist eine bewährte Methode für die Schrittweise Entwicklung innovativer Produkte und Dienstleistungen. Eine minimale Kombination aus Rollen, Events und Artefakten bestimmen die grundlegenden Vereinbarungen zur Entwicklung agiler Organisation mit Scrum. Durch ihr Zusammenspiel stellen sie die Transparenz sowie ständige Überprüfung und Anpassung sicher.

Scrum gehört zu den agilen Methoden, die entstanden noch bevor Agilität im Zusammenhang mit Projektführung überhaupt ein Begriff wurde. Jeff Sutherland und Ken Schwaber, die Entwickler von Scrum, prägten diesen als Mit-Autoren des Agilen Manifests.

Scrum-Guide

Die Regeln von Scrum sind im Scrum-Guide festgehalten. Das Dokument ist in vielen Sprachen kostenlos online abrufbar und umfasst keine zwanzig Druckseiten. Es ist nicht schwierig, die Mechanik von Scrum zu verstehen. Das Regelwerk definiert lediglich drei Rollen, fünf Events und eine Handvoll Artefakte als Repräsentation der Arbeitstätigkeit. Damit reduziert es sich selbst auf die wesentlichen Aspekte effektiver Produktentwicklung. Dadurch bleibt ein weitreichender Spielraum (und Bedarf), die eigene Praxis vielseitig zu ergänzen.

Diese einfache Konstruktion dient dazu, den Scrum-Dreisatz aus Transparenz, Überprüfung und Anpassung in einer Projektorganisation zu festigen. Scrum wird deine organisatorischen Probleme nicht beseitigen, sondern erst sichtbar machen. Die Frage ist, wie du darauf reagierst.

Eine naheliegende und gerne praktizierte Reaktion liegt darin, unliebsame Elemente davon freimütig an die eigene Realität anzupassen: «Bei uns läuft das halt anders!» Dadurch vergibt man sich eine golden Chance, die eigene Arbeitsweise zu reflektieren und als Organisation zu lernen. Die resultierende Form der Zusammenarbeit ist im Ergebnis meistens unproduktiver und unbefriedigender als zuvor. Der Scrum-Guide grenzt sich von diesem Zugang entsprechend klar ab: Es steht allen frei, diese für sich anzupassen – das Ergebnis ist dann nicht Scrum.

Agile Organisation mit Scrum ist nicht für jeden Betrieb das Richtige und auch wenn es passt, wird die Umsetzung nie vollständig oder perfekt sein. Das muss sie auch nicht. Der Wert von Scrum liegt gerade darin, die bestehenden Muster periodisch zu hinterfragen und Verbesserungen zu finden.

Werte

Im Zentrum der Zusammenarbeit mit Scrum steht die Orientierung an den fünf Grundwerten. Die Methode ist darauf ausgerichtet, Teams dabei zu helfen, diese Werte täglich zu leben.

Rollen, Artefakte und Events

Die Regeln von Scrum sind im Guide auf wenigen Seiten umfassend erklärt. Die Regeln umfassen lediglich eine Handvoll an Rollen, Artefakten und Events.

Rollen

Am Anfang steht ein kleines Team, das Scrum-Team. Seine Mitglieder arbeiten in gemeinsamer Verantwortung und gegenseitiger Unterstützung an ihrem Produkt oder ihrer Dienstleistung. Im Scrum-Team sind drei Rollen vertreten:

• Ein Team-Mitglied bringt als Product-Owner:in die Perspektive der Produkt-Gestaltung ein. Dazu gehört die Zusammenarbeit mit den unterschiedlichen Anspruchsgruppen ebenso wie Analyse und Priorisierung der Kund:innenerwartungen. Die oder der Product-Owner:in stellt dadurch sicher, dass das Team seine Zeit optimal einsetzt und zu jeder Zeit an den wichtigsten Aufgaben arbeitet.
• Ein anderes Team-Mitglied sichert als Scrum-Master:in die effektive und reibungslose Zusammenarbeit im Team. Als Team-Coach unterstützt sie oder er die Kommunikation und Entscheidungsfindung im Team und auch nach aussen.
• Alle anderen Team-Mitglieder werden als Entwickler:innen bezeichnet und verantworten die kreative und sachgemässe Umsetzung des hochwertigen Produkts. Weitere Rollen-Unterscheidungen, welche die unterschiedlichen Spezialisierungen der Entwickler:innen abbilden, werden nicht gemacht.

Artefakte

Zu Beginn einer jeden Iteration wählt das Scrum-Team aus einer priorisierten Sammlung diejenigen Aufgaben, die sie in der neuen Iteration umzusetzen planen. Das Ergebnis davon wird eine neue Version des Produkts sein, die bereit zur Auslieferung ist.

• Diese neue Version wird als Produkt-Inkrement bezeichnet
• Die Aufgaben werden im Produkt-Backlog festgehalten, aus dem auch ersichtlich wird, welche davon als nächste anstehen
• Der Sprint-Backlog repräsentiert den Arbeitsvorrat des Teams für eine Iteration und bildet damit die für einen erfolgreichen Abschluss relevanten Aufgaben ab

Der einzige Weg von einem Kund:innenbedürfnis zu einer entsprechenden Verbesserung an Produkt oder Dienstleistung führt damit vom Produkt-Backlog über den Sprint-Backlog zu einem neuen Produkt-Inkrement. Das Scrum-Team arbeitet niemals an Aufgaben, die auf anderem Weg zu ihm gelangten.

Events

Die laufende, reibungslose Kommunikation im Team und darüber hinaus ist unabdingbare Voraussetzung für gelingende Zusammenarbeit. Die Scrum-Events unterstützen diese, ersetzen aber nicht den inhaltlichen Austausch im Sprint-Verlauf. Dieser kann ad-hoc, in geplanten Besprechungen, durch regelmässige Meetings oder schlicht im Rahmen von Peer-Programming stattfinden.

• Als Sprint wird in Sprint die oben schon erwähnte Iteration bezeichnet. Ein Sprint dauert nicht länger als vier Wochen und bildet sowohl den stabilen Takt der Zusammenarbeit als auch den vereinbarten Rahmen der kreativen Produkt-Entdeckung durch die Entwickler:innen.
• Der Sprint beginnt mit dem Sprint-Planning, an dem das Ziel des Sprints festgelegt und die dafür relevanten Aufgaben aus dem Product-Backlog in den Sprint-Backlog übernommen werden.
• Der Sprint endet mit der Sprint-Review. Hier stellt das Scrum-Team sich selbst und anderen Interessierten den aktuellen Stand der Entwicklung vor. Die Planung des folgenden Sprints erfolgt auf der Grundlage der hier vorgestellten und erarbeiteten Informationen.
• Das Scrum-Team trifft sich täglich zum Daily Scrum, einer bewusst sehr knapp gehaltenen Abstimmung über den Stand der Dinge und die gemeinsamen Pläne bis zum nächsten Tag.
• Einmal in jedem Sprint hält das Scrum-Team im Rahmen einer Retrospektive Rückschau, um die gemeinsame Arbeit zu untersuchen und Verbesserungsschritte vorzunehmen.

Scrum anwenden

Scrum ist nicht schwierig und kann von jedem Team verwendet werden. Das ist insbesondere dann sinnvoll, wenn sich in einem Team bisher keine funktionierenden Arbeitsabläufe eingespielt haben. Scrum entstand in der Software-Entwicklung, hat sich inzwischen aber in jeder Art kreativer Arbeit bewährt. Zwei Kardinalsfehler werden dabei immer und immer wieder gemacht:

• Teams werden dazu gezwungen oder motiviert, Scrum einzusetzen
• Scrum-Regeln werden an die eigenen Besonderheiten angepasst

Jeder dieser Fehler genügt, um die Umsetzung zum Misserfolg zu führen. Wenn aber ein Team aus Überzeugung und mit Konsequenz nach seiner Scrum-Umsetzung sucht, bilden die oben zusammengefassten Regelungen ein stabiles und erprobtes Grundgerüst. Auch nach Jahren finden Scrum-Teams beim erneuten Lesen des Scrum-Guides zuverlässig wertvolle Anregung, wie sie ihre Arbeit weiter verbessern können.

Scrum anpassen

Selbstverständlich ist es so, dass jede Organisation ihre Eigenheiten hat; ebenso jedes Team und ohnehin seine Mitglieder als Menschen und Fachleute. Das Hinterfragen und die bewusste Anpassung von Regeln an die individuellen Bedürfnisse ist so richtig wie notwendig.

Scrum regelt einige wesentliche Aspekte der Arbeitsorganisation mit einer beneidenswerten Klarheit. In der gegen dreissigjährigen Geschichte seiner Entwicklung floss eine Menge Erfahrung in dieses Regelwerk. Wenn Teams sich aus der eigenen Situation heraus dazu entschliessen, einzelne Aspekte nicht zu berücksichtigen, beschädigen sie dadurch das austarierte Zusammenspiel.

Mehrere Teilzeit-Product-Owner; ein Scrum-Master für zwei Stunden die Woche; quartalsweise Retrospektiven; Sprints von 12 Wochen und dergleichen mehr. Die gängigen Anpassungen richten sich nicht darauf aus, den organisatorischen oder individuellen Bedürfnissen besser zu begegnen. Vielmehr wird vermeintlich unnötiger Aufwand an als ineffizient angenommene Regelungen eingespart. Die Grundlage dieser Einschätzung ist häufig dünn.

Die Form ihrer Umsetzung lässt dem Team dabei viel Spielraum, um eigene Bedürfnisse oder Präferenzen einzubringen. Wenn Teams darüber hinaus gehen und ausgehend von Scrum ihre eigene Arbeitsweise entwickeln möchten, ist das legitim und oft begrüssenswert – sofern dies bewusst und aus einer tatsächlichen Verbesserung des Angebots heraus entsteht.

Scrum skalieren

Scrum ist ein Werkzeug, um im Team eine agile Form der Zusammenarbeit zu entwickeln. Es gibt verbreitete Versuche, die Mechanik davon auf die Struktur von Grossprojekt-Organisationen zu übertragen, die sich als nicht tragfähig erweist. Daraus kann keine Agilität resultieren.

Organisatorische Agilität entsteht, wenn die eigene Arbeitsweise konsequent und kontinuierlich im Hinblick auf die sich verändernden Bedürfnisse und eine ständig verbesserte Dienstleistung weiterentwickelt wird. Kanban bewährt sich in diesem Kontext wie kein anderes Werkzeug.

Scrum zu skalieren bedeutet letztlich nichts Anderes, als es auf jeder Ebene einzusetzen. Teams sind die Zellen organisatorischer Zusammenarbeit. Mit Scrum können sie sich abgrenzen, organisieren und ins Ganze einbringen.