Scrum: Regelmässig liefern und nachjustieren

Das von Ken Schwaber und Jeff Sutherland begründete Rahmenwerk Scrum basiert auf einem teambasierten, empirischen Vorgehen mit fest eingebundenen Feedback-Schleifen. Das ermöglicht es, mithilfe von ausprobieren, reflektieren und nachjustieren gemeinsam mit dem Kunden und anderen Beteiligten die passende Lösung oder das für den Kunden bestmögliche Produkt zu entwickeln.

Die Feedback-Zyklen spiegeln sich in den fünf im Scrum Guide beschriebenen Ereignissen wider:

Mit diesem schrittweisen Vorgehen, das am Ende eines jeden Sprints ein potenziell auslieferbares Teilstück, zum Beispiel einer Software, anvisiert, wachsen über die Zeit nicht nur Erkenntnisse über die Zusammenarbeit oder das Anwenderverhalten, sondern auch der Nutzen für die Anwenderinnen und User, also die Kunden.

Diese Kundenzentrierung ist elementarer Bestandteil des zugrunde liegenden Manifests für Agile Softwareentwicklung, das insgesamt betrachtet die Zufriedenheit der Kunden, eine vertrauensvolle und enge Zusammenarbeit sowie eine Konzentration auf das Wesentliche in den Vordergrund rückt. Statt ein Feature-Feuerwerk zu entwickeln, wird die Komplexität reduziert, indem zunächst die wirklich wichtigen und nutzenstiftenden Elemente entwickelt werden. Anforderungen können sich im laufenden Prozess noch ändern. Sie werden nicht am Anfang fixiert und plangesteuert abgearbeitet, sondern können sich nach und nach ergeben; lediglich während eines Sprints, der maximal vier Wochen andauert, ist die eingesteuerte Arbeit fix.

Damit die tägliche Arbeit in einem Scrum-Team gut funk­tioniert und keiner der Aspekte aus dem Blickfeld gerät, wurden für dieses Vorgehen drei verschiedene Rollen mit klarer Abgrenzung und jeweils spezifischem Fokus entwickelt. Kurz gesagt kümmert sich der Product Owner um das Was (Was wird entwickelt?), das Entwicklungsteam um das Wie (Wie kann eine Lösung aussehen?) und der Scrum Master um die Optimierung der Zusammenarbeit und des Prozesses.

Die Rollen sind ebenso wie die Ereignisse obligatorisch und müssen bei einer Einführung von Scrum von Anfang an berücksichtigt werden. Um die festgeschriebenen Rollen mit Leben zu füllen, muss Scrum als Ganzes verstanden und umgesetzt werden. Darf beispielsweise ein Product Owner nicht über sein Produkt entscheiden und agiert lediglich als Sprachrohr des Vorgesetzten oder werden im Team Probleme unter den Teppich gekehrt, so ist der Erfolg gefährdet und Scrum nur eine leere Hülle. Das bedeutet: Wer mit Scrum arbeiten möchte, muss sich auf grössere Ver­änderungen von Anfang an einstellen, den neuen Rollen ihre nötige Handlungs- und Entscheidungsfreiheit zugestehen sowie das Team selbstständig arbeiten lassen.