Es gibt kaum eine Diskussion in der Softwareentwicklung, die mit mehr Inbrunst geführt wird als die Frage: agil oder klassisch? Die Lager sind verhärtet, die Argumente werden wie Glaubenssätze vorgetragen. Auf der einen Seite die Agilisten, die in Wasserfall-Modellen den Untergang der westlichen Zivilisation sehen. Auf der anderen Seite die Klassiker, die in jeder Retrospektive eine Kaffeekränzchen-Veranstaltung vermuten.
Dabei wird eine entscheidende Frage überraschend selten gestellt: Was für ein Problem versuchen wir eigentlich zu lösen?
Die Natur des Problems bestimmt die richtige Methodik — nicht die persönliche Vorliebe, nicht der Zeitgeist und schon gar nicht die Folie, die der letzte Berater dagelassen hat. Der Schlüssel liegt in der Unterscheidung zwischen komplex und kompliziert.
Ein komplexes Problem ist eines, bei dem die Anzahl der unbekannten Variablen hoch ist. Man kann das Ergebnis nicht vorhersagen, weil die Wechselwirkungen zwischen den Variablen nicht vollständig verstanden sind. Die Lösung entsteht durch Ausprobieren, durch schnelle Feedback-Zyklen, durch Lernen. Hier ist man näher am Kunden, näher am Unbekannten. Hier braucht man Agilität — nicht als Ideologie, sondern als pragmatische Antwort auf Unsicherheit.
Ein kompliziertes Problem hingegen hat viele Variablen, aber die meisten davon sind bekannt. Die Zusammenhänge sind analysierbar, die Abhängigkeiten kalkulierbar. Die Lösung ergibt sich durch sorgfältige Analyse, durch Planung, durch systematisches Abarbeiten. Hier ist der klassische Ansatz nicht nur berechtigt — er ist überlegen.
Die Airbus-Analogie macht den Unterschied greifbar:
Komplex: Die Flugbegleiterin
Die Arbeit einer Flugbegleiterin ist komplex. Sie kann nicht vorhersagen, wie sich die Passagiere verhalten werden. Wird jemand in Panik geraten? Wird ein Kind krank? Wird ein Passagier aggressiv? Sie muss auf Situationen reagieren, die sie nicht planen kann. Ihre Kompetenz liegt im Umgang mit dem Unvorhersehbaren — in der Fähigkeit, schnell zu adaptieren.
Kompliziert: Der Airbus selbst
Den Airbus zu bauen ist kompliziert — aber nicht komplex. Die Abhängigkeiten zwischen den Bauteilen sind bekannt. Die physikalischen Gesetze sind verstanden. Die Toleranzen sind berechenbar. Hier wäre ein agiler Ansatz nicht nur unnötig, sondern gefährlich. Niemand möchte in einem Flugzeug sitzen, dessen Tragfläche „iterativ” entwickelt wurde.
Übertragen auf die Softwareentwicklung: In einem typischen E-Commerce-System ist das Frontend — die Interaktion mit dem Kunden, die Darstellung von Produkten, das Kauferlebnis — eher komplex. Die Anforderungen ändern sich schnell, die Nutzererwartungen sind schwer vorherzusagen, A/B-Tests und schnelle Iterationen sind der Schlüssel zum Erfolg. Hier ist agiles Vorgehen die richtige Wahl.
Das Backend hingegen — die Integration mit Zahlungsdienstleistern, die Anbindung an ERP-Systeme, die Verarbeitung von Bestellungen — ist eher kompliziert. Die Schnittstellen sind dokumentiert, die Geschäftsregeln sind definiert, die regulatorischen Anforderungen sind bekannt. Hier kann und sollte man planen, analysieren, spezifizieren.
Das bedeutet nicht, dass ein Projekt sich für genau eine Methodik entscheiden muss. Im Gegenteil: Die besten Projekte sind die, die den Mut haben, innerhalb eines Projekts verschiedene Ansätze zu kombinieren — agil dort, wo Unsicherheit herrscht, klassisch dort, wo Klarheit besteht.
Die Frage „agil oder klassisch?” ist also falsch gestellt. Die richtige Frage lautet: Wie komplex ist das Problem, das wir lösen wollen? Und die ehrliche Antwort darauf bestimmt die Methodik — nicht die Ideologie.
Geschäftsführer
Michael Schwarze ist Geschäftsführer von atra consulting und erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung. Er hat in Startups und Konzernen gearbeitet und begeistert sich für moderne Softwarearchitekturen und dynamisch-typisierte Sprachen.
