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” genannt).

Der Fokus von LeSS (Large Scale Scrum) liegt bekanntermaßen auf Skalierung, sprich darauf, wie agile Produktentwicklung auch in wachsenden Unternehmen und über zahlreiche Teams hinweg funktionieren kann. Ein zentrales Element von Skalierung ist Synchronisation der Produkt-Teams. Ein “Overall Review” mit allen Teams ist Teil davon. Aus diesem Kontext stammt auch die Basar-Idee.

Dabei präsentieren alle Teams das im Sprint Entwickelte an einzelnen Ständen in einem Raum. An jedem Stand stehen Mitglieder des jeweiligen Teams bereit für Fragen und Diskussionen. Stakeholder, Teammitglieder und andere Teilnehmer (z.B. Endnutzer) besuchen die einzelnen Teams und erfragen die Stories oder Features, die sie interessieren. LeSS bezeichnet dies als die “diverge period”, in der Informationen gesammelt werden.
Im Anschluss folgt das Zusammenführen dieser Infos. Stakeholder fassen zusammen, äußern ihre Meinungen und diskutieren die präsentierten Ergebnisse.
Beide Phasen können mehrere Zyklen in einem Basar durchlaufen. Wie im klassischen Sprint Review können verschiedene Geräte und Medien genutzt werden, um Ergebnisse erlebbar zu machen. Ein Feature einer App selbst an einem Device auszuprobieren ist sehr viel einprägsamer, als das Ergebnis berichtet oder gezeigt zu bekommen.

Die konkrete Umsetzung eines Basars wird unterschiedlich gehandhabt. Beispielsweise nimmt in einigen Unternehmen der PO während des Basars die Stories der Teams ab. Dort wo der PO stark in die tägliche Arbeit der Teams eingebunden ist, kennt er das Ergebnis bereits und steht eher als Ansprechpartner in der Stakeholder-Diskussion zur Verfügung.

Insgesamt ermöglicht das Basar-Format eine effiziente Information und offene Diskussion von und mit Stakeholdern. Gleichzeitig bietet sich ein Gesamtüberblick über die im letzten Sprint entwickelten Features, Produktteile und Verbesserungen über alle Teams hinweg. Ähnlich wie beim Gemba Walk erhalten die Teams direktes Feedback und ihre Arbeit erfährt Aufmerksamkeit und Wertschätzung.

Eine unterhaltsame und motivierende Erweiterung erfuhr unser Produkt-Basar auf der LeSS Konferenz. Jeder Teilnehmer erhielt für den Basar “LeSS Money”, also Spielgeld-Scheine. So konnte man in die Produkte “investieren”, die einem persönlich Wert brachten. Das funktionierte in diesem Fall, da alle Basar-Besucher selbst Teilnehmer der Konferenz waren und das “Produkt” eine Aufbereitung der  wichtigsten “Learnings” und Kernthemen sein sollte. Insofern waren alle Teilnehmer gleichzeitig Endnutzer. Das trifft auf Entwicklungsteams normalerweise nicht zu.
In jedem Fall war es eine schöne Belohnung für jedes Team, wenn jemand Geld in die eigene Team-Box warf. Vom Spaßfaktor ganz zu schweigen. Wo das möglich und gewollt ist, kann man auf diese oder ähnliche Art durchaus einen anspornenden Wettbewerb erzeugen. Dabei sollte jedoch unbedingt bedacht werden, dass Schuldzuweisungen und Verlierer-Termini kein Team voranbringen und daher zu vermeiden sind.
(Und natürlich muss ich hier nochmal erwähnen, dass unser Team Gewinner der Basar Challenge auf der LeSS Konferenz war…) 😀

Auch der Basar muss jedoch nicht zwangsläufig ein Garant für kontinuierliches Stakeholder-Feedback sein. Woran das liegt und was ich noch mit agilen Teams erlebt und ausprobiert habe, könnt ihr nächste Woche hier lesen.

Stakeholder-Feedback und Wertschätzung in der agilen Produktentwicklung – Teil 1
Markiert in:                 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.