Kommunikation in der agilen Softwareentwicklung – Verbringen wir wirklich zu viel Zeit in Meetings?

„Softwaredeveloper verbringen ein Drittel ihrer Arbeitszeit in Meetings“, titelt heise online und beruft sich dabei auf eine Studie eines Anbieters von Zeitplanungssoftware. Auch ich stelle in meinen Teams immer wieder fest, dass Meeting-Zeiten häufig als zu lang und belastend empfunden werden. Ein Phänomen, das durch die Remote-Arbeit anscheinend noch verstärkt wird. Aber heißt das wirklich, dass wir zu viel Zeit in Meetings verbringen? Dazu möchte ich meine Gedanken mit euch teilen.

Schnell sind Lösungsvorschläge gefunden: Meeting-freie Zeiten oder gar Tage müssen her und damit wir diese auch einhalten, muss es auch gleich eine unternehmensweite Regelung sein. Trotz dieser Lösungsversuche verschwindet das Problem aber nicht. Ein untrügliches Zeichen dafür, dass wir das Problem noch gar nicht richtig verstanden haben und damit nur die Symptome bekämpfen.

Zunächst einmal gilt es festzuhalten, dass Meetings in aller Regel Ausdruck eines legitimen Kommunikationsbedarfs sind. Diesen zu unterbinden, ist daher so wirkungsvoll wie die Uhr anzuhalten, um Zeit zu sparen oder die Ölwarnlampe im Auto abzuschalten, wenn sie dauernd leuchtet.

Damit ich nicht missverstanden werde, natürlich sollte man Meetings auf das notwendige Maß beschränken und möglichst effizient ansetzen, vorbereiten und durchführen. Dafür gibt es aber in der agilen Softwareentwicklung altbekannte und gut bewährte Lösungen, wie ich im Folgenden noch verdeutlichen werde. Effizienz ist jedoch nicht die erste Frage, die wir beantworten müssen. Denn diese stellt nur sicher, dass wir die Dinge richtig tun. Wenn wir effektiv sein wollen, müssen wir aber die richtigen Dinge richtig tun und hierbei gibt es einiges zu beachten.

Um uns dem also zu nähern, sollten wir zunächst einmal unterscheiden, in welchem Kontext der Kommunikationsbedarf entsteht. Reden wir über teaminterne oder darüber hinausgehende Abstimmungen und Gespräche, zum Beispiel mit anderen Teams derselben Einheit, auf Steuerungsebene dieser Teams oder mit gänzlich anderen Einheiten?

Interne Kommunikation in agilen Teams

In unseren agilen Teams setzen wir auf typische Meeting-Formate wie Dailies, Refinements, Plannings, Reviews und Retrospektiven. Diese haben ihren Sinn darin, verlässlich zur richtigen Zeit die richtigen Dinge im richtigen Format zu besprechen.

Wenn unser Team die empfohlene Größe von acht bis zehn Personen nicht überschreitet, müssen wir hier also nur noch auf die effiziente Ansetzung, Vorbereitung und Durchführung achten. Dabei helfen uns entscheidend agile Prinzipien wie Eigenverantwortung, Selbstorganisation, Pull-Prinzip und Time Boxing. Außerdem sind gut gepflegte Sprint-/Product-Backlogs oder Kanban-Boards ebenso wichtig wie eine transparente, von allen akzeptierte Agenda. Ja, auch agile Meetings sollten m. E. eine Agenda haben, selbst wenn diese manchmal trivial erscheint. Ein paar nützliche Werkzeuge wie Jira, Confluence, Webex, Teams oder physische Kanban-Boards sind ebenfalls hilfreich, zumindest dann, wenn sie richtig und mit Bedacht eingesetzt werden und zuverlässig funktionieren.Wenn wir dann noch regelmäßig wertvolle Retrospektiven durchführen, können wir uns kontinuierlich verbessern.

Effizienzsteigerungen lassen sich dabei ggf. noch durch Verschiebung der Termine auf Randzeiten erreichen. Meetings können zum Beispiel morgens, unmittelbar vor oder nach dem Mittag oder vor Feierabend aneinandergereiht werden. Wobei ihr wiederum auf ausreichend Pausen zwischen den Meetings achten solltet. Außerdem solltet ihr darüber nachdenken, die mit einem Sprint-Wechsel verbundenen Meetings an einem Tag durchzuführen, statt diese auf mehrere Tage zu verteilen.

Was hingegen mit Bedacht betrachtet werden sollte, sind vermeintliche Effizienzsteigerungen durch Verlängerung der Frequenz von Regel-Meetings (etwa zweiwöchentlich statt wöchentlich). Hierbei verlängert sich nämlich i. d. R. nicht nur die Dauer der Meetings. Zudem entsteht häufig das Problem, dass die Klärung wichtiger Fragen dann zu lange aufgeschoben wird und somit effektiv wieder mehr Zeit zur Klärung benötigt wird. Deshalb nutzen wir heute auch Dailies statt der früher üblichen Jour-fixe-Termine und bevorzugen agile Sprints von zwei bis vier Wochen, statt klassische Großprojekte nur in wenige Teillieferungen zu unterteilen.

Es empfiehlt sich in der Regel also, solche Regel-Meetings eher kürzer, dafür aber häufiger anzusetzen. Wenn es dann mal keine Themen zu besprechen gibt, gilt grundsätzlich, dass ein Termin selbstverständlich auch kurzfristig abgesagt werden darf.

Kommunikation auf Steuerungsebene

Agile Teams arbeiten selten vollständig unabhängig voneinander. Meistens arbeiten sie parallel zu weiteren agilen Teams an ähnlichen oder ergänzenden Produkten. Hierbei muss die effektive Zusammenarbeit durch eine Steuerungsebene koordiniert werden. Das ist wesentlicher Bestandteil einer jeden agilen Skalierung.

Dabei helfen uns dieselben agilen Prinzipien und Werte wie auch innerhalb der Teams. Daher ist es sicher eine Überlegung wert, auch die gleichen agilen Formate zu nutzen (Dailies, Refinements, Plannings, Reviews, Retros), nur eben auf einer anderen Flughöhe und ggf. in einer anderen Frequenz. Diese Formate haben sich schließlich bewährt und stellen sicher, dass wir verlässlich zur richtigen Zeit die richtigen Dinge im richtigen Format besprechen. Auch hier können uns gut gepflegte Backlogs, agile Boards (z. B. auf Epic-Ebene für einen größeren Zeitraum) und nützliche Werkzeuge dabei helfen, die notwendigen Meetings effizient vorzubereiten und durchzuführen. Zusätzlich gilt es aber auf Steuerungsebene, auf klare Zuständigkeiten, Verantwortungen und Rollen zu achten. Hierbei kann uns z. B. die RACI-Matrix behilflich sein.

Team-übergreifende Kommunikation

Deutlich schwieriger wird die Sache bei der Team-übergreifenden Kommunikation, da hier der Bedarf stark davon abhängt, wie die Teams und ihre Produkte aufgestellt sind. Sind beispielsweise Querschnittsaufgaben durch eine lose Koppelung zwischen den Teams organisiert oder gibt es ein dediziertes Querschnitts-Team, das im Wesentlichen Governance-Funktionen ausüben soll?

Lose Koppelungen reduzieren in der Regel die Komplexität und verringern damit auch den Kommunikationsbedarf. Hilfreich kann es hier zum Beispiel sein, die Softwaredeveloper im Rahmen einer Community of Practice (CoP) selbst entscheiden zu lassen, welche Komponenten auf welche Weise wiederverwendbar entwickelt werden sollen.

Problematisch kann auch ein Team-Schnitt sein, der sich eher nach technischen Komponenten ausrichtet, die keinen eigenständigen Produktcharakter haben. Insbesondere wenn die gesamte Produktentwicklung stark vom Zusammenspiel aller beteiligten Teams abhängig ist. Obendrein fördert ein solcher Team-Schnitt meistens auch Spezialistentum und damit ungewollte Kopfmonopole. Besonders kritisch wird es, wenn starke Team-Abhängigkeiten außerhalb der direkten Einflusssphäre der Steuerungsebene existieren. Oder wenn die Steuerungsebene zu viele Teams gleichzeitig koordinieren muss. Da solche strukturellen Probleme in den wenigsten Fällen von den Teams selbst gelöst werden können, reagieren diese zuweilen mit Fokuszeiten, Sprechstunden oder ähnlichen Maßnahmen.

Hilfreicher ist es jedoch, wenn ihr gemeinsam mit der Steuerungsebene nach Lösungen sucht und dazu zunächst selbst ein paar kritische Fragen beantwortet:

• Mit wem habe ich den häufigsten Kommunikationsbedarf?
• Sind die wichtigsten Skills/Personen zumindest temporär im Team?
• Sind die Verantwortungen richtig verteilt oder hängen wir in unseren agilen Prozessen von außenstehenden Personen ab?
• Bringt jemand häufig Themen aus anderen Teams mit, bespricht diese in einem Team-Meeting und trägt dann die Ergebnisse oder schlimmer noch Rückfragen wieder in eine andere Runde?
• Wie können wir die Abhängigkeiten zu anderen Teams minimieren?

Ansonsten gilt es, die Eigenverantwortung der Teams zu stärken. Jede Stabs- oder Querschnittseinheit mit Entscheidungs- oder Weisungsbefugnis ohne Ergebnisverantwortung erhöht den Kommunikationsbedarf und erschwert damit die Team-Arbeit unnötig.

Ebenso wichtig ist es, die Kommunikationswege möglichst kurz zu halten. Nicht jede Team-übergreifende Kommunikation muss über die Steuerungsebene laufen, das unterscheidet die Steuerungsebene gerade von der klassischen Hierarchie. Ihr könnt euch die notwendigen Personen auch temporär in euer Team holen oder zumindest in eure agilen Team-Meetings einladen.

Erst dann solltet ihr unter Berücksichtigung der oben genannten agilen Prinzipien und Werkzeuge versuchen, die Effizienz eurer darüber hinaus erforderlichen Meetings zu steigern. Dabei sollten solche Meetings grundsätzlich freiwillig und selbstorganisiert sein. Regelmäßige Feedback-Runden, ROTI-Scores (Return On Time Invested) und eventuell auch Retros stellen ihre Nützlichkeit sicher.

Der Einfluss von Remote-Arbeit

Bleibt noch die Frage zu klären, ob der Trend zur Remote-Arbeit das Problem verschärft. Um den sozialen Zusammenhalt in den Remote-Teams zu stärken, setzen jedenfalls viele Teams auf zusätzliche Meetings wie informelle Kaffeerunden oder auch Einzelgespräche. Aber sind dies wirklich zusätzliche Meetings? Schließlich verabreden wir uns auch im Büro mal zum Kaffeetrinken oder Mittagessen. Oder wir diskutieren auf dem Weg zur Kantine miteinander über dienstliche wie nichtdienstliche Dinge. Aber zugegeben, hierbei verläuft die Kommunikation einfacher und flexibler. Letztlich ist das wohl auch eine Frage der persönlichen Wahrnehmung. Ich selbst weiß solche informellen Meetings durchaus zu schätzen, entscheide aber dennoch von Fall zu Fall.

Fazit

Effektivität ist mehr als Effizienz. Nur wenn wir richtig aufgestellt sind, können wir Abhängigkeiten unter verschiedenen Teams und den damit einhergehenden Kommunikationsbedarf minimieren. Denn wie sagte Einstein doch einst: „Das Problem zu erkennen, ist wichtiger, als die Lösung zu erkennen, denn die genaue Darstellung des Problems führt zur Lösung.“