Warum müssen wir agile Verfahren anwenden?

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Beim Blättern in unserem APM-Buch (manchmal ist es gut, nicht nur zu schreiben, sondern auch zu lesen) bin ich gleich beim ersten Kapitel auf ein Zitat gestoßen und ich dachte darüber nach, warum es dort steht.

„Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut“, soll einmal Winston Churchill gesagt haben. Was meinte Churchill damit und warum liefert er damit das Kernargument für agile Software- und Systementwicklung?

Als britischer Premierminister und das noch zu Kriegszeiten, legte er seine Aufmerksamkeit sehr wahrscheinlich auf die Handhabung von Überraschungen. Je mehr Überraschungen auftreten, desto flexibler bzw. agiler müssen die Akteure sein, die überrascht werden. In der Softwareentwicklung hat die Häufigkeit und Schwere von Überraschungen Ende des letzten Jahrhunderts ein Maß erreicht, bei dem triviale Entwicklungsmethoden nach Wasserfall versagen.

Mit welchen Überraschungen haben wir es üblicherweise zu tun?

• Die Umwelt von Entwicklungsprojekten ändert sich:
  • Gesetzgebung
  • Neue Ideen des Auftrag- bzw.Anforderungsgebers
  • Interessen und Machtverhältnisse wichtiger externer Akteure
  • Verhalten von Mitbewerbern des Auftraggebers, beispielsweise neue Strategien, Ankündigungen, Wettbewerbsprodukte, Preis- oder Kostensituationen.
  • Neue technische Möglichkeiten oder Herstellungsverfahren
  • Der Auftraggeber ändert seine Prioritäten, seine Investitionsbereitschaft oder hat einfach nicht mehr genügend Geld für das Projekt.
• Auch innerhalb des Projektes gibt es Überraschungen aller Art:
  • Neue Erkenntnisse über das zu entwickelnde Produkt, die Anforderungen daran oder zum Entwicklungsprozess
  • Neue Ideen zur Gestaltung oder zu Eigenschaften des zu entwickelnden Produktes
  • Zweifel, Ängste, Unsicherheiten zu bestimmten Aspekten oder Anforderungen
  • Beteiligte Experten, Könner oder andere wichtige Ressourcen schwinden oder fallen nennenswert aus, bspw. durch Krankheit, Fluktuation oder wegen anderer wichtigerer Aufgaben.
  • Interessen und Machtverhältnisse innerhalb der Entwicklungsorganisation
• Annahmen erweisen sich als unzutreffend:
  • Geschätzte Aufwände, Termine o.Ä.
  • Produktivität oder Verfügbarkeit von Mitarbeitern
  • Vorhandene Risiken und Hindernisse

Überraschungen dieser Art treffen während der gesamten Projektlaufzeit immer wieder auf das Projekt. Wird jetzt ein Entwicklungsprozess wie bspw. ein Wasserfallmodell angewendet, der die Handhabung von Überraschungen nicht kennt, ist die Entwicklungsorganisation maßlos überfordert und havariert: Überraschungen und Fehler werden erst sehr spät erkannt. Bis dahin wiegen sich alle in vermeintlicher Sicherheit oder Zufriedenheit. Und wenn sie erkannt werden, verschlimmert die mangelhafte Anpassungsfähigkeit der Entwicklungsorganisation und ihrer Prozesse alles noch.

Es hilft vor allem nicht, sich über diese Überraschungen zu beklagen, selbst wenn sie ungerecht sind oder gar der Auftraggeber für sie verantwortlich ist. Es liegt in der Natur von Menschen und ihren Organisationsformen, dass sie permanent miteinander kommunizieren, dabei Informationen austauschen, Wissen und Ideen generieren und Entscheidungen (zu neuen Handlungen) treffen.Und ebenso ist es völlig normal, dass wir Menschen in der aktiven Auseinandersetzung mit einem Gegenstand (also bspw. beim Programmieren oder fachlichen Modellieren) Fragen erzeugen, Thesen bilden, Ideen entwickeln, kreativ werden, lernen. Wir können das gar nicht verhindern und es wär auch blöd, diese geistigen Entwicklungen unterbinden zu wollen.

Die Ursachen für Dynamik lassen sich nicht unterbinden oder ignorieren. Wer das trotzdem macht, und beispielsweise Festpreise, Ausschreibungssitiationen als Vorwand dafür verwendet, handelt unverantwortlich, ja sogar fahrlässig, denn dynamikrobuste Entwicklungsverfahren sind ja bekannt.

Das für mich wichtigste Merkmal agilen Vorgehens ist daher die Fähigkeit der Entwicklungsorganisation sich anzupassen und zu lernen. Hierfür werden regelmäßige Rückkopplungen auf verschiedenen Ebenen benötigt. Zum einen auf der Ebene der konkreten Arbeitsergebnisse (Was haben wir hergestellt?). Zum anderen die Selbstbeobachtung der eigenen Arbeit und Kommunikation innerhalb und mit externen des Projektes (Wie stellen wir her?). Diese Rückkopplungen lassen den Anpassungsbedarf sichtbar werden.

Wenn die Entwicklungsorganisation dann noch die Fähigkeit besitzt, darauf sinnvoll zu reagieren, also passende Entscheidungen zu treffen, ist zumindest prinzipiell bereits eine lernende und anpassungsfähige Organisation und ein dynamikrobuster Entwicklungsprozess vorhanden. Die Entscheidungsfähigkeit kann durch organisatorische Rahmenbedingungen geschaffen werden, hierzu zählen Rollen, Verantwortlichkeiten (auch Hierarchie) ebenso wie kollektive Entscheidungsmechanismen bspw. durch spezielle Arbeitstreffen.

Scrum hat genau diese Elemente: Mechanismen zur Beobachtung des Anpassungsbedarfes auf Arbeits- und auf der Metaebene und ebenso Rollen und Arbeitstreffen, um auf diesen Ebenen Entscheidungen zu treffen. Deswegen funktioniert Scrum so gut.

Ich lese immer wieder, auch von „agilen“ Autoren, das agile Verfahren nur für bestimmte Projektarten, Problemklassen oder Rahmenbedingungen die beste Wahl sind und bspw. für große Vorhaben, streng regulierte Kontexte, Festpreise, Ausschreibungen, Behörden- oder Konzernkulturen u.ä. nicht in Frage kommen – das sehe ich grundsätzlich anders. Von trivialen Problemen abgesehen haben wir es immer mit interner und externer Dynamik und mit einem stetigen Fluss von Überraschungen zu tun.

Agile Verfahren beschreiben die Rahmenbedingungen für eine lernende und anpassungsfähige Organisation. Deswegen sind sie nicht nur generell geeignet, sondern auch grundsätzlich einem Wasserfallverfahren vorzuziehen. Es gibt praktisch keinen belastbaren Grund, nicht agil vorzugehen, solange wir nicht noch bessere Verfahren gefunden haben. Und in diesem Sinne sind XP, Scrum, APM und Kanban allesamt geeignet. Und weil sie verschiedene Aspekte adressieren bzw. verschiedene Hebel ansetzen, sind sie in gewisser Weise sogar gut kombinierbar.