Backlog Gerümpel
Ich habe vor Kurzem wieder erlebt, wie wichtig Feedback in der Software-Entwicklung ist. In einem Projekt ist das Scrum Team derzeit im siebten 1-Wochen Sprint. Bis zum Release der 1. Version stehen noch zwei Sprints zur Verfügung. Das Backlog ist übervoll mit Themen. Die Hauptaufgabe des P.O. ist es nun verschärft, die wichtigeren Themen von den Unwichtigeren zu trennen und die noch verbleibende Sprints zu nutzen.
Wir (der Product Owner und ich als Scrum Master) hatten nun einen Termin mit dem Produkt-Sponsor (der Vorgesetzte des P.O.) und der P.O. präsentierte einige Folien zum Status des Projektes und zeigte auch das Backlog. Er erläuterte, dass die meisten Themen nicht umgesetzt werden können und stellte beispielhaft einige Einträge vor.
Nach der Hälfte des einstündigen Meetings schauten wir gemeinsam auf die Applikation, um dem Sponsor den aktuellen Stand zu zeigen.
Nun passierte etwas, was so häufig vorkommt: Der Sponsor, der bislang in den Reviews nur selten anwesend war, begann Feedback zum Produkt zu geben! Am Anfang waren es eher vorsichtige Nachfragen, nach ein paar Minuten stellte er aber (noch einmal) den Zweck des Projektes heraus. Dabei zeigte es sich, dass bei uns die ursprünglichen Ziele etwas aus dem Fokus gerückt waren. Nicht dramatisch, aber eben doch so weit, dass ohne dieses 15-Minuten Feedback eines Aussenstehenden vermutlich vom P.O. die falschen Themen für die letzten zwei Sprints ausgewählt worden wären.
Was war passiert? Während der täglichen Arbeit mit Backlog-Themen ist der Überblick über das große Ganze wohl etwas verloren gegangen. Ohne dass es uns bewußt war, haben wir doch in Teilen an der "Goldkante" gearbeitet, obwohl wir meinten, genau dies nicht zu tun. Auch Forderungen des Fachbereiches (der User der Applikation) wurden im Nachhinein zu hoch gewichtet und haben das Scrum-Team verwirrt und defokussiert.
Deswegen: Tut alles, um Feedback von allen Seiten bekommen zu können.
- User Storys sind Storys des Users, Storys von der Verwendung der Software. Vermeidet "Developer-Storys" (oder "technische Storys") zu schreiben. Wenn das Development-Team Zeit benötigt, um unter der Motorhaube zu arbeiten, dann nennt das schlicht "Aufgabe".
- Versucht im Sprint immer etwas zu entwickeln, das zum Einholen von Feedback verwendet werden kann. Wenn Storys zu groß sind, dann verkleinert sie aus User Sicht. Denkt dabei in verschiedenen Ausbaustufen des Features. Verwendt zum Herausarbeiten der wertvollsten Variante z.B. den Ansatz von E. Gottesdiener¹. Vermeidet eine Verkleinerung aus technischer Sicht (z.B. "In einem Sprint machen wir die GUI, im nächsten den DB-Service, dann die Datenbanktabellen ...").
Nach meiner Erfahrung fällt das Verlassen der technische Perspektive vielen Leuten im Development-Team (noch) schwer. - Versucht den vertikalen Durchstich im Sprint hinzubekommen und speckt alles ab, was euch dies erschwert. Es nützt euch nichts, wenn ein Feature über mehrere Sprints entwickelt wird und ihr erst nach einigen Wochen soweit seid, um Feedback einzuholen.
- Verwendet nicht nur das Review, um Feedback zu bekommen, sondern macht auch separate Sessions mit dem Stakeholder. Diese Sessions kann der P.O. auch alleine mit dem Stakeholder durchführen.
- Seid euch bewußt, dass ihr manchmal die Mitarbeit eines Aussenstehenden benötigt, um den Überblick zu behalten. Ein Abtauchen in die Materie ist normal für alle Projektbeteiligten und wichtig für die Detailarbeit. Ihr müßte aber auch, wie beim Schwimmen im Meer, den Kopf ab und an aus dem Wasser heben und sehen, ob der Kurs noch stimmt. Nutzt dazu Leute, die nicht täglich im Projekt involviert sind, um euch über die Wasseroberfläche zu bringen. Macht dies frühzeitig. Wenn ihr meint es ist zu früh, dann macht es erst recht (jetzt).
- Überlegt bei jeder User-Story, wie die Demo aussehen wird. Der User muss etwas bekommen, mit dem er interagieren kann, ob passiv (z.B. Information zum Authentifizierung wird dem auf der Software-Oberfläche zur Verfügung gestellt) oder aktiv (z.B. der User kann einen Button klicken und bekommt ein Reaktion des Systems). Nur dann kann er Feedback geben.
- Verzichtet auf Powerpoint-Präsentationen und Screenshots. Zeigt das echte Ding. Wenn ihr das nicht könnt, habt ihr nicht mit dem Ziel entwickelt, frühzeitig Rückmeldungen der Stakeholder einzusammeln.
Die agile Software-Entwicklung lebt vom frühzeitigem Feedback. Nur dies kann das Scrum-Team davor bewahren, in die falsche Richtung unterwegs zu sein. Das Scrum-Team kann Woche für Woche perfekte Sprints hinlegen, mit steigender Velocity, hoher Testabdeckung, in bester Qualität, mit fantastischen Erkenntnissen in der Retrospektive, hoher Happiness, alles innerhalb der Time-Box usw. Dies wird euch nicht davor bewahren ein Produkt zu entwickeln, das am Ziel vorbei geht.
Projektfremde Leute sind ein idealer Kompass und eine Karte zur Standortbestimmung. Nutzt sie!
weiterführenden Quellen