In Scrum und anderen agilen Vorgehensweisen und Frameworks spielt die Verantwortung eine große Rolle. Der Begriff „Verantwortung“ ist eine mögliche Übersetzung des englischen Begriffs „commitment“. Die andere Übersetzung, die ich im Zusammenhang mit agilen Vorgehensweisen gerne verwende, ist „Verpflichtung“. Beide Begriffe meinen Ähnliches, aber eben nicht dasselbe. Die Verpflichtung zielt meinem Verständnis nach in der Hauptsache auf die termingerechte Lieferung des gemeinsam festgelegten Ergebnisses ab. Verantwortung ist für mich der weitaus stärkere Begriff, umfasst er doch neben der konsequenten Ergebnisorientierung auch die Sorge für den Prozess und das Team – und noch einige andere Dinge, die ich zu einem „Scrum-Verantwortungskreis“ zusammengefasst habe:
Der Scrum-Verantwortungskreis
Verantwortung für das Product Backlog
Der Product Owner ist verantwortlich für die fachliche Beschreibung des Produkts. Der Funktionsumfang des Produkts wird durch die Backlog Items festgelegt, die gemeinsam das Product Backlog bilden. Auf die Frage, was ein „gutes“ Backlog Item darstellt, gibt es viele „richtige“ Antworten. Fest steht, dass alles, was das Produkt ausmacht, beschrieben und für das Team sichtbar und nachvollziehbar sein muss. Ob nicht funktionale Anforderungen, beispielsweise Performanz- oder Sicherheitsaspekte, als Backlog Items beschrieben werden sollen, ist letztendlich Geschmackssache. Viel wichtiger ist, dass diese Aspekte überhaupt berücksichtigt werden, oder anders ausgedrückt: dass sich jemand für diese Aspekte verantwortlich fühlt.
Verantwortung in der Schätzklausur
In der Schätzklausur bestimmt das Team die Größe der Backlog Items – nach bestem Wissen und Gewissen und in der Erwartung, dass sich die Größenschätzungen mit zunehmendem Erkenntnisgewinn verändern können. Zwei Aspekte sind beim agilen Schätzen wichtig: Zum einen schätzt das Team die Backlog Items selbst. Die Teammitglieder müssen die Backlog Items später umsetzen, deshalb sollen sie so früh wie möglich eine Vorstellung über die Inhalte dieser Items entwickeln und eine realistische Abschätzung der Größe treffen. Die Schätzung des Teams kann vom Scrum Master oder dem Product Owner nur argumentativ beeinflusst werden. Das letzte Wort hat immer das Team. Logische Schlussfolgerung: Das Team trägt die Verantwortung für dir Schätzung – was nicht bedeutet, dass der Schätzwert in Stein gemeißelt ist. Auch hier gilt: Veränderung ist etwas ganz Natürliches.
Verantwortung für das Sprint Backlog
Eine erfolgreiche Schätzklausur zeichnet sich durch ein hohes Maß an Kommunikation aus. Das Team diskutiert erste Implementierungsstrategien, um auf dieser Basis einen Schätzwert bestimmen zu können. Dazu muss es die fachlichen Anforderungen des Backlog Items möglichst gut verstehen. Aus diesem Grund nimmt der Product Owner (eventuell gemeinsam mit anderen Kundenvertretern und Experten) an der Schätzklausur teil. In der Diskussion über ein Backlog Item entwickelt sich ein gemeinsames Verständnis der fachlichen Anforderungen. Mit diesem Wissen und dem durch die Sprintlänge abgesteckten zeitlichen Rahmen ist das Team nun in der Lage, gemeinsam mit dem Product Owner eine Menge von Backlog Items auszuwählen, die im Rahmen des kommenden Sprints umgesetzt werden sollen. Diese Auswahl findet ihren Ausdruck im Sprint-Ziel, auf dessen Erreichung sich das Team verpflichtet (da ist sie: die andere Bedeutung von „commitment“!).
Verantwortung für die Aufgaben (Tasks)
Jetzt geht es richtig los: Aus den (beispielsweise in Form von User Stories) fachlich formulierten Backlog Items werden vom Team einzelne Aufgaben extrahiert. Diese Handlungsanweisungen beschreiben technisch und/oder fachlich, was konkret zu tun ist, um das Sprint-Ziel (genauer: das zugehörige Backlog-Item) zu erfüllen. Wenngleich das „Was“ nun konkret beschrieben ist, so hat das Team bei der Frage nach dem „Wie“ immer noch einen großen Handlungsspielraum. Dieser wird begrenzt durch die im Projektkontext geltenden Architekturvorgaben, Programmierrichtlinien und Standardtechnologien und nicht zuletzt durch das kollektive Wissen des Teams. Auch wenn der organisatorische Rahmen dem Team ein wenig „Wie“-Verantwortung abnehmen kann, so muss das Team immer in der Lage sein, die getroffenen Entscheidungen zu argumentieren. Das fällt den meisten Mitgliedern agiler Teams jedoch recht leicht, weil die Verantwortung kollektiv leichter getragen werden kann als von einem einzelnen Softwarearchitekten.
Verantwortung im Daily Scrum
Das Daily Scrum dient der täglichen Synchronisation und der kollektiven Fortschrittskontrolle (in Form der Burndown Charts). Hier übernimmt das Team Verantwortung für den Fortschritt. Ein Daily Scrum ist zugleich eine Mini-Retrospektive: Das Team reflektiert über die vergangenen 24 Stunden. Es überprüft, ob das gesteckte Zwischenziel (in Form einzelner Aufgaben) erreicht wurde, forscht beim Nichterreichen (kurz!) nach den Ursachen und bringt geeignete Maßnahmen auf den Weg, um das Ziel am Ende des Sprint erreichen zu können. Im Daily Scrum tritt die Verantwortung der einzelnen Teammitglieder oft sehr deutlich zutage. Nicht selten führt der Druck der Verantwortung zu Rechtfertigungen einzelner Teammitglieder, die erklären wollen, warum sie nicht so weit sind, wie sie eigentlich sein sollten (besser: wollten). Hier ist der Scrum Master gefragt, um diese Art von Diskussionen in eine ergebnisorientierte Richtung zu lenken. Es hat sich bewährt, den agilen Grundwert „Fokussierung“ im Gedächtnis der Teammitglieder regelmäßig zu reaktivieren. Die Konzentration auf die anstehenden (hier auch im Sinne von „an dem Sprint Backlog stehenden“) Aufgaben wirkt manchmal Wunder.
Verantwortung im Sprint Review
Im Sprint Review erneuert das Team seine Verantwortung für das Sprint-Ziel, die es zu Beginn des Sprints übernommen hat. Anhand des (potentiell produktiv nutzbaren) Sprint-Ergebnisses kann das Team zeigen, was es in diesem Sprint geleistet hat. Dank des gemeinsam mit dem Product Owner festgelegten Sprint-Ziels sollte das Ergebnis nahezu deckungsgleich mit den fachlichen Anforderungen sein – ein „so habe ich das nicht gewollt!“-Erlebnis bleibt den agilen Teams meistens erspart. Da im Sprint Review ein funktionierendes Produkt vorgestellt wird, können die Kunden ihre Anforderungen und Ideen am „lebenden Objekt“ messen, gegebenenfalls verfeinern oder verändern bzw. das Team auf Missverständnisse bezüglich der Backlog Items hinweisen. Auch hier gilt: Wer rechtzeitig und regelmäßig miteinander kommuniziert, der wird im Sprint Review eher positiv überrascht.
Verantwortung in der Retrospektive
Während sich im Sprint Review alles um das Produkt dreht, so steht in der Retrospektive der Softwareentwicklungsprozess im Mittelpunkt. „Wie können wir das agile Handwerkszeug noch geschickter einsetzen, um die gemeinsam erkannten Probleme auszumerzen?“, fragt sich das Team. Dem Erkenntnisgewinn folt eine Priorisierung der Hindernisse, um schließlich für die am höchsten priorisierten Probleme geeignete Gegenmaßnahmen zu entwickeln und zu etablieren. Damit bietet sich dem Team die Möglichkeit, das eigene Arbeitsumfeld selbst zu gestalten. Das (und natürlich die vom Produkt begeisterten Kunden) ist der Lohn für die viele Verantwortung, die das Team im Laufe eines Scrum-Projekts übernimmt. Und da geteilte Verantwortung nur halb so schwer wiegt, kann Verantwortungsübernahme in agilen Projekten tatsächlich Spaß machen. Aus Verantwortung und Spaß entsteht dann nicht selten
Spaß an der Verantwortung
… und spätestens dann hat sich die Entwicklungsmannschaft zu dem eigenverantwortlichen agilen Team entwickelt, von dem in der agilen Literatur oft die Rede ist. Der Scrum Master eines solchen Teams muss nur noch selten an die agilen Werte und die Einhaltung der Spielregeln erinnern. Das macht ihn nicht arbeitslos – es sei denn, das Impediment Backlog ist leer. Aber das wäre ja nun wirklich zu schön, um wahr zu sein …