Ist Scrum etwas für uns?

Annäherung an eine neue Idee

Scrum will help you to fail in thirty days or less.

Ken Schwaber, Softwareentwickler

Wenn herkömmliche Methoden nicht funktionieren, warum es dann nicht auf eine ganz andere Weise versuchen? Diese Frage beschäftigte die beiden US-Amerikaner Ken Schwaber und Jeff Sutherland. Herausgekommen ist ein neues Vorgehensmodell – die Scrum-Methode.

Der englische Begriff »Scrum« stammt aus dem Rugby und bedeutet übersetzt soviel wie »dichtes Gedränge«. Gemeint ist das Gedränge, das entsteht, wenn sich im Rugby die Spieler um den Ball versammeln. Hinter der Rugbymetapher steht die bittere Erkenntnis, dass Einzelkämpfer in starren Strukturen mit ihren festen Plänen den heutigen Anforderungen von Schnelligkeit und Flexibilität nicht mehr gewachsen sind. Wenn hingegen ein Team gemeinsam als Einheit einen Weg zurücklegt und sich dabei wie beim Rugby den Ball hin- und herspielt, besteht eine gute Aussicht auf Erfolg.

Ken Schwaber und Jeff Sutherland stellten 1995 auf der OOPSLA, einer jährlich abgehaltenen Forschungskonferenz, erstmals eine Definition von Scrum vor. Im Kern beinhaltet sie, starre Projektpläne durch einfache Rollen, Regeln und Methoden der Zusammenarbeit zu ersetzen.

Scrum ist ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können. Es versetzt sie in die Lage, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.

Scrum wird heute meist von Softwareentwicklern genutzt, doch das Prinzip und die gewonnenen Erkenntnisse treffen auf alle Arten von Teamwork zu. Darin liegt einer der Gründe, weshalb die Methode so beliebt ist.

Man darf Scrum nicht rein mechanisch als Prozess verstehen, dem man blind zu folgen hat. Im Unterschied zum klassischen Projektmanagement, das sich als fester Prozess versteht, bietet Scrum ein Framework an – also einen Rahmen, der es ermöglicht, die agilen Prinzipien in der Projektarbeit zu leben. Die ursprüngliche Definition kann man deshalb wie folgt abwandeln:

Scrum ist ein Rahmenwerk für die Zusammenarbeit von Teams. Es basiert auf einer Definition von Rollen, Meetings und Werkzeugen, die einem Team Struktur und einen klar definierten Arbeitsprozess geben. Dieser wiederum basiert auf agilen Prinzipien.

Diese Abkehr von einem fest vorgegebenen Prozess hat vor allem einen entscheidenden Vorteil: Man bleibt offen gegenüber neuen Einsichten oder Ideen – den eigenen genauso wie denen des Kunden. Anstatt vorab definierte Pläne abzuarbeiten, ermöglicht es das Scrum-Prinzip, Prioritäten zu ändern und damit auch das Projektergebnis anzupassen.

Der Kern der Scrum-Methode lässt sich so beschreiben: Das Team kann sich selbst organisieren. Seine Mitglieder setzen sich interdisziplinär zusammen, damit möglichst viele Kompetenzen abgedeckt werden. Kennzeichnend für den Ablauf sind kurze, vorhersagbare Entwicklungszyklen, an deren Ende jeweils eine neue funktionierende Version des Produkts steht. Auf diese Weise steigert man Schritt für Schritt nicht nur die Qualität des Produkts, sondern gewinnt auch das Vertrauen des Kunden.

Die Scrum-Methode kommt mit nur wenigen Regeln aus. Im Gegensatz zur Steuererklärung passt der generelle Ablauf tatsächlich auf einen Bierdeckel, wie Niklas dem erstaunten Tom an der Hotelbar demonstrierte (Abbildung 3).

Am Anfang steht eine Vision des Produkts, das entstehen soll – etwa einer neuen Steuerungssoftware wie im Projekt von Tom. Aus der Vision werden konkrete Eigenschaften des Produkts abgeleitet, die der »Product Owner« im »Product Backlog« auflistet und priorisiert. Da er für den ökonomischen Erfolg des Produkts verantwortlich ist, geht er dabei nach wirtschaftlichen Gesichtspunkten vor. Das heißt vor allem: Er legt fest, in welcher Reihenfolge die Einträge im Product Backlog abgearbeitet werden.

Die Produktentwicklung erfolgt iterativ, das heißt in festen Abschnitten von gleicher Länge, meist zwei bis vier Wochen. Diese Abschnitte werden »Sprints« genannt, die sich quasi die Klinke in die Hand geben: Das Ende des einen bildet den Anfang des nächsten Sprints.

Für die Umsetzung der im Product Backlog gesammelten Produkteigenschaften ist das »Entwicklungsteam« zuständig. Der Product Owner bestimmt somit, was bei einem Sprint entwickelt werden soll, während sich das Entwicklungsteam darum kümmert, wie es entwickelt wird.

Damit dieses Zusammenspiel klappt, braucht es eine enge Abstimmung...