Ich widme mich wieder meinem Lieblingsthema – nicht weil ich Sie langweilen möchte, sondern weil ich gerade an dieser so zentralen Stelle so viel Blödsinn sehen und lesen muss. So viele Teams bemühen sich um die Einhaltung der Zeremonien und Artefakte, um möglichst richtig Scrum zu machen und vergessen dabei das Wichtigste: die Inhalte.
Wie oft sieht man Teams, die das Thema Refinement/Grooming vernachlässigen und erst im Planning ernsthaft in sehr komprimierter Form über Inhalte sprechen. Oft genug ist das der Zeitpunkt, in dem Entwickler erstmalig mit den Inhalten des nächsten Sprints konfrontiert werden, wenn der Produkt Owner die scheinbar fertig formulierte Anforderung präsentiert. Man spricht kurz über das Was, um es gut genug zu verstehen, damit man sich ein wenig länger über das Wie unterhalten kann. In einem solchen Vorgehen fliegen uns die Anforderungen regelmäßig wie die explodierenden Kühe um die Ohren, und alle fragen sich, wie das schon wieder passieren konnte.
Andere Teams haben sich feste Sessions in ihren Terminplan eingetragen, um Anforderungen für den nächsten Sprint ein paar Tage vor Startschuss zu besprechen. Auch dieses Vorgehen ist nur wenig besser. Auch hier präsentiert der Product Owner in der Regel die fertige Anforderung, man unterhält sich kurz über das Was, gelegentlich auch über das Warum, um dann etwas länger über das Wie zu sprechen. Ganz unweigerlich kommt ganz schnell die Frage: »Können wir das jetzt schätzen?« Das Feedback auf diese Frage ist meistens, dass es noch ein paar kleine Fragezeichen gäbe, aber man habe lang genug darüber gesprochen und ein ausreichendes Verständnis entwickelt, dass man jetzt mit einigermaßen guter Sicherheit eine Schätzung abgeben könne.
Auch in diesem Setting explodieren uns die Anforderungen in schöner Regelmäßigkeit unter dem Arsch, und wir sind noch ratloser. Schließlich haben wir lange genug über die Anforderung gesprochen.
Ganz davon abgesehen, dass ich es grundsätzlich für einen schweren Fehler halte, das Team nicht auch in das Warum einzubeziehen, wird es uns so niemals gelingen, Features oder Epics in ihrer Gänze zu überblicken. Ein Entwickler erhält so immer nur Einblick in einen kleinen Teilbereich des Ganzen. Es ergeben sich unnötige Schwierigkeiten in der Implementierung, aber auch grundsätzliche Verständnisprobleme. So bleibt alles Stückwerk, auch wenn es uns gelingt, nach jedem Sprint ein kleines Inkrement zu shippen.
Worauf möchte ich hinaus?
Um das volle Potential eines Teams abzurufen, brauche ich den Kontext für jede Anforderung auf dem Board. Damit verbunden ist auch ein möglicherweise verändertes Rollenverständnis des Product Owners. In meiner Sicht und nach meiner Erfahrung ist ein PO, der allein das Was bestimmt und seinem Team fertige Häppchen vorsetzt eher ein Hemmnis für ein starkes Entwicklungsteam.
Ich möchte, aus einem gemeinsamen Verständnis heraus im gesamten Team Entscheidungen treffen können. Eine Entscheidung, die man gemeinsam getroffen hat, hat mehr Gewicht, als diejenige, die ein anderer für mich getroffen hat. Mit einer solchen Entscheidung setze ich mich als Entwickler anders auseinander. Mein Vorgehen wird sich verändern.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Ich beginne mit meinen Teams also sehr viel früher. Der Einstiegspunkt ist die übergeordnete Ebene, bevor wir an das Schneiden der Stories gehen. Ich spreche mit meinen Teams über Themen und Epics und priorisiere gemeinsam mit den Kollegen zunächst die Themen und Features, die wir in baldiger Zukunft angehen möchten, auch wenn dazu noch keine oder nur wenige Details bekannt sind. Vor allen Dingen vermittle ich zu diesem Zeitpunkt bereits die Intention, die mit diesen Themen und Features verbunden ist. Ich möchte, dass allen jederzeit vollkommen klar ist, warum wir was tun. Aus dieser Fragestellung ergibt sich für uns die Priorisierung.
Bereits jetzt sprechen wir auch über allererste ganz grobe technische Abhängigkeiten, um eben diese Dinge schon zu diesem Zeitpunkt berücksichtigen zu können. Natürlich kann es uns passieren, dass wir ein Feature erst umsetzen können, wenn wir ein Anderes erledigt haben, oder wir laden uns unverhältnismäßig große Aufwände auf. Diese Dinge sollten wir frühestmöglich wissen.
Das gemeinsame Priorisieren von Themen/Epics bzw. von Features ist nur der erste Schritt unserer Refinement-Kette. Wir haben bisher lediglich ein gemeinsames Verständnis geschaffen, warum wir welche Dinge tun. Über Details sprechen wir im nächsten Schritt, gehen dabei immer vom Groben ins Feine. Bei jedem Gespräch über ein Feature haben wir nicht zwingend das Ziel, eine abschließende Zahl für die StoryPoints auf die Karte zu schreiben, sondern möglichst viele Fragezeichen aufzulösen, die sowohl funktionaler als auch technischer Natur sein können. Wir kommen also zu einer ganzen Kette von Refinements einer einzigen Anforderung. Schritt für Schritt werden wir dabei schlauer und lernen das Feature besser kennen.
Sie werden nun einwerfen, dass wir damit einen riesigen Aufwand treiben, aber ich muss entgegnen, dass uns das zum einen vor bösen Überraschungen bewahrt, und wir zum anderen sehr viel besser verstehen, was wir eigentlich tun, und was wir damit erreichen wollen. Das ursprüngliche Feature wird sich in diesen mehreren Sessions auch verändern, weil wir besser verstehen, wie wir den gewünschten Nutzen für den Kunden erreichen können.
Wir gehen dabei so vor, dass wir nicht eine große Session einmal in der Woche oder einmal im Sprint ansetzen, sondern die Inhalte eher auf viele kürzere Diskussionen verteilen. Wir treffen uns (vielleicht direkt im Anschluss an das Daily, um den Tag nicht weiter zu zerreißen), sprechen über einen Aspekt unseres Features, identifizieren noch offene Fragen oder schneiden einzelne Stories heraus für die Dinge, die uns schon sehr klar sind, sind nach wenigen Minuten fertig, einer klärt die offenen Fragezeichen, und ein oder zwei Tage später, steht man morgens wieder gemeinsam vor der Tafel, bespricht die inzwischen neu gewonnenen Erkenntnisse und kommt so einen Schritt weiter. Der gesamte Gesprächsaufwand ist oftmals nicht so viel höher, wie bei einer langen Session, aber durch das schrittweise Vorgehen haben wir immer wieder Zeit, offene Fragen zu klären und Meinungen einzuholen.
Natürlich erhöhen die Recherchen zwischen den einzelnen kurzen Gesprächen den Gesamtaufwand. Ein Entwickler nimmt sich z.B. eine Stunde Zeit, um in altem Code nach den passenden Ansatzpunkten zu suchen, aber haben wir diese Zeit nicht sowieso in unserem Sprint vorgesehen? Je nach Projekt brauchen wir mehr oder weniger Zeit, aber als Faustregel kann man sich merken, dass man in einem Zwei-Wochen-Sprint für jeden Entwickler einen ganzen Tag für Refinements vorsehen sollte. Dieser Tag verteilt sich selbstverständlich meistens auf den gesamten Zeitraum. Andere Scrum-Master und Coaches sprechen auch von 20% und mehr. Welcher Wert für Sie passt, werden Sie nach einiger Zeit selbst am besten entscheiden können. Unser Diktat ist dabei der Bedarf, nicht die Uhr. Haben Sie keine Angst davor, dass Sie weniger produktiv arbeiten können, wenn Sie viel Zeit mit Refinements verbringen. Im Prinzip gilt der Grundsatz »Lieber zweimal messen und dafür nur einmal Schneiden«. Durch die gute Vorbereitung arbeiten wir bei der Umsetzung sehr viel konzentrierter und produzieren weniger Waste.
Das Ganze fügt sich in ein größeres Bild. Ich sprach eingangs davon, dass ich gemeinsam mit dem Team die Epics/Themen/Features priorisiere. Das bezieht sich nicht nur auf die Umsetzung, sondern auch auf die Vorbereitung. Ich arbeite gerade an einem Thema, weiß aber schon, welches als nächstes angegangen werden soll, also weiß ich auch, mit welchem ich mich gedanklich auseinandersetzen muss, um keine Lücke entstehen zu lassen. Ich arbeite also an einem Thema, habe das nächste in meiner Refinement-Kette und bin bereit, wenn ich an die Umsetzung gehe. Aus diesem Grund habe ich die Refinements auch fest in meinem Sprintbacklog und in meinen Sprintzielen verankert. Ich habe also das Sprintziel, Feature X zu schippen und das interne Ziel, Feature Y so weit vorbereitet und durchdacht zu haben, dass ich direkt im Anschluss nahtlos damit starten kann.
In diesem Modell wird der Product Owner mehr zu einem Koordinator. Er denkt vor, entwickelt ein Feature und verortet es in den Kundenanforderungen. Dies bespricht er mit dem Team und nimmt auch dieses Feedback auf. Daraufhin verfeinert er das Feature, holt weitere Stimmen ein und sorgt für die Antwort auf die funktionalen Fragen, während sich die Entwickler um die Antworten auf die technischen Fragen kümmern.
Fürchten Sie sich nicht vor dem Mehraufwand durch aufwändige Refinements. Was Sie dadurch in der Umsetzung gewinnen, macht das mehr als wett.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
