Vieles ist darüber geschrieben worden, wie effektive Meetings ablaufen (sollen). Es geht um die Agenda, die Suche nach den richtigen Teilnehmern, über das abschließende Protokoll, den Redeanteil der Teilnehmer, die Räumlichkeiten und vieles mehr. Was aber vielfach garnicht mehr zum Tragen kommt, ist die Frage nach dem Grund der Veranstaltung. Die Frage nach dem „Warum?“
Vielfach institutionalisierte Meetings mögen vielleicht mal einen Grund gehabt haben, haben diesen aber schon lange verloren und sind zu einer Form des Cargo Kult verkommen: Man zelebriert die vormals sinnvollen Regeln als Zweck an sich, hinterfragt diese aber nicht mehr. Werden im Projekt dann Erfolge erzielt, so ist dies die Bestätigung alle Meetings auch möglichst unverändert beizubehalten.
Warum?
Stellt man sich also die Frage, warum sollte ein konkretes Meeting stattfinden, so lassen sich zwei klare Bereiche identifizieren: Weitergabe von Information und/oder Erstellung eines Arbeitsartefakts.
Handelt es sich um Information, so sollte ein Meeting einfach nicht stattfinden. Was ist der Mehrwert eine Information vorgetragen zu bekommen gegenüber einer schriftlichen Form? Meiner Meinung nach: Keiner! Im Gegenteil: teilweise sitzen eine nicht unerhebliche Anzahl Mitarbeiter in diesen Meetings, die unproduktiv konsumieren. Auch zeigt die Erfahrung, dass solche Veranstaltungen gerne mal dazu genutzt werden, den Vortragenden unter Druck zu setzen und seine Information kritisch zu hinterfragen.
Sollte denn dann nicht nach jedem Meeting, in dem gerne mal eben ein Manntag verbraten wird, ein Arbeitsergebnis stehen? Ein Inkrement, vielleicht nicht des Produktes, aber doch eines benötigten Artefaktes, wie ein Teil des Handbuches, ein Teil des Management Reports usw?
Zusammenkünfte, in denen in einer (kleinen) Gruppe gearbeitet wird, heißen aus gutem Grund nicht einfach Meeting, sondern eher Workshop. Workshops sind eine Zusammenkunft, in denen mit Hilfe geeigneter Methoden, unter Moderation und Anleitung ein Arbeitsergebnis erstellt wird.
Wider die sinnlose Meeting-Flut
Nicht nur in einer klassischen Umgebung, sondern auch (und vielleicht auch besonders) in einer agilen Umgebung, regt man sich gerne über die hohe Anzahl an Meetings auf und empfindet sie als Last, die die Mitarbeiter davon abhält die „eigentliche“ Arbeit zu tun. Wenn man diejenigen mal außen vor lässt, die als ihre „eigentliche“ Arbeit ansehen, vor ihrem Rechner zu sitzen und Code zu schreiben (im Rahmen von Softwareentwicklung, natürlich), ist das durchaus eine berechtigte Anmerkung.
Die Scrum Zeremonien sind genau darauf ausgelegt, aber leider vielfach noch nicht konsequent gelebt. In ihnen wird ein Teil der „eigentlichen“ Arbeit erledigt.
Das Daily ist nicht ein Meeting, um die Arbeit der Teammitglieder zu reporten, sondern ein Koordinierungsmeeting. Wer arbeitet mit wem an was? Wer benötigt von wem Unterstützung, wer hat etwas Zeit und kann seine Unterstützung anbieten? Welche Probleme habe ich, die dem Team bekannt sein müssen, damit sie mir helfen können und/oder u.U. nicht in die gleiche Falle tappen? Was wurde abgeschlossen und muss von den Kollegen nicht mehr berücksichtigt werden?
Laut Scrum Guide ist das Refinement kein Meeting sondern ein fortlaufender Prozess. Organisiert man das Refinement als Zusammenkunft des Teams, so ist es definitiv kein Story-Vorstellungsmeeting, in dem der PO seine Vorstellungen verkündet und über die weitere Arbeit informiert, sondern eine Zeit, die Arbeit der nächsten Sprints vorzubereiten, zu formulieren und zu detailieren und ein gemeinsames Verständnis der zukünftigen Arbeit zu entwickeln (samt eines grundlegenden Forecasts). Es entsteht im besten Falle ein Teil der Anforderungen (inklusive der Abnahmekriterien), die fortgeschrieben werden und selbstverständlich ein Teil der zu erstellenden Arbeitspakete sind.
Ähnliches gilt, ohne in Details zu gehen, auch für die anderen Scrum-Zeremonien.
Ein Meeting, was nicht originär zum Scrum Kanon zählt, ist das Peer Programming. Dabei handelt es sich um ein Arbeitsformat, bei dem die Arbeit von zwei Mitarbeitern zusammen erledigt wird. Sinnvoll ist das Peer Programming nicht nur dadurch, dass ein Arbeitsinkrement (im Falle der Softwareentwicklung ja nun auch ein Teil der Software) erstellt wird, sondern auch dass die Arbeit effizienter und effektiver gestaltet werden kann.
Fazit
Egal, ob in einem agilen oder eher klassischen Umfeld gearbeitet wird: Geht es in einem Meeting hauptsächlich um Informationsweitergabe, so ist das ein starkes Indiz dafür, dass diese Veranstaltung überflüssig ist.
In Meetings sollte immer ein Teil der Arbeit entstehen, ein Plan, ein Teil der Anforderungen, Entscheidungen jeglicher Art usw. Workshops und andere alternative Formate sind mit Hilfe geeigneter Methoden und Moderation geeignet dies zu erreichen.
