iX | Gezielte Wahl (Teil 1)

Entsprechend dieser Prägung stellen agile Methoden Kommunikationsrituale in den Vordergrund, die parallel den zeitlichen Ablauf der Projektarbeit bestimmen. Aus dieser Taktung und den Kommunikationsergebnissen heraus lassen sich eine Projektplanung und andere schriftliche Artefakte ableiten.

Vertreter der agilen Bewegung fordern eine kommunikative Projektsituation, in der alle Beteiligten auf Augenhöhe miteinander sprechen und verhandeln. Software-Entwicklung soll nach Meinung der agilen Bewegung durch sich selbst organisiernde Teams erfolgen. Damit unterstellen die agilen Ansätze implizit, dass das Steuern eines Projekts durch einen zentralen Projektplan nicht machbar sei.

Die agile Bewegung versucht, über geeignete Methodenbausteine schnell und umfassend auf Anforderungsänderungen zu reagieren: „Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“ Dabei verstehen sich agile Teams als lernend. Durch den regelmäßigen Rückblick während des Verlaufs versuchen sie die Zusammenarbeit zu verbessern – und durch fortwährendes Optimieren die Liefergeschwindigkeit zu steigern.

Um diesen Lernprozess zu ermöglichen und frühzeitig Änderungsanforderungen als solche zu erkennen, setzt die agile Bewegung auf die regelmäßige und direkte Kommunikation der Beteiligten. Anschließend dokumentieren agile Projekte Vereinbarungen und Erkenntnisse schriftlich. 

Agile Ansätze sollen den Weg in eine positive Projektwelt weisen. Während Teammitglieder sich in der alten, klassischen Welt zu Ausführungsgehilfen des Managements degradiert fühlen können, verspricht die agile Bewegung eine gleichberechtigte Projektrolle. Doch gerade diese Rollenänderung erfolgt in vielen Unternehmen nicht. Arbeitet das gesamte Unternehmen klassisch-hierarchisch, ist ein Umgangswandel der beteiligten Manager für ein Softwareprojekt nicht zu erwarten.

Hinzu kommt die Rollenwahrnehmung der IT als solche: Sieht die Firma die Abteilung als ausführende Kraft – also als Teil der Produktion, die keine eigene Stimme beim Ausformulieren der Unternehmensziele hat, ist das erfolgreiche Einführen agiler Methoden nahezu ausgeschlossen. Die agile Bewegung sieht die IT als einen ebenbürtigen Partner im Unternehmen an und setzt auf Teamarbeit als Erfolgsmodell. In vielen Betrieben widerspricht das jedoch der Wirklichkeit.

Zum Einführen agiler Methoden müssen sich die Beteiligten über eine gewandelte Sicht des Projektumfelds einigen. Indem es die Rollen anpasst und neue Methoden einführt, reagiert das Team auf diese Veränderung. Dieses Vorgehen müssen diejenigen mittragen, die in der Hierarchie über der Mannschaft verankert sind. Alle zusammen müssen sich einigen, wie man Ziele definieren und ihr Erreichen überprüfen kann. Da die übergeordneten Manager meist nicht direkt von ihren eigenen Ritualen ablassen können, sind angepasste und dem agilen Projekt- vorgehen angemessene Berichtsinhalte ebenfalls zu bestimmen. 

Ein Übergang in die agile Projektwelt erfolgt in vielen Softwareteams vor dem Hintergrund hoher Unzufriedenheit mit der letzten Arbeit: Nicht selten ist direkt vor einem Wechsel ein Softwareprojekt gescheitert. Bei der Wahl einer neuen Methode favorisieren viele Mannschaften aktuell agile Ansätze. Schließlich haftet dem klassischen Wasserfall-Vorgehen der Ruf an, sie wären umständlich und würden nicht zum Erfolg führen. Und genau dies hätten ja die vergangenen Projekte bewiesen.

Diese generelle Aussage ist jedoch zu hinterfragen: Ist das letzte Projekt daran gescheitert, dass die klassische Projektmethode nicht passte – oder daran, dass man zu wenige Projektbausteine explizit und bewusst nutzte? In vielen Unterneh- men herrscht Wissensnotstand um Projektmethoden. Das inflationäre Nutzen des Worts „Projekt“ zeigt Wirkung. Viele im Team glauben, sie würden in einem klassischen Projekt arbeiten, während sie doch nur Aufgaben organisieren – und das mehr schlecht als recht.

Ein genauer Blick auf die verwendeten Ansätze und die genutzten Bausteine zeigt zweierlei:

• Das Projektteam hat eine der Situation angemessene Projektmethode etabliert, die jedoch keiner „Lehrbuch-Methode“ entspricht, aber mit einem Lehrbuchnamen charakterisiert ist. Das führt zu unterschiedlichen Erwartungshaltungen an Rollen und Rituale. Die Ergebnisse dieser Missverständnisse zeigen sich häufig spät im Projekt – und meist mit negativen Folgen für das Resultat.
• Nur wenige Beteilgte können bewusst alle genutzten Methodenbausteine benennen. SWBLM zeigt sich in Reinkultur. Durch den Wechsel der Mitarbeiter kann es sein, dass das Wissen über bisher genutzte Bausteine zum Nachteil des gesamten Teams wegfällt.

Eine Methode beinhaltet die Team- Rituale während des Projekts. Daneben existieren viele Verhaltensweisen und kleine Maßnahmen, die den Projekterfolg stützen. Gerade die sind wenigen Teams in ihrer Gesamtheit bekannt. Vor einem Wechsel des Ansatzes sollten sich daher Mannschaften vergegenwärtigen, welche Bausteine sie in ihrem Alltag gerade nutzen – und welche davon passend oder optimierungsbedürftig sind. Durch eine Reflexion des eigenen Verhaltens sichern sich die Teams dagegen ab, Bausteine abzuschaffen, die sie bisher weit getragen haben.