Brauchen wir all diese agilen Meetings? Tipps aus der Zeitfresser-Falle

Wenn man dann noch in einem hochskalierten Umfeld mit vielen, mehr oder weniger abhängigen Produkten arbeitet, kommen noch die sogenannten PI-Plannings dazu. Alle diese Meetings sind wohl definiert mit Agenda, einer klaren Zielsetzung, einem Moderator und einer festgelegten Teilnehmerschar. Wichtige Voraussetzungen für gute Meetings. Trotzdem passiert es im Projektalltag immer wieder, dass die Beteiligten gerade diese wichtigen Meetings als Zeitfresser empfinden. Warum ist das so? Und wie können wir die Meetings wieder zu den wertstiftenden Synchronisationspunkten machen, als die sie gedacht sind? Dieser Frage sind wir in unserem internen Best Practice Austausch „Scrum Lunch“ nachgegangen.

Fünf Kernprobleme agiler Meetings und wie wir sie lösen können

Sowohl den Auftraggeber, den Product Owner als auch das Entwicklungsteam verbindet das Grundbedürfnis, die Zeit für die Entwicklung nutzen zu können und mehrwertstiftende Features zu entwickeln. Den Entwicklungsteams ist dabei klar, dass es mittelfristig enorme Auswirkungen auf genau diese Entwicklung neuer Features hat, wenn man Meetings ganz entfallen lässt. Die Entwicklung kann dann auf missverstandenen Anforderungen und Annahmen aufsetzen, Blocker werden nicht so schnell identifiziert und beseitigt oder das Team setzt falsche Prioritäten bei der Bearbeitung seiner Tasks. Das führt dazu, das mittelfristig weniger Zeit für die Entwicklung bleibt und im worst case „das Falsche“ entwickelt wird. Die Folgen sind nicht nur Mehraufwände, sondern Frust auf beiden Seiten.

Wenn Auftraggeber oder Product Owner die agilen Meetings als Last empfinden und ihren Mehrwert nicht mehr wahrnehmen, dann hat das meist mit grundlegenden Problemen im Projektsetup zu tun. Und die sind lösbar.

In unserem Best Practice Austausch haben wir fünf Kernprobleme identifiziert, die die Wirksamkeit der agilen Meetings verpuffen lassen und Ansätze gefunden, wie man sie beheben kann:

Tatsächlich gibt es Projekte, die zu einfach für Scrum sind. Wenn die Anforderungen an das Produkt klar sind, die technologische Lösung keine Herausforderung darstellt, der zeitliche Umfang überschaubar und das Team sehr klein ist, dann ist ein Vorgehen wie Scrum einfach der falsche Ansatz. Die Zeit für die Meetings steht dann in keinem Verhältnis zur Umsetzungszeit und die Synchronisation bringt keinen Mehrwert.
Das kann man tun: Das Cynefin Framework kann hier helfen, von vornherein den richtigen Projektmanagement Ansatz zu wählen. Dabei muss man nicht gänzlich auf agile Elemente verzichten. Review und Retro sind z.B. die Motoren des Lernprozesses und können auch in einem weniger komplexen Umfeld eine große Hilfe sein.

Wenn das Projektumfeld durch viele fachliche und technische Abhängigkeiten geprägt ist, steigt die Komplexität rasant an. Abhängigkeiten erfordern einen hohen Abstimmungs- und Koordinationsaufwand. Dieser bremst das Projekt aus und führt gleichzeitig potenziell zu mehr Missverständnissen. In dieser Situation auf Meetings zu verzichten, verschärft die Situation nur.
Das kann man tun: Es ist wichtig, zu prüfen, ob fachliche und technische Abhängigkeiten zwischen den Systemen abgebaut werden können. Der Aufbau des Systems und der Schnitt der Featureteams sollte so wenig wie möglich und nur so viel wie nötig Schnittstellen umfassen. Anders ausgedrückt: der Schnitt zwischen den Microservices eines Systems muss richtig gewählt werden (bspw. mittels Domain-Driven Design) und die Teams können den Systemen dann passend zugeordnet werden (siehe auch (Inverse) Conway’s Law).

Natürlich ist die Welt nicht ideal und wir können uns nicht immer zu 100 Prozent mit nur einem Projekt auseinandersetzen. Tagesgeschäft oder weitere ganz dringliche Projekte zwingen uns, unsere Kapazität auf mehrere Themen aufzuteilen. Wenn der größte Teil der Projektmitglieder aber nur mit Splitterkapazitäten am Projekt arbeiten kann, dann werden die Meetings zur Last und die Organisation wird enorm schwierig.
Das kann man tun: Die erste Frage in dieser Situation lautet: Lassen sich nicht Aufgaben besser verteilen, um weniger Teammitglieder mit mehr Kapazität im Projekt zu haben? Und wenn jemand mit ganz wenig Kapazität unabdingbar für das Projekt ist, muss er dann als festes Teammitglied eingesetzt werden oder gibt es nicht Alternativen? Wenn hier keine Lösung in Sicht ist, muss der eigentliche Sinn der Meetings in den Fokus genommen und alternative Lösungen für Synchronisation, Planung, Schätzung, Lernprozess am Ergebnis und am Prozess gesucht werden.

Die Teilnehmerzahl in agilen Meetings ist zu groß

Eine zu große Teilnehmerzahl hat immer zur Folge, dass nicht alle mit der gleichen Aufmerksamkeit dem jeweiligen Beitrag folgen. Das heißt, für sie entfaltet sich der Nutzen des Meetings tatsächlich nur eingeschränkt. Das soll so nicht sein. Deswegen gilt es hier, zügig Lösungen zu finden, um Frust zu vermeiden.
Das kann man tun:

1. Ist das Featureteam zu groß? Teams mit mehr als sieben Personen sollten geteilt werden.
2. Gibt es Teilnehmer mit speziellen Aufgaben (z.B. Ops oder Testing), die nicht an der Feature Entwicklung beteiligt sind? Dann bietet sich z.B. im Backlog Refinement ein mehrstufiges Verfahren an. Zunächst wird der Überblick über die Feature im Backlog hergestellt. Den sollten alle bekommen. Beim „Kneten“ der einzelnen User Stories müssen die Kollegen mit speziellen Aufgaben nicht dabei sein.
3. Hat der Kunde/Product Owner zu viele Produkte? Dann sollte er von allen Meetings entlastet werden, die optional sind. Meist werden optionale Termine im Kalender dennoch als Verpflichtung wahrgenommen. Hier hilft es, den Product Owner gar nicht einzuladen, und alle Meetings im Projekt WIKI transparent zu machen.
4. Erfolgt eine Skalierung über ein Rahmenwerk wie SAFE (Scaled Agile Framework) mit riesigen PI-Meetings? Die Product Increment (PI) Meetings sind dazu da, Schnittstellen transparent zu machen und für das nächste Release abzustimmen. Wenn die Produktdomäne sehr groß ist, werden auch diese Meetings groß. Idealerweise sind die Entwickler in diesen Meetings dabei. Sie können allerdings schlanker gestaltet werden, wenn nur ein Teil der Mannschaft teilnimmt. Das erfordert in den Teams eine sehr gute Vorbereitung und ist damit gut für die Qualität.
5. Wenn sich die Meetings nicht verkleinern lassen und die Relevanz der Themen sich nicht vorab eindeutig z.B. über die Rolle des Teilnehmers festlegen lässt, dann kann man auch einen OpenSpace Ansatz wählen. Ein Beispiel: Im Falle des Backlog Refinement werden kurz alle User Stories vorgestellt. Die Entwickler entscheiden dann, welche für sie besonders relevant sind und an welchem Refinement sie teilnehmen möchten.

Die agilen Meetings erreichen nicht, was sie sollen

Wenn der Sinn des jeweiligen Meetings nach und nach aus den Augen verloren wurde, kann es passieren, dass es zweckentfremdet wird. Dann wird z.B. ein Daily gerne genutzt, um technologische Details zu besprechen. Es wird damit zu lang und nicht jedes Teammitglied kann einen Beitrag leisten. Und obwohl die Zeit überzogen wird, bleibt die Synchronisation auf der Strecke.
Das kann man tun: Es ist ein dauernder Prozess der Refokussierung, um die Meetings auch richtig nutzen zu können. Der Agile Master (oder Scrum Master) ist hier permanent gefordert, gegenzusteuern. Das bedeutet in unserem Beispiel auch, dass für die Auseinandersetzung über technologische Details der notwendige Raum an anderer Stelle geschaffen wird.

Die Eingangsfrage „Brauchen wir all diese agilen Meetings?“ beantworten wir mit einem klaren „Ja“. Wenn die Meetings mehr belasten als nutzen, gilt es, ganz genau auf die Ursachen zu sehen. Dann findet sich die richtige Stellschraube, um agil wieder auf Spur zu kommen.

Mehr zu agilem Projektmanagement