Die verschobene Komplexität: Von Wasserfall über Agile zu KI

This blog post is also available in English

TL;DR

Komplexität in der Softwareentwicklung hat sich über die Zeit immer weiter verschoben: von Projektmanagement und Anforderungsanalyse hin zur einzelnen Entwickler:in.
Viele Wasserfallprojekte scheiterten nicht an der Rollentrennung, sondern an der Illusion, Softwareentwicklung sei deterministisch planbar statt ihrer Natur nach komplex.
Agile Methoden haben einen Teil dieser Komplexität zurück ins Team geholt, durch Iteration und gemeinsames Refinement von PO und Team.
KI-gestützte, agentische Entwicklung verschiebt die Rolle der Entwickler:innen noch einmal grundlegend: Durch Spec-driven Development und Orchestrierung rücken sie näher an Requirements Engineering und damit an das chaotische Stakeholder-Umfeld heran.
KI-Tools lassen Aufgaben einfacher aussehen, als sie sind. Die scheinbare Vereinfachung erzeugt tatsächlich mehr gedankliche Auseinandersetzung mit Fachlichkeit und trägt so zum gestiegenen Mental Load bei.
Junior-Entwickler:innen sind besonders betroffen: sinkender Bedarf an ihrer Kapazität trifft auf fehlende Kompetenzen für die gewachsene Komplexität. Die Lernpipeline zur nächsten Senior-Generation bricht weg.

Der gestiegene Mental Load

«Ich bin nach der Arbeit total geschafft!» Diesen Satz höre ich in letzter Zeit immer wieder, wenn ich mit Softwareentwickler:innen über ihren Arbeitsalltag spreche. Die Rede ist von einem spürbar gestiegenen Mental Load: mehr Kontext, mehr Verantwortung, mehr Entscheidungen, die vorher woanders getroffen wurden. Die Ursache scheint der KI-gestützte Entwicklungsprozess zu sein. Trotz schnellerer Umsetzung, Reduktion der Tipparbeit und Erhöhung des Outputs scheint der Einsatz von KI eine ganz neue Komplexität in den Entwicklungsalltag zu bringen.

Ich glaube, dass dieses Phänomen tatsächlich die Zuspitzung einer Entwicklung ist, die schon lange vor dem Einsatz von KI in der Softwareentwicklung begonnen hat: Komplexität in der Softwareentwicklung wurde mit der Entwicklung neuer Methoden und Werkzeuge nie wirklich reduziert, sondern nur immer weiter verschoben. Von Projektmanagement und Anforderungsanalyse in Richtung Team, von dort weiter in Richtung einzelner Entwickler:innen. KI ist dabei nicht die Ursache dieser Verschiebung, sondern nur ihr bislang radikalster Beschleuniger.

Um das zu verstehen, lohnt sich ein Blick durch die Brille des Cynefin-Frameworks, das hilft, Aufgabenfelder nach ihrem Komplexitätsgrad zu unterscheiden. Das Cynefin-Framework liefert uns das Vokabular, um zu beschreiben, was in den letzten zwei Jahrzehnten tatsächlich passiert ist. Denn erst wenn klar ist, welche Art von Komplexität sich wohin verschoben hat, wird auch klar, warum gerade Entwickler:innen von dieser Verschiebung besonders betroffen sind und warum das insbesondere für den Nachwuchs zum Problem wird.

Cynefin kurz erklärt

Das von David Snowden und Mary Boon aufgestellte Cynefin-Framework unterscheidet Aufgaben und Systeme danach, wie gut sich Ursache und Wirkung erkennen lassen und leitet daraus ab, welche Art von Vorgehen am ehesten in diesem Kontext geeignet sind. Das Cynefin-Framework unterscheidet dabei zwischen vier unterschiedlichen Domänen:

Simple / Clear: Ursache und Wirkung sind offensichtlich, es gibt bewährte Standardlösungen. Ein Bug mit bekannter Ursache und bekanntem Fix, ein Standard-CRUD-Feature nach etabliertem Muster. In einer solchen Domäne gilt es, die richtige Best Practice anzuwenden. Gerade für Junior-Enwickler:innen ist dies die Domäne, in der sie erste Erfahrungen machen können, um das Rüstzeug für größere Herausforderungen aufzubauen.
Complicated: Ursache und Wirkung sind erkennbar, aber es braucht Expertise, um sie zu analysieren. Eine Performance-Optimierung, bei der man erst durch Profiling und Analyse versteht, wo der Engpass liegt, oder die Integration eines komplexen Drittsystems nach Dokumentation. Hier helfen Good Practices, Methodik und Erfahrung, um eine Lösung für das jeweilige Problem zu finden. Snowden sieht hier genau das Feld, in dem Experten glänzen können. In der Softwareentwicklung könnte das die Spezialist:in sein, die ein tiefes Wissen hat, aber eher klare Strukturen zum Arbeiten braucht und vielleicht lieber alleine arbeitet, die sich in diesem Umfeld wohlfühlt und brillante Lösungen entwickeln kann.
Complex: Ursache und Wirkung sind erst im Nachhinein erkennbar, nicht im Voraus. Eine Architektur-Entscheidung für ein neues, unbekanntes Anforderungsfeld, ein Produkt-Experiment mit ungewissem Nutzerverhalten. Hier hilft keine Blaupause, sondern nur ausprobieren, beobachten, anpassen (emergent practice). Das ist der Bereich, in dem die meiste konzeptionelle Unsicherheit steckt. In dieser Domäne arbeiten wir am erfolgreichsten mit agilen, crossfunktionalen Teams, indem wir unser Wissen zusammenwerfen und uns über Hypothesen und Experimente vorantasten.
Chaotic: Es gibt (zunächst) gar keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung, Handeln ist dringend nötig, Struktur muss oft erst geschaffen werden, bevor überhaupt analysiert werden kann. Das typische Beispiel dafür liegt in der Softwareentwicklung meist nicht im System selbst, sondern im Umfeld: widersprüchliche Stakeholder-Interessen, politische Grabenkämpfe zwischen Abteilungen, sich unvorhersehbar ändernde Anforderungen, unterschiedlich kooperationsbereite Beteiligte, deren eigentliche Motive gar nicht offen auf dem Tisch liegen. Hier hilft keine Methodik und kein Analyseprozess. Zunächst muss überhaupt erst Ordnung, Kommunikation und Vertrauen hergestellt werden (novel practice), bevor sich irgendetwas wie ein lösbares Problem formulieren lässt. Das ist genau das Umfeld, das sich destruktiv auf ein Entwicklungsteam auswirkt, und es ist die Aufgabe des Product Owners, das Team genau vor diesem Chaos abzuschirmen und ihm so den Freiraum zur Bearbeitung der komplexen fachlichen und technischen Probleme zu schaffen.

Wichtig ist dabei ein Effekt, den Cynefin als Complacency-Klippe beschreibt: Der Übergang von Simple zu Chaotic ist fließend und tückisch. Eine Aufgabe, die einfach aussieht, kann in Wirklichkeit deutlich mehr Unsicherheit enthalten, als auf den ersten Blick erkennbar ist und wenn diese Unsicherheit unbemerkt bleibt, kippt die Situation unvermittelt ins Chaos. Dieser Effekt wird uns später, wenn es um KI-gestützte Entwicklung geht, noch einmal begegnen.

Diese vier Domänen dienen im Folgenden nicht als Diagnosewerkzeug für den Alltag, sondern als Vokabular: Sie helfen zu benennen, welche Art von Komplexität sich im Lauf der letzten zwei Jahrzehnte wohin verschoben hat.

Wie Komplexität vom Umfeld ins Team wanderte

Die Illusion der Planbarkeit im Wasserfallmodell

In der klassischen Softwareentwicklung gab es eine klare Rollentrennung: Projektmanagement, Anforderungsanalyse und Softwareentwicklung waren getrennte Funktionen, oft sogar getrennte Personen oder Abteilungen. Diese Trennung war kein Zufall, sondern hatte im Grunde eine Cynefin-Funktion: Das chaotische Umfeld aus Stakeholder-Interessen, politischen Zwängen und sich wandelnden Erwartungen sollte im Projektmanagement absorbiert werden, während die Anforderungsanalyse daraus ein lösbares, kompliziertes Problem destillieren sollte.

Das Wasserfallmodell unterlag aber einem entscheidenden Konstruktionsfehler: Es unterstellte, dass sich ein Softwareprojekt als Ganzes deterministisch planen lässt. Im Cynefin-Vokabular heißt das, dass ein größeres Softwareprojekt bestenfalls kompliziert, nie aber komplex sein wird. Genau daran sind viele Wasserfallprojekte gescheitert. Größere Softwarevorhaben sind ihrer Natur nach komplex, teils sogar chaotisch: Anforderungen ändern sich, Annahmen erweisen sich als falsch, Nutzerverhalten lässt sich nicht vollständig vorhersehen. Ein Vorgehen, das auf einer einzigen, seriellen Sequenz aus Analyse, Design und Umsetzung beruht, kann mit diesem Systemverhalten nicht umgehen, unabhängig davon, wie sauber die Rollen dabei getrennt sind. Was fehlte, war also der iterative Ansatz, den Cynefin für komplexe Domänen vorsieht: ausprobieren, beobachten, anpassen, statt einmalig vorausplanen.

Agile Methoden adressieren genau diesen Konstruktionsfehler. Durch eine enge zeitliche Verzahnung von Konzeption und Umsetzung, statt einer seriellen Abfolge von Phasen. Damit einher geht ein zweiter, davon unabhängiger Paradigmentwechsel: Die Rollen selbst vermischen sich stärker.

Ein zentraler Mechanismus dafür ist der Refinement-Prozess: Anforderungen werden nicht mehr allein von einem Analysten vorgedacht und dem Team fertig übergeben, sondern gemeinsam von Product Owner und Team erarbeitet, hinterfragt und geschärft. Der PO übernimmt dabei weiterhin eine wichtige Pufferfunktion: effektive Stakeholder-Kommunikation soll das Team vor dem chaotischen Umfeld schützen. Aber durch das gemeinsame Refinement ist diese Pufferfunktion durchlässiger geworden als frühere Rollentrennungen, so dass ein gutes Stück der konzeptionellen, teils komplexen Arbeit, die früher außerhalb der Entwicklung geleistet wurde, jetzt dauerhaft im Team verbleibt.

Komplexität braucht die richtigen Menschen am richtigen Platz

Diese gewachsene, team-interne Komplexität lässt sich nicht durch den Prozess allein bewältigen, sie erfordert auch die passende Verteilung auf die Menschen im Team. Nicht alle Entwickler:innen sind gleichermaßen in der Lage oder bereit, sich hoher Komplexität zu stellen – teils aus Gründen der Erfahrung, teils aus Gründen der Persönlichkeit. Erfahrenere Entwickler:innen übernehmen tendenziell die komplexeren, unsichereren Anteile, während einfachere bis kompliziertere Aufgaben einen Rahmen bieten, in dem sich weniger Erfahrene schrittweise an höhere Komplexität herantasten können.

Ein starkes Team zeichnet sich dadurch aus, dass unterschiedliche Charaktere konstruktiv zusammenarbeiten und Aufgaben so geschnitten werden, dass jedes Mitglied sich mit seinen Fähigkeiten und Neigungen bestmöglich einbringen kann. Diese bewusste Zusammensetzung und Aufgabenverteilung ist im Kern eine Verteilung von Komplexität auf die Personen, die am besten damit umgehen können und wollen. Dieser Anspruch gilt ganz unabhängig vom gewählten Vorgehensmodell, hat aber durch die agile Wende an Bedeutung gewonnen, weil insgesamt mehr Komplexität im Team selbst zu verteilen ist.

Das Chaos erreicht das Team

In den letzten Jahren hat sich die Softwareentwicklung durch KI-gestützte und zunehmend agentische Werkzeuge spürbar verändert. Wo Entwickler:innen früher Zeile für Zeile selbst Code schrieben, generieren KI-Agenten heute ganze Funktionen, Module oder sogar Architektur-Grundgerüste auf Basis von Spezifikationen und Prompts. Die eigentliche Tätigkeit verschiebt sich damit vom Schreiben zum Formulieren, Steuern, Bewerten und Korrigieren. Entwickler:innen orchestrieren den Entwicklungsprozess zunehmend, statt ihn selbst auszuführen. Das bringt einen erheblichen Produktivitätsgewinn, aber es verändert auch, welche Fähigkeiten gefragt sind und wo im Prozess die eigentliche Arbeit stattfindet.

Das Muster aus dem vorigen Abschnitt setzt sich dabei fort: Komplexität wandert weiter in Richtung Entwicklung. Was sich ändert, ist aber nicht nur das Tempo dieser Verschiebung, sondern auch ein neuer Faktor, der historisch so nicht existierte: der Anreiz, Teams zu verkleinern, weil KI-Einsatz scheinbar weniger Personal für denselben Output benötigt. Diese Effekte (schnellere Verschiebung, schrumpfende Teams und ein wachsender Umfang dessen, was der Einzelne überblicken muss) verschärfen, was ohnehin schon in Bewegung war.

Vom Umsetzer zum Anforderungsverantwortlichen

Mit Ansätzen wie Spec-driven Development verschiebt sich die Rolle der Entwickler:innen noch einmal grundlegend. Es reicht nicht mehr aus, im Refinement gemeinsam mit dem PO Anforderungen zu hinterfragen und zu schärfen. Entwickler:innen formulieren jetzt selbst die Spezifikation, aus der die KI den Code generiert, und tragen damit einen erheblichen Teil dessen, was vorher Requirements Engineering oder PO-Arbeit war. Das ist ein qualitativer Sprung: Die Rolle rückt strukturell näher an die von PM und PO heran und damit näher an genau das chaotische Umfeld, vor dem die frühere Rollentrennung eigentlich schützen sollte.

Ein Mismatch mit der eigenen Berufswahl

Diese Verschiebung trifft auf eine unbequeme Realität: Viele Menschen haben sich gerade wegen klarer Strukturen und geringer Ambiguität für die Softwareentwicklung entschieden. Neben der Freude an der Technik war das ein legitimer, oft sogar zentraler Faktor der Berufswahl. Nun verlangt die neue Rolle aber genau die Fähigkeiten, die im chaotischen, politisch geprägten Anforderungsbereich zählen: Ambiguitätstoleranz, Verhandlungsgeschick, Kommunikation mit unterschiedlich kooperationsbereiten Stakeholdern. Was bisher noch eine Verteilungsfrage im Team war (nicht jede:r muss alles können, das Team gleicht Unterschiede aus) wird jetzt zunehmend zu einer Anforderung an jede:n Einzelne:n.

Wenn Komplexität sich als Einfachheit tarnt

Hier wird die eingangs erwähnte Complacency-Klippe konkret: KI-Tools lassen Aufgaben simpel aussehen (Prompt rein, Code raus), während die zugrundeliegende Aufgabe in Wahrheit komplex oder sogar chaotisch ist, gerade weil sie jetzt Anforderungs- und Stakeholder-Anteile mitträgt. Die Reduktion auf Orchestrierung suggeriert eine Vereinfachung der Arbeit, erfordert aber tatsächlich eine tiefere Auseinandersetzung mit der Fachlichkeit, den Anforderungen und ihren Hintergründen, als das reine Schreiben von Code je verlangt hat. Genau diese Diskrepanz zwischen scheinbarer Vereinfachung und tatsächlich gestiegener gedanklicher Last dürfte ein wesentlicher Grund dafür sein, dass viele Entwickler:innen von einem deutlich gestiegenen Mental Load berichten. Nicht weil die Werkzeuge weniger leisten, als sie versprechen, sondern weil das, was sie an Tipparbeit abnehmen, an anderer Stelle als Denk- und Verantwortungsarbeit wieder auftaucht.

Kleinere Teams, fehlende Lernpipeline

Die eingangs erwähnte Team-Verkleinerung verschärft all das zusätzlich: Die bisherige organisatorische Antwort auf die Komplexität, nämlich genau diese Komplexität im Team über verschiedene Charaktere und Fähigkeiten zu verteilen, wird schwerer, je kleiner das Team ist.

Am stärksten trifft das Junior-Entwickler:innen, und zwar durch zwei sich addierende Effekte: Zum einen sinkt der Bedarf an ihrer Kapazität, da KI-Unterstützung genau die einfachen bis komplizierten Aufgaben übernimmt, an denen Junior-Entwickler:innen traditionell lernen. Zum anderen fehlen ihnen für den jetzt größeren komplexen und chaotischen Anteil oft noch die nötigen Kompetenzen. Das ist nicht nur ein kurzfristiges Problem: Wenn Junior-Entwickler:innen keinen Raum mehr haben, sich im komplizierten Terrain zu üben, bevor sie mit komplexen und chaotischen Situationen konfrontiert werden, bricht die Lernpipeline weg, aus der die nächste Generation von Senior-Entwickler:innen hervorgehen müsste.

Mehr Umfang, mehr Verantwortung

Neben der gestiegenen Komplexität wächst durch dieselbe Entwicklung auch schlicht der Umfang dessen, was Entwickler:innen überblicken müssen. Wer den Entwicklungsprozess orchestriert statt nur zu programmieren, muss mehr Fachlichkeit verstehen, mehr Code überblicken, als er oder sie je selbst geschrieben hätte, und mehr Entscheidungen treffen, die früher über mehrere Rollen verteilt waren. Das ist eine eigenständige Belastung, unabhängig von der Frage, wie komplex oder chaotisch die einzelne Aufgabe im Cynefin-Sinn ist. Einfach mehr Kontext, mehr gleichzeitig im Kopf zu behaltende Fäden, mehr Verantwortung pro Person.

In Kombination mit der durch die verschobene Aufgabenverteilung, oft unsichtbar bleibenden Komplexität ergibt sich daraus eine doppelte Last: Die Arbeit ist nicht nur schwieriger geworden, sondern auch umfangreicher, wobei sich diese beiden Effekte noch gegenseitig verstärken.

Und nun?

Wenn wir uns aus der Cynefin-Brille ansehen, wie sich Softwareentwicklung über die Zeit verändert hat, können wir zwei grundlegende Verschiebungen erkennen:

Die klare Rollentrennung der klassischen Softwareentwicklung war der Versuch, die chaotischen und komplexen Anteile eines Softwareentwicklungsprojektes vor dem Team wegzukapseln. Projekt und Anforderungsmanagement sollten das umgebende Chaos in klare strukturierte Anforderungen übersetzen, damit für die Entwicklung ein kompliziertes, lösbares Problem übrigblieb. Agile Methoden haben diese Kapselung aufgeweicht: Durch Iteration und gemeinsames Refinement wanderte ein gutes Stück konzeptioneller, komplexer Arbeit zurück ins Team, während der PO als Puffer zum chaotischen Umfeld erhalten blieb.
KI-gestützte Entwicklung verschärft diese Verlagerung nicht nur graduell, sondern verschiebt die Domänengrenze selbst, verschleiert aber gleichzeitig den dadurch verursachten Komplexitätsanstieg. Aufgaben, die durch Spec-driven Development und Orchestrierung einfach aussehen, beinhalten in Wahrheit einen erheblichen Anteil dessen, was früher Requirements Engineering und Stakeholder-Management war und damit jene komplexen und chaotischen Anteile, vor denen die ursprüngliche Rollentrennung eigentlich schützen sollte. Am härtesten trifft das Junior-Entwickler:innen: Nicht nur sinkt der Bedarf an ihrer Kapazität, es bricht auch die Lernpipeline weg, in der sie sich bislang schrittweise an höhere Komplexität herantasten konnten.

Der gestiegene Mental Load, von dem Entwickler:innen berichten, ist vor diesem Hintergrund keine Überraschung, sondern ein zu erwartendes Symptom: Umfang und Komplexität der Arbeit wachsen gleichzeitig, während die organisatorischen Puffer, die früher beides abgefedert haben, kleiner werden.

Wir stehen also vor ganz neuen Fragen hinsichtlich unserer Softwareentwicklungsorganisation:

Wie gestalten wir Teams und Rollen so, dass die neu entstehende Komplexität wieder verteilbar wird, statt sie allein bei einzelnen Entwickler:innen abzuladen?
Was bedeutet das für die Ausbildung von Junior-Entwickler:innen, wenn der bisherige Übungsraum wegfällt?
Wie können wir sicherstellen, dass Junior-Entwickler:innen sich Schritt für Schritt an komplexere Aufgaben herantasten können?
Wie stellen wir sicher, dass diejenigen, die sich bewusst für klare Strukturen entschieden haben, in dieser Verschiebung nicht einfach untergehen?

Quelle

David J. Snowden, Mary E. Boone: A Leader’s Framework for Decision Making