Scrum ist ein tolles System. Bitte verstehen Sie mich nicht falsch. Ich mag Scrum, aber manchmal bringt es mich auf die Palme. Eine Sache, über die ich mich immer wieder ärgern kann, ist die Sache mit den Reviews und der Testerei. Ganz besonders dann, wenn ich mit Scrum Mastern und Product Ownern spreche, die nicht wissen ob Tests in den Sprint gehören, und die durch das Review hetzen, weil nur eine Stunde Zeit im Meeting ist aber so viele Anforderungen abgenommen werden müssen.
Ich kann den armen Leutchen nicht einmal einen Vorwurf machen. Das Scrum Regelwerk lässt sie in dieser Frage allein, und die Aussage, dass der Product Owner während des Reviews alle fertiggestellten Anforderungen abnimmt, halte ich für durchaus gewagt.
Ein gut funktionierendes Team aus vielleicht sechs erfahrenen Entwicklern schafft in zwei Wochen eine ganze Menge. Von einem Product Owner zu verlangen, dass er all das in zwei Stunden (und damit haben wir schon ein recht langes Review-Meeting) in allen Details begutachtet und abnimmt, halte ich sogar für außerordentlich ambitioniert.
Das ist für mich sogar ein gefährliches Vorgehen. Der Product Owner macht sich viele Gedanken beim Schreiben seiner Anforderungen. Er stellt für jede einzelne eine ganze Reihe von Abnahmekriterien auf. Diese Dinge definieren die Software, die wir erstellen. Wenn der Product Owner an dieser Stelle einen Fehler macht, bekommen wir im schlimmsten Fall ein nicht zu bedienendes Feature. Und jetzt soll ich tatsächlich akzeptieren, dass dieser wichtigste Test der Software in wenigen Minuten von einer Person durchgeführt wird?
Jemandem, der etwas von der Softwareentwicklung versteht, muss ich nicht sagen, dass die Testerei selbstverständlich noch weit komplexer und umfangreicher ist. Der Product Owner kann selbstverständlich nur oberflächlich auf seine Abnahmekriterien hin testen und checken, ob diese alle erfüllt sind, das Feature das macht, was es machen soll, und ob ihm bei dieser Gelegenheit irgendeine Fehlermeldung im die Ohren fliegt. Belastungstests sind schwieriger. Wie sieht es bei Refactorings aus? Wie nimmt ein Product Owner eine Anforderung ab, die sich auf den Deep Core bezieht? Oder auf die Serverumgebung? In diesen Fällen braucht er Hilfe. Im Idealfall haben wir einen Tester im Team, manchmal wird ein Feature an eine nachgelagerte Testabteilung übergeben. Wie auch immer, Code tippen und der Product Owner nimmt die Sache dann im Rahmen eines Reviews ab, ist keine Lösung.
Ich gehe gerne so vor, dass ich als Product Owner meine Reviews dann mache, wenn ein Entwickler eine Anforderung fertiggestellt hat. Im Rahmen des Daily Scrum sagt der Entwickler, dass er eine Sache abgeschlossen hat, der Product Owner nimmt sich möglichst bald die Zeit, sich die Anforderung in Ruhe anzusehen und auf seine Abnahmekriterien hin zu prüfen. Er ist damit die erste Testinstanz im Laufe des Sprints. Der PO kann direkt Feedback an den Entwickler geben, wenn er noch ein Problem findet, und der Entwickler kann dieses Problem seinerseits noch in diesem Sprint lösen.
Die Alternative dazu ist, dass der PO die Anforderung im Review zurückweist, woraufhin diese in den nächsten Sprint übernommen wird. Ich bin eher ein Fan davon, die Dinge zeitnah zu lösen, und das ist nur möglich, wenn sich der PO eine Anforderung sofort (oder am nächsten Tag) ansieht. Zusätzlich nimmt man sich dann auch wesentlich mehr Zeit, sieht sich die Sache in Ruhe an und ist damit auch gewissenhafter. Gelegentlich geschieht es auch, dass dem Product Owner bei der ruhigen Betrachtung der fertiggestellten Anforderung auffällt, dass irgendetwas nicht wirklich rund läuft, dass es sich nicht wirklich flüssig bedienen lässt, dass noch eine Verbesserung möglich ist. In diesem Fall schnappt man sich den Entwickler, spricht das mit ihm durch und geht die Sache an.
Sie werden jetzt einwenden können, dass das Sprint Backlog unveränderlich sei, und dass das die gesamte Sprintplanung über den Haufen werfe. Damit haben Sie auch recht. Eine Änderung des Sprint Backlogs sollte man sich genau überlegen, ich muss jedoch wieder die Frage zur Alternative stellen. Der Entwickler hat eine Anforderung fertiggestellt, und der Product Owner stellt fest, dass man das Feature noch verbessern könnte, indem man eine Kleinigkeit ändert (ich spreche jetzt ganz bewusst nur von einer Kleinigkeit). Der Product Owner nimmt während des Reviews das Feature an, weil alle Anforderungen umgesetzt sind. Dann macht er sich daran, eine neue Anforderung mit der Änderung zu schreiben. Der neue Sprint ist aber schon gestartet. Der Alte Sprint endet mit Review und Retrospektive, der neue beginnt direkt im Anschluss daran mit der neuen Sprintplanung. Die neue geänderte Anforderung kann also erst im darauf folgenden Sprint umgesetzt werden. Ist das nicht völliger Quark?
Zurück also zum gesunden Menschenverstand. Der Product Owner stellt noch während des laufenden Sprints fest, dass die Anforderung nicht komplett über den Haufen geworfen werden muss, sondern mit wenigen kleinen Veränderungen verbessert werden kann. Er spricht also mit dem Entwickler darüber, der ihm eine voraussichtliche Zeit nennt. Wenn wir Glück haben, passt das alles noch in den Sprint, weil wir in weiser Voraussicht einen kleinen Zeitpuffer eingeplant haben. Wenn wir Pech haben, müssen wir eine andere kleine Anforderung opfern und in den nächsten Sprint verschieben. Wenn die Änderungen an der Anforderung umfangreicher sind, dann wird das nicht mal eben so gemacht, dann wird eine neue Anforderung im nächsten Sprint umgesetzt.
Jetzt muss ich natürlich warnen: Wir sprechen hier über eine Ausnahmesituation. Wenn es häufiger geschieht, dass ein Product Owner den Sprintinhalt während des Sprints ändert, weil er noch mögliche Verbesserungen findet, dann sollte er sich ernste Gedanken über seine Vorbereitung machen.
Wir sollten uns auch innerhalb eines Sprints ein wenig Freiraum lassen. Unser Ziel ist es nicht, uns möglichst eng an eine Vorgehensweise zu halten, sondern möglichst gute Software zu entwickeln. Und wenn wir uns dafür mal ein wenig vom Regelwerk entfernen müssen, dann ist das vollkommen in Ordnung. Wichtig ist jedoch, dass alle Beteiligten genug Disziplin und Übersicht haben, dass diese Dinge Ausnahme bleiben und nicht zur Regel werden (wenn Sie Hilfe dabei brauchen, das richtige Maß zu finden, fragen Sie mich).
Wenn der PO sein Review schon während des Sprints macht, brauchen wir dann noch ein Review?
Kurze Antwort: ja. Der PO hat die Anforderung bereits begutachtet und an den Tester weitergegeben. Es hat ein Code Review stattgefunden. Wir wissen, dass alles funktioniert und alles passt. Eingeweiht sind bislang jedoch nur Product Owner und der Entwickler, der die betreffende Anforderung umgesetzt hat. Im Review stellen die Entwickler ihre Arbeit noch einmal allen vor. Damit verschiebt sich der Focus des Reviews weg von einer Testsitzung hin zu einer Informationssitzung. Das gesamte Team wird auf den gleichen Wissensstand gebracht. Hierbei ergeben sich auch Ansätze für weitergehende Massnahmen. Zum Beispiel kann ein Entwickler bei einer Anforderung darauf hinweisen, dass er sich für deren Umsetzung eine neue Technologie angeeignet hat. Vielleicht vereinbart man bei der Gelegenheit eine kleine interne Schulung, damit auch die anderen davon profitieren.
Man kann zum Review auch diverse Interessenvertreter einladen. Ich finde das immer etwas problematisch, wenn man dann noch anhand der Abnahmekriterien checkt, ob eine Anforderung überhaupt fertiggestellt ist. Wenn das schon erledigt ist, wird das Review zur Präsentation der Ergebnisse, die dann auch durchaus problemlos über das Entwicklerteam hinaus gehen kann.
