Im zweiten Teil des Beitrags werfen wir einen Blick auf einen weiteren Ansatz, den ich mit verschiedenen Teams ausprobiert habe, um regelmäßig direktes Feedback von Stakeholdern zu entwickelten Features, Produktteilen und Verbesserungen zu erhalten.
Visualisieren und Lernen: Die Showtime
Einen dem Produkt-Basar ähnlichen Ansatz (wie letzte Woche beschrieben) verfolgten wir in einem Unternehmen mit mehreren Entwicklungsteams im Rahmen der Weiterentwicklung unseres Prozesses. Wir hatten die drei Teams, die an einem Produkt arbeiteten, bereits synchronisiert und es gab einen gemeinsamen Product Owner (PO) – beides Kernelemente von Large Scale Scrum (LeSS). Für das Review hatten wir bereits verschiedene Formate getestet und bemerkt, dass die Akzeptanz erneut gesunken war. Hauptargumente waren der Zeitaufwand, technische Probleme (einige Teammitglieder saßen an anderen Standorten) und die Schwierigkeit, den technischen Präsentationen anderer Teams zu folgen.
Diesen Einwänden wollten wir gerecht werden, den Austausch und kontinuierliches Lernen in den Mittelpunkt stellen und einfach mehr Spaß haben.
So bedienten wir uns verschiedener erprobter Instrumente und hielten von da an eine “Showtime” ab, deren Umsetzung wir ebenfalls kontinuierlich verbesserten.
In dieses Format konnten wir alle Teams einbeziehen, auch diejenigen, die an unterschiedlichen Produkten arbeiteten. Dies machte Sinn, da die Teams teilweise Feedback von identischen Stakeholdern benötigten und auch Abhängigkeiten zwischen einzelnen Teams bestanden. Außerdem konnte somit mehr Wissensaustausch zwischen den Teams angestoßen werden. Um einen überschaubaren Zeitrahmen einhalten zu können, fand die Showtime am Ende wöchentlich statt und war für 90 Minuten angesetzt, die jedoch meist nicht komplett benötigt wurden. Die Teams, deren Themen stärker miteinander verknüpft waren bzw. die am gleichen Produkt arbeiteten, präsentierten in der gleichen Woche. Dadurch blieb die Anzahl der Teams pro Showtime überschaubar.
Zu Beginn jeder Showtime hatte jedes der bis zu fünf präsentierenden Teams maximal 10 Minuten Zeit, um zu präsentieren, woran es gerade arbeitete. Dies umfasste (wie beim Review) sowohl die Live-Demonstration von fertigen Produkt-Inkrementen, aber auch Einblicke in Metriken, Hinweise auf Fehlschläge und daraus Gelerntem sowie Berichte über technische Optimierungen und Ausblicke auf nächste Schritte. So unmöglich das klingen mag, mit der Zeit funktionierte das wirklich wunderbar – trotz der kleinen Timebox von 10 Minuten pro Team. War dieser zeitliche Rahmen nach der Kurzpräsentation noch nicht ausgereizt, konnte der Präsentierende die Zeit für die Beantwortung kurzer allgemeiner Fragen nutzen.
Andernfalls folgte im Anschluss ein Basar, der wie im Teil 1 beschrieben funktionierte: jedes der präsentierenden Teams hatte einen Stand, an dem Teammitglieder mit Stakeholdern und Interessi
erten diskutierten und Fragen beantworteten.
Aus den klassischen Sprint Reviews hatten wir außerdem gelernt, dass Gesagtes von verschiedenen Teilnehmern sehr unterschiedlich reflektiert und interpretiert wird. Daher legten wir großen Wert auf Visualisierung. Um Missverständnisse bezüglich des tatsächlichen Statuses von Präsentiertem zu vermeiden, markierte jedes Team den aktuellen Stand mit beschrifteten Haftnotizen auf einem Poster, das ich zu diesem Zweck gemalt hatte. Das hatte zusätzlich den Effekt, dass ein Überblick über die präsentierenden Teams und deren Themen entstand, die es allen Beteiligten beim Basar erleichterte, die richtigen Ansprechpartner zu finden.
Sowohl das Präsentierte als auch Visualisierungen wurden per Livestream an Teammitglieder an anderen Standorten übertragen. Nach wie vor bin ich der Meinung, dass ein Team dann am besten zusammen arbeiten kann, wenn es einen gemeinsamen Raum an einem Ort hat. Leider ist dies nicht immer praktisch umsetzbar. Daher war die kontinuierliche Verbesserung des technischen Setups ein weiterer Schwerpunkt. Dies könnte jedoch locker einen eigenen Blogpost füllen und sprengt hier den Rahmen.
Besonders toll war, dass auch Moderation sowie Vor- und Nachbereitung der Showtime am Ende ausschließlich durch Teammitglieder erfolgte – auch wenn Agile Coaches unterstützend zur Seite standen und jederzeit verfügbar waren. Nach dem Rotationsprinzip war jede Woche ein Team an der Reihe, so dass der Aufwand für die einzelnen Teams und Personen überschaubar blieb. Zur technischen Unterstützung war jeweils ein Mitglied des Teams einbezogen, das in der vorangegangenen Woche das technische Setup aufgebaut und betreut hatte. So war gleichzeitig sichergestellt, dass das Wissen permanent aktuell gehalten (z.B. wenn am Setup etwas optimiert wurde) und geteilt wurde. Unsere Teams hatten diesbezüglich einen hohen Grad an Selbstorganisation und gegenseitiger Unterstützung erreicht, was großartig ist.
Insgesamt war das Showtime-Konzept sehr erfolgreich und wurde von allen Beteiligten geschätzt. Dies konnte jedoch erst nach zahlreichen kleinen Schritten erreicht werden.
Fazit: Empathie und Systemverständnis
Es gibt zahlreiche Möglichkeiten, wertvolles Feedback zu bekommen und den Entwicklungsteams sowie deren Arbeit Wertschätzung entgegen zu bringen. Dennoch muss der Einsatz einer tollen Methode nicht zwangsläufig die Lösung des Problems sein – vor allem dann nicht, wenn es sich um eine lokale Optimierung handelt. Egal wie kreativ euer Ansatz ist, er wird nur dann auch langfristig zum Erfolg führen, wenn ihr empathisch seid für die Belange eurer Stakeholder und das gesamte System in den Blick nehmt.
So ist ein klassischer Grund für mangelndes Feedback beispielsweise die fehlende Verfügbarkeit von Stakeholdern aufgrund überfüllter Kalender. Dies wiederum kann verschiedenste Ursachen haben: unklare Verantwortlichkeiten, Unterbesetzung auf einer bestimmten Ebene oder in bestimmten Abteilungen eines Unternehmens, Unerfahrenheit in einer neuen Rolle (ein Klassiker in schnell gewachsenen Startups), fehlende Informationen und/oder Verständnis für den agilen Entwicklungsprozess… und vieles mehr.
Eine weitere Ursache für oben beschriebene Probleme kann im herrschenden Rollenverständnis oder auch in einem Mangel an Vertrauen und Akzeptanz liegen. Viele Unternehmen definieren die Rolle des Scrum Masters u.a. über die Beschränkung des Aktionsradius’ auf die Teamebene. Das ist vor allem dann problematisch, wenn es keine weitere Rolle gibt, die die dadurch entstehende Lücke füllt. In einigen Unternehmen gibt es zusätzlich Agile Coaches oder eine andere Rolle, bei der die agilen Fäden zusammenlaufen. Persönlich sehe ich auch Scrum Master in einer Rolle, die im ganzen Unternehmen wirken kann und sollte. Wie auch immer aber die Lösung aussieht, wichtig ist, dass ein Informationsaustausch zwischen Entscheidern und Agilisten überhaupt zustande kommen und etabliert werden kann.
Insofern ist die wichtigste Voraussetzung, Stakeholder für das Produkt und Entscheider im Unternehmen auf seiner Seite zu haben und mit ihnen an einem Strang zu ziehen. Dann können Termine und Methoden so gewählt werden, dass sie die Belange aller Beteiligten berücksichtigen und zum Ziel führen.
(Teil 1 zum Beitrag findest Du hier.)