Eure Teams sind motiviert, ihr startet mit Bilderbuch-Scrum durch, ihr habt richtig gute early adopters, die Euch beim Verbreiten agiler Ideen unterstützen und ihre eigenen Erfahrungen im Team teilen. Alles könnte so schön sein. Aber im Sprint Review wartet euer komplettes Team vergeblich auf Stakeholder. Obwohl die Einladung ein Serientermin ist, alle informiert und erinnert wurden und ebenfalls alle die Einladung angenommen haben. Was für eine Enttäuschung. Spätestens nach dem zweiten Sprint Review hat euer Team keinen Bock mehr darauf, denn scheinbar ist die geleistete Arbeit nicht wichtig genug, um gewürdigt zu werden. In der nachfolgenden Retrospektive wird der Prozess an sich, Scrum und agiles Vorgehen generell in Frage gestellt und die Motivation des Teams ist dahin.
Wer von euch hat wissend geschmunzelt, verzweifelt genickt oder zustimmend geseufzt?
Diejenigen, die Ähnliches bereits erlebt haben, fragten sich wahrscheinlich auch, wie man die Situation für alle Beteiligten verbessern kann. Ein paar Erfahrungen dazu möchte ich in diesem und dem darauffolgenden Post mit Euch teilen.
Aufmerksamkeit erhöhen: Das Gemba Walk Experiment
Um zu erkennen, was das Problem ist, kann es sinnvoll sein, gemeinsam mit den Stakeholdern zu reflektieren, was passiert ist und warum. In einem Unternehmen, in dem ich mehrere Teams betreut habe, gelangten wir nach Rückfragen zu der Annahme, dass andere Termine wichtiger erscheinen, weswegen Stakeholder nicht am Review teilnehmen. Was könnte man daraus ableiten? Eine Idee war, die Attraktivität und den wahrgenommenen Wert des Sprint Reviews zu erhöhen. Genau das haben wir ausprobiert – mit dem Gemba Walk Experiment.
Gemba ist ein japanisches Wort und bedeutet soviel wie “Tatort” oder der Ort des Geschehens. Aus ökonomischer Sicht ist damit auch der Ort gemeint, an dem produziert und Wert erzeugt wird. Im klassischen Qualitätsmanagement wird diese Idee so verstanden, dass Experten die Prozesse und Bedingungen vor Ort beobachten, um akute Probleme analysieren und eine angemessene Lösungsstrategie ableiten zu können.
Uns gefiel das Konzept und wir entschlossen uns, die Idee des Gemba Walks zu adaptieren. Wir erhofften uns, Teams und Stakeholder generell näher zusammen zu bringen. Außerdem wollten wir die Möglichkeit schaffen, Entscheidungen während des Entwicklungsprozesses nachvollziehbar und verstehbar zu machen.
Dafür wurden die Stakeholder in den Teamraum eingeladen, wo auch alle anderen Werkzeuge und Arbeitsmittel, wie Whiteboards, Build Screens, JIRA Boards, To Do Listen, Priorisierungs-Matrizen u.ä., in Augenschein genommen werden konnten.
Im Vergleich zum Review wurde der Fokus erweitert: Das Team demonstrierte zwar zuerst den aktuellen Stand der Produktentwicklung, im Gegensatz zum klassischen Sprint Review in Scrum konnte dieser aber auch den Status unfertiger Features beinhalten, wenn die Stakeholder dazu Informationen wünschten. Während der ersten Phase, in der das Team ungestört funktionierende und an den Kunden auslieferbare Produktteile präsentierte, konnten sich Stakeholder Fragen notieren, auf die im Anschluss eingegangen wurde. Je nach Anzahl der Teilnehmer und Fragen, wurden letztere zwischendurch in Cluster aufgeteilt und durch Dot Voting oder “buy-a-question” mit Pokerchips priorisiert, um sicherzustellen, dass die wichtigsten Fragen zuerst besprochen und definitiv beantwortet werden.
Außerdem waren die Gemba Walks offen für jedermann. Das hat die empfundene Wertschätzung für das Team definitiv erhöht, denn es waren stets auch Mitglieder anderer Teams und Interessierte aus anderen Abteilungen des Unternehmens anwesend.
Allerdings erhöhten sich damit auch Vorbereitungsaufwand und Platzbedarf. Um das zu kompensieren und die Kalender der Stakeholder zu entlasten, gab es nur einen Gemba Walk pro Woche. Entsprechend hatte jedes Team seinen Gemba Walk nur in mehrwöchigen Abständen, je nachdem wie viele Teams am Produkt arbeiteten (z.B. 6 Teams = 6 Wochen mit je einem Gemba Walk, d.h. jedes Team hat nur aller sechs Wochen einen Gemba Walk). Das ist eine lange Zeitspanne für eine Feedback-Schleife im agilen Entwicklungsprozess. Entsprechend musste zusätzlich weiterhin Feedback über andere Wege eingeholt werden. Reviews zum Sprintende gab es weiterhin – quasi als Endabnahme im Team mit dem Product Owner (PO), manchmal mit einzelnen Stakeholdern. In der Woche des Gemba Walks ersetzte dieser jedoch das Review.
War das Experiment erfolgreich? Ja. Wir haben definitiv dazugelernt und konnten weiter optimieren. Hat das Experiment unser Problem, die Anwesenheit von Stakeholdern sicherzustellen, gelöst? Nein. Oha! Was also war das Ergebnis?
Ein positiver Effekt war definitiv die gesteigerte Aufmerksamkeit für die Arbeit der Entwicklungsteams im gesamten Unternehmen. Auch der Austausch zwischen den Teams wurde gefördert. Das Interesse an der Arbeitsweise unserer Teams war enorm und einige kreative Arbeitsmittel wurden bestaunt und positiv bewertet.
Durch die offenere Gestaltung des Gemba Walks im Vergleich zum Sprint Review gab es einerseits mehr Austausch zu geplanten Kampagnen, Ideen und Nutzerreaktionen, andererseits auch tatsächlich mehr direktes Feedback zu den fertigen Features.
Kurzzeitig steigerte der neue Charakter auch die Motivation der Beteiligten und wir mussten den Zeitrahmen sogar erweitern, da das Interesse so groß war. Das war umso erstaunlicher, weil die meisten Stakeholder zuvor nicht einmal an deutlich kürzeren Sprint Reviews teilnahmen.
Dennoch war uns schnell klar, dass wir einfach etwas Neues geschaffen hatten, das kein Ersatz für ein klassisches Review sein konnte. Entsprechend überwogen nach einigen Monaten auch die Nachteile, z.B. ist kein Team-Raum geeignet, eine so große Menge von Leuten zu fassen. Und letztlich machte sich nach wenigen Monaten auch das ursprüngliche Problem bemerkbar: immer weniger tatsächliche Stakeholder nahmen an den Gemba Walks teil. “Inspect and adapt” war erneut angesagt.
Positiv verstärken: Der Basar
Eine interessante Version des Reviews durften wir im Rahmen der ersten LeSS-Konferenz in Amsterdam 2016 selbst erleben: den Produkt-Basar (im LeSS Framework
“Bazaar” …