kommunizieren in agilen Projekten

Reden und reden lassen – Kommunikation in agilen Projekten

Martin Lederer - metaMind
Solutions Architect
Mehr erfahren

Kommunikation hat in allen Bereichen des Lebens einen ausgezeichneten Ruf. Sie gilt als Garant für wohlerzogene Kinder, stabile Ehen und Projekterfolge. Vom „Drüber reden“ scheint alles erst mal nur besser zu werden. Aber alles hat seinen Preis.

Niemand käme ernsthaft auf die Idee, Maurer oder Zimmermänner, Autoren oder Lektoren, Mechaniker oder Fahrzeugingenieure mehrmals täglich aus ihrer Arbeit zu holen und sie in ein Meeting zu setzen, in dem ihr Expertenwissen eher selten gebraucht wird. Softwareentwickler hingegen werden oft und gerne zum Austausch gebeten, denn Machbarkeit hängt zentral an der Software, und Entwickler sind natürlich fast immer von den Entscheidungen der Stakeholder betroffen.

Das Hohelied der Kommunikation erklingt besonders laut unter den Dächern der „Agilen“, deren wichtigste Maßnahme für die Transformation klassischer Organisationen eine Veränderung der Kommunikationsströme und -gewohnheiten ist. Allerdings ist Kommunikation hier nicht nur irgendwie wichtig, sondern das unabdingbare Bindemittel, das die Prozessteile im Projekt zusammenhält! Es gibt eben keine festen Übergabepunkte mit formaler Dokumentation wie beim Wasserfallmodell, das oft fehlschlägt, weil es an festen Formalien Schaden nimmt oder schwerfällig darüber gehoben werden muss.

Für die Transformation von klassischen Organisationen ist Kommunikation besonders wichtig, um die Prozessteile innerhalb eines Projektes zusammenzuhalten (Quelle: Adobe Stock / insta_photos).

Vom Scrum-Regeltermin auf die Tonspur

Abstimmungen in agilen Projekten

Fachliche und technische Abstimmungen laufen oft auf der Tonspur (Quelle: Adobe Stock /Syda Productions).

Was nicht heißt, dass Scrum-Agilität keine Regeltermine mit festgesetztem Thema kennen würde: Daily Stand-Ups, Retros, Planning Poker, Storys lesen, schätzen, zurückgehen lassen, Reviews, Refinements – um nur die Wichtigsten zu nennen. Auch fachliche und technische Abstimmungen mit, ohne und zwischen den Entwicklern sind vorgesehen und für den Erfolg notwendig, obwohl sie in keinem Terminplan auftauchen. Die einzeiligen Story-Titel ohne weitere Beschreibung sind oft nur Platzhalter für eine Erklärung auf der berüchtigten „Tonspur“.

Kommunikation – viel hilft viel!

Austausch und Kommunikation wird darüber hinaus als zuverlässiges Hausmittel gegen jedes Zipperlein verabreicht, von niedriger Code-Qualität bis zum unverständigen Kunden. Eine Überdosierung scheint nicht bekannt, so dass eher mehr als weniger bunte Rechtecke ihren Weg in die Kalender der Entwickler finden, denn „viel hilft [schließlich] viel“.

Die Teilnahme an vielen Meetings führt dazu, dass die eigentliche Arbeit auf der Strecke bleibt (Quelle: Adobe Stock / Elnur).

In den Besprechungen ist grundsätzlich jede Frage erlaubt, das Verständnis und das Interesse aller Stakeholder an dem, „was passiert“, ist ein hohes Gut und wird ermutigt: Was ist möglich, was ist sinnvoll, wie kann man? Dabei bleibt die eigentliche Arbeit auf der Strecke, woran auch das Gerede vom produktiven „Flow“ bisher nichts geändert hat. Die Folgen im Arbeitsalltag bleiben nicht aus. Einige Beobachtungen:

  • Ein Finanzfachmann lässt sich die Grundzüge der Softwareentwicklung erklären, wie ein Sprint abläuft und was es mit Storypoints auf sich hat. Das Problem ist, dass der Burndown zu gering ausfällt. Er gibt engagiert Ratschläge, was man noch tun und untersuchen könnte.
  • Ein Entwickler soll von einem Team in ein anderes, „schwächeres“ Team wechseln, um dort zu unterstützen. Er will aber nicht. Es kostet mehrere Nachmittage mit beiden Teams in gemeinsamer Sitzung und externer Moderation, bis man überraschenderweise keine Alternative findet und der Entwickler schweren Herzens das Team wechselt.
  • Ein Entwickler fragt in der Retro, ob man nicht mehr Zeit für die Entwicklung blockieren könnte. Die Scrum Masterin geht nach der Retro eine gute halbe Stunde mit ihm seine Besprechungen des letztens Sprints durch und findet, das wohl zumindest die meisten Treffen sehr gut investiert gewesen seien.
  • Wann er am produktivsten sei, wird ein Entwickler gefragt. „So abends ab fünf, halb sechs.“ Wenn alle gegangen seien, wirft sein Kollege ein. Und wie viel produktiver? „Ach, wir schaffen dann von fünf bis sieben am meisten.“

Wie man den Flow stoppt

Ein Scrum-Coach würde die Hände über dem Kopf zusammenschlagen und eine Menge „Kommunikation“ auf das Problem werfen. Allerdings ist durchaus bekannt, dass treffen, reden und austauschen beileibe nicht kostenlos ist. Mindestens muss man Zeit, Aufmerksamkeit und einen Wechsel zwischen Kontexten investieren („No more flow“). Ist nun etwas nicht kostenlos, kann sich die Investition eventuell nicht lohnen.

Vielleicht sollte man Entwickler nicht nur vor Releases und wichtigen Präsentationen „mal arbeiten lassen“ – sondern ganz generell? Und womöglich nicht nur Entwickler, sondern auch Product Owner und alle anderen? Man könnte beispielsweise Arbeitsweisen und -rollen in Kommunikationsarbeiter und Informationsarbeiter auftrennen, um die Aufgaben zu verdeutlichen. Denn ohne Struktur und Regeln wirkt Kommunikation wie eine Brandung, der das gesamte Team schutzlos ausgesetzt ist.

Kommunikation ist wichtig, trotzdem sollten alle konzentriert arbeiten können (Quelle: Adobe Stock / deagreez).

Trade-off zwischen reden und arbeiten

In den Kursen zu agiler Organisation lernt man leider nicht, wie und wie oft man kommuniziert. Da es sich aber bei der Kommunikation um den zentralen Bestandteil dieser Methodik handelt, könnte man vielleicht ein Gespräch zum Thema ins umfangreiche Scrum-Setup einstellen: „Wieviel wollen wir nicht reden, wieviel wollen wir nicht arbeiten?“

Quelle Titelbild: AdobeStock/pio3

Martin Lederer - metaMind
Solutions Architect
Mehr erfahren

Weitere Beiträge

Risk & Security

Cybersecurity im Automobilbereich: die neue ISO 21434

Weiterlesen
Risk & Security

Messenger-Security-Check: Wie sicher sind die täglichen Begleiter?

Weiterlesen
Human & Relations

Warum Meinungsvielfalt eine Chance ist

Weiterlesen

Kommentieren

Diesen Beitrag teilen

Alle Beiträge von
Agile & Organisation