Gemeinsame Reviews

Bild: Pxhere / Rawpixel - CC0 1.0

Ob in Scrum nach jedem Sprint oder in Kanban oder anderen Frameworks je nach Bedarf - Review Meetings in denen der neueste Produktfortschritt den Auftraggeben und Nutzern vorgestellt und mit ihnen diskutiert wird sind ein zentraler Bestandteil agiler Vorgehensweisen. In der Regel hat dabei jedes Team ein eigenes Review-Meeting, allerdings kann es Konstellationen geben in denen gemeinsame Veranstaltungen Sinn machen.

Am naheliegendsten in das im Rahmen agiler Skalierung. Wenn mehrere Teams an einem gemeinsamen Produkt oder in einem gemeinsamen Projekt arbeiten sind mit grosser Wahrscheinlichkeit die Themen aller Teams miteinander verwandt, vor allem dann wenn sie in Release Trains oder anderen gemeinsamen Taktungen arbeiten. Da auf diese Art ein gemeinsames Increment entsteht (oder zusammen passende Incremente entstehen) macht auch eine gemeinsame Präsentation und Diskussion Sinn.

Ein weiterer Anwendungsfall für gemeinsame Reviews ist gegeben wenn mehrere Teams an einer gemeinsamen Codebasis arbeiten in der es keine teambasierte Code Ownership gibt. Das Review kann in dem Fall der passende Ort sein um sich einen Überblick darüber zu verschaffen welches Team an welcher Stelle Änderungen vornimmt. Das Risiko bei einem solchen Vorgehen ist, dass die Veranstaltung zu technisch wird und dadurch andere Zielgruppen abschreckt. Gegebenenfalls macht daher ein gemeinsames technisches Review separat vom fachlichen Review Sinn.

Im Rahmen geografisch verteilter Firmen können gemeinsame Reviews Teil von Events sein mit denen der standortübergreifende Zusammenhalt gefördert wird. Im Rahmen von Präsentationen und Diskussionen können die Mitglieder der jeweiligen Teams direkt miteinander interagieren, was erfahrungsgemäss deutlich intensiver ist als gemeinsame Videokonferenzen. In diesem Kontext haben die Meetings damit eine zusätzliche soziale Funktion.

Zuletzt kann in Firmen mit vielen Teams ein gemeinsames Review eine Notwendigkeit sein um die Kalender der Stakeholder zu entlasten. Man kann sich das einfach vorstellen: wenn 15 Teams gemeinsam an einem Webshop bauen und jedes Ein- oder Zweiwochensprints hat, dann kämen bei separaten Sprint Reviews bis zu 60 Stunden pro Monat zusammen die man alleine in diesen Meetings verbringen könnte, Anlauf- und Abklingzeiten nicht mitgerechnet. Ein Zusammenlegen kann hier für Erleichterung sorgen (wobei aber immer noch gewährleistet sein muss, dass Austausch stattfinden kann).