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