Mit der Einführung agiler Methoden in der Softwareentwicklung sollte doch alles besser werden. Die Geschäftsleitung hatte sich die größte Mühe gegeben und keine Kosten gescheut, um die Transformation in die neue Welt vorzubereiten: Sie informierte die Mitarbeitenden regelmäßig über die nächsten Schritte und schickte sie auf Lehrgänge, bei denen sie die agilen Methoden und Rollen kennenlernten. Zudem schaffte sie neue Tools an, um die neuen Prozesse darin abzubilden. Agile Coaches begleiteten den Change-Prozess.

Etwa ein Vierteljahr nach der Einführung stellte die Geschäftsführung fest, dass sich der Output, also die Anzahl der neuen Softwareprodukte, nicht erhöht hatte. Schlimmer noch, es gingen weniger Funktionen live und diese enthielten mehr Fehler als zuvor. Die Geschäftsführung fragte sich, wie es dazu kommen konnte. Sie hatte doch an alles gedacht, um den Weg in die agile Zukunft reibungslos gehen zu können.

Projektmanagementmethoden und Tools allein garantieren keinen Projekterfolg

Nicht beachtet hatte sie jedoch den hohen Stellenwert der Kommunikation – sowohl innerhalb der agilen Teams als auch im Austausch mit den verschiedenen Anspruchsgruppen. Es sind das Entwicklungsteam, die Rollen Product Owner und Scrum Master sowie die beteiligten Stakeholder, die bei der agilen Arbeit nach Scrum täglich in einem neuen Umfeld miteinander arbeiten und eben auch kommunizieren. Die Basis dieser agilen Zusammenarbeit liegt in den agilen Events.

"Agil" ist (immer noch) in aller Munde, es gibt verschiedene Ansätze, diese Projektmethode einzusetzen. Meine Erfahrung ist, dass in vielen Fällen nicht streng nach Scrum gearbeitet wird, die Events aber häufig dennoch in der einen oder anderen Form durchgeführt werden. Um dem gerecht zu werden, wähle ich für diese Artikelserie – in Abweichung vom Scrum Guide – eine etwas freiere Benennung der vier Events, die ich so aus meinem Praxisalltag kenne: Daily Standup, Planning, Review und Retrospektive. Während dieser Events treffen die Personen regelmäßig zusammen und gestalten ihre Arbeit. In diesen Meetings ist es enorm wichtig, dass kommunikative Fallen nicht den gemeinsamen Projekterfolg gefährden.

Wie eine gute Kommunikation in diesen agilen Events gelingen kann, ist Inhalt dieser zweiteiligen Artikelserie. Im ersten Teil stehen Kommunikationsmöglichkeiten für das Daily Standup und das Review im Mittelpunkt. Im zweiten Teil erfahren Sie, wie Sie das Planungsmeeting und die Retrospektive mithilfe von Kommunikationsmethoden effektiver und erfolgreicher durchführen.

Ich möchte mit den beiden Artikeln zeigen, dass es nicht die angewandten Projektmanagementmethoden oder die eingesetzten Tools sind, die zum Projekterfolg führen. Vielmehr bringt die richtig angegangene Kommunikation der Projektbeteiligten ein Projekt mit weniger Konflikten und mehr Klarheit in kürzerer Zeit erfolgreich ins Ziel.

Fachlichkeit hui, Kommunikation pfui

Auch für agil durchgeführte Softwareprojekte gilt die Aussage, dass ein Großteil von ihnen scheitert oder erst verspätet oder mit abgespecktem Funktionsumfang in die Produktion gelangt. Die Gründe des Scheiterns liegen oft nicht an der Fachlichkeit. Diese ist in vielen Fällen bekannt, man kann aus ihr die Anforderungen an die zu entwickelnde Software ableiten. Das Entwicklungsteam verwendet z.B. Java und legt die Daten in einer Oracle-Datenbank ab.

Zudem kommen die Expert:innen und Spezialist:innen, die ein Vorhaben entwickeln und durchführen, häufig aus verschiedenen Disziplinen, sodass das Projekt auf ein breites Know-how zurückgreifen kann. Doch trotz der scheinbar guten Rahmenbedingungen gehen Projekte schief: Die Produkte sind im skizzierten agilen Umfeld zum geplanten Zeitpunkt nicht vollständig einsatzbereit.

Die Knoten-Formel: Von Graphen und Knoten zur Kommunikation im Team

Die Ursache dafür, dass auch in agilen Projekten die Ergebnisse stark von den Erwartungen abweichen, liegt in dieser kleinen mathematischen Formel:

(n-1)*n/2 = K

Die eine oder der andere wird sie aus der Graphentheorie kennen, welche als Wissenschaft von Netzwerken insbesondere in der diskreten Mathematik und der Informatik eine Rolle spielt. Der Term beschreibt die mögliche Anzahl der Verbindungen (K) zwischen einzelnen Knoten (n). Was hat das mit agilen Projekten zu tun?

Ganz einfach, ersetzen Sie den abstrakten Begriff "Knoten" durch Person und denken Sie bei "Verbindung" an "Möglichkeit, zu kommunizieren". Nehmen Sie nun die Zahl Fünf als durchschnittliche agile Projektgröße und setzen diesen Aktualparameter in die Formel ein:

(5-1) * 5/2 = 10

Bedenken Sie, dass Kommunikation keine Einbahnstraße ist und in stets in zwei Richtungen erfolgen kann. Sie müssen das Ergebnis also verdoppeln (10 * 2 = 20). In einem agilen Team mit einer durchschnittlichen Teamgröße von fünf Personen besteht demnach 20-mal die Möglichkeit, jemanden "auf den Schlips zu treten", misszuverstehen oder die Bedürfnisse des Gegenübers nicht zu erkennen. Ist dies der Fall, sind Konflikte innerhalb des Teams unausweichlich.

Erkennt oder schlichtet das Team diese nicht frühzeitig, herrscht eine schlechte Stimmung, die eine produktive und effektive Arbeit behindert. Und schon ist die Möglichkeit, dass das agile Projekt scheitert, einen Schritt näher gerückt.

Dieses Beispiel bezieht sich lediglich auf ein kleines agiles Team. Das Team kommuniziert ständig sowohl intern als auch extern mit beteiligten Personen. Oder, wie der österreichische Philosoph Paul Watzlawick es formulierte: "Man kann nicht nicht kommunizieren." (Watzlawick, Beavin, Jackson 1969, S. 53) Bezieht man sämtliche Stakeholder mit ein, die in einer Beziehung zum Team stehen, erhöht sich die Anzahl der Kommunikationsmöglichkeiten – und daraus abgeleitet die Zahl der potenziellen Konflikte.

Mit Kommunikationsmethoden Bewusstsein für agile Werte fördern