Einleitung: Die Illusion der perfekten Methode
In der modernen IT-Welt gleicht die Diskussion um die richtige Projektmethode oft einem religiösen Disput. Auf der einen Seite stehen die Verfechter des agilen Ansatzes (Scrum, SAFe), die Flexibilität und Iteration als das einzig Wahre predigen. Auf der anderen Seite finden sich die Traditionalisten, die auf die Planbarkeit und Struktur des Wasserfall-Modells schwören.
In den letzten Jahren war der agile Ansatz zweifellos der Favorit. Doch wer tief in der Praxis der Softwareentwicklung steckt, spürt, dass der Glanz bröckelt. Es zeigen sich Defizite in der praktischen Anwendung. Projekte laufen aus dem Ruder, Budgets explodieren und Teams brennen trotz (oder manchmal wegen) strenger Befolgung agiler Zeremonien aus.
Dieser Artikel ist eine Reflexion aus der Praxis. Er richtet sich an Projektleiter, Programm-Manager und Entscheider, die sich fragen: „Welche Methode passt wirklich zu meinem Projekt?“
Wir werden analysieren, warum Projekte einzigartig sind, warum die „User Story“ nicht immer der heilige Gral ist und warum der gesunde Menschenverstand oft wichtiger ist als das Lehrbuch.
1. Warum Projekte einzigartig sind (und Dogmen scheitern)
Das Problem mit dem „Schema F“
Ein Grundsatz wird in der Methodendiskussion oft vergessen: Jedes Projekt ist einzigartig.
Die Umstände, unter denen ein Projekt durchgeführt wird, sind nie identisch.
Das Team, die Unternehmenskultur, die technologische Basis, der Druck vom Markt und das Budget variieren ständig.
Daraus folgt eine wichtige Erkenntnis: Ein dogmatischer Einsatz von Methoden wie Scrum, SAFe oder Hermes ist nicht zielführend.
Wer versucht, die Realität mit Gewalt in eine Schablone zu pressen, wird scheitern.
Methode folgt Umstand, nicht umgekehrt
Im Zentrum der Betrachtung sollte niemals die Methode stehen, sondern die Umstände.
- Was soll abgebildet werden?
- Wie komplex ist die Materie?
- Wie erfahren ist das Team?
Als ich selbst zu programmieren begann, steckte die Agilität noch in den Kinderschuhen. Die Welt war geprägt von Wasserfall-Projekten und monolithischen Systemen.
Ich begann spät in meiner Karriere, mich theoretisch mit Methoden zu befassen.
Zuerst verliess ich mich auf den gesunden Menschenverstand.
Und genau dieser Pragmatismus fehlt heute oft.
Wir brauchen wieder mehr Fokus auf das „Was“ und „Warum“ und weniger Obsession mit dem „Wie“ (der Methode).
2. Das „Stille Kämmerlein“: Kommunikation vs. Spezifikation
Das Ur-Problem der Softwareentwicklung
Bevor wir über Agilität vs. Wasserfall streiten, müssen wir das Grundproblem adressieren, an dem viele IT-Projekte kranken.
Es liegt oft in der Natur der Entwickler selbst.
Speziell introvertierte technische Experten neigen dazu, Applikationen als Auftrag entgegenzunehmen, sich ins „stille Kämmerlein“ zurückzuziehen und Wochen später ein Ergebnis zu präsentieren.
Das Resultat?
Die Auftraggeber werden vor vollendete Tatsachen gestellt.
Oft entspricht das Gelieferte technisch der Anforderung, aber nicht dem, was der Kunde eigentlich brauchte oder erwartete.
Solche Projekte werden zu Rohrkrepierern. Sie müssen refakturiert, neu gebaut oder komplett eingestampft werden.
Die agile Lösung: Einbindung der Stakeholder
Hier liegt die eigentliche Stärke des agilen Gedankens, die wir bewahren müssen, unabhängig von der Methode: Feedback-Schleifen.
Während meiner Karriere legte ich stets Wert darauf, Stakeholder (die Parteien mit einem Interesse am Projekt) kontinuierlich abzuholen.
- Offenlegung des Fortschritts: Zeigen, was da ist, auch wenn es unfertig ist.
- Prototyping: Software schrittweise verfeinern.
- Kurskorrekturen: Feedback führt zu einer Erweiterung oder Anpassung des Codes, nicht zu einem kompletten Abriss.
Dieses Vorgehen ist agil im besten Sinne: Es geht dynamisch mit Anforderungen um, statt von einer statischen, unumstösslichen Spezifikation auszugehen.
Das ist primär kein technisches Problem, sondern eine Frage des Mindsets.
3. Der Konflikt: User Stories vs. Software-Architektur
Hier kommen wir zu einem Punkt, der in der Theorie oft übersehen, in der Praxis aber schmerzhaft spürbar wird: Der Widerspruch zwischen agilem Management und technischer Architektur.
Die User Story als Anker
Agiles Projektmanagement nutzt die „User Story“ als Definitionseinheit.
Die Idee: Ein Teil des Systems wird definiert, entwickelt, getestet, ausgeliefert und ist damit „fertig“.
Die Realität der modularen Architektur
In der modernen Softwareentwicklung ist dieser Ansatz oft naiv.
Applikationen sind keine Ansammlung isolierter Funktionen. Unterschiedliche User Stories nutzen eine gemeinsame technische Basis (Datenbankmodelle, Schnittstellen, Libraries).
Dies entspricht dem modernen, modularen Ansatz der Softwarearchitektur.
Wenn ich eine User Story umsetze, berühre ich oft das Fundament, auf dem fünf andere Stories stehen.
Der Vergleich: Industrielle Produktion vs. Coding
Agile Methoden wie Lean und Kanban haben ihre Wurzeln in der industriellen Produktion (z.B. Toyota). Doch Software ist kein Auto.
- Das Auto: In einer Produktionsstrasse ist die Fertigung der Autotür losgelöst vom Rückspiegel. Ist die Tür einmal perfekt designt, ist sie statisch. Es gibt keinen Grund, sie im laufenden Prozess zu verändern.
- Die Software: Die Abbildung von Use Cases entwickelt sich weiter. Neue Erkenntnisse in Bereich A erfordern Anpassungen in Bereich B. Ein Datenbankmodell muss harmonisiert, Schnittstellen refakturiert werden.
Software ist dynamisch, nicht statisch.
Ein rein sequenzielles Abarbeiten von User Stories ignoriert die notwendige Pflege des „Ganzen“ (der Architektur).
4. Der unvermeidbare Wasserfall: Initialisierung und Go-Live
Selbst in den agilsten Projekten gibt es Phasen, die sich linear verhalten müssen. Wer das ignoriert, riskiert Chaos.
Initial-Entwicklung
Bevor das erste Inkrement geliefert werden kann, braucht es ein Fundament. Aufgrund gemeinsam verwendeter Module kommen wir nicht darum herum, einen Teil des Wasserfalls für die Startphase zu übernehmen. Es muss eine Architektur stehen, bevor man die Wände streichen kann.
Der Go-Live als Zäsur
Ein kritischer Moment ist der Übergang von der Entwicklung (DEV) in den Betrieb (Lifecycle). Bis zum Moment, wo eine Applikation im „Beta“-Status oder einer „Friendly User“-Phase ist, geniesst sie den „Dev-Bonus“. Fehler werden verziehen, Updates sind schnell eingespielt.
Mit der Produktivschaltung ändert sich alles. Die Entwicklung verändert sich grundlegend und der Lifecycle beginnt.
Hier gelten plötzlich strenge Regeln, SLAs (Service Level Agreements) und Stabilität steht vor neuen Features. Dieser harte Übergang ist ein klassisches Wasserfall-Element (Meilenstein), das sich nicht wegdiskutieren lässt.
5. Der Elefant im Raum: Kosten, Budget und Schätzungen
Das vielleicht grösste Spannungsfeld zwischen Agilität und Unternehmensrealität sind die Finanzen.
Das Budget-Dilemma
Software-Projekte überziehen fast immer ihr Budget.
- Wasserfall: Verspricht festen Scope und feste Kosten. Das Problem: Bei komplexen Projekten sind Schätzungen selbst mit detaillierter Spezifikation fast unmöglich, da zu viele unbekannte Komponenten involviert sind.
- Agil: Fordert eigentlich ein „Time & Material“-Modell. Man schätzt Deltas, Requirements entwickeln sich, Kosten summieren sich auf.
Die Kostenexplosion und das Kostendach
In der Praxis ist kaum ein Auftraggeber (CFO, Kunde) bereit, einen Blankoscheck auszustellen („Wir zahlen, bis es fertig ist“).
Hier versagt der dogmatische agile Ansatz.
Es wird ein Kostendach gefordert.
Doch wie vereinbart man ein festes Budget mit einem variablen Scope?
Dies führt oft zu einer „Schein-Agilität“, bei der Festpreise für agile Sprints verlangt werden.
Daraus resultiert ein Widerspruch in sich, der Risiken einseitig auf die Entwicklung verlagert.
6. Das Team: Spezialisten sind keine Ressourcen
Ein weiterer Fehler im dogmatischen Agilen (z.B. Scrum) ist die Annahme der Austauschbarkeit.
Das Lehrbuch geht oft von „T-Shaped Skills“ aus: Jeder Entwickler kann idealerweise jede Aufgabe im Backlog übernehmen. Das führt zu der Idee, Ressourcen seien dynamisch verschiebbar.
Die Realität: Als Projektleiter führst du ein Team von Spezialisten.
- Der Datenbank-Experte ist kein Frontend-Designer.
- Der Junior-Entwickler hat nicht den Weitblick des Solution Architects.
- Senioritäten und Persönlichkeiten unterscheiden sich massiv.
Es ist matchentscheidend, die Verfügbarkeit dieser Spezialisten sinnvoll zu planen.
Man kann nicht einfach „3 Entwickler“ in einen Sprint werfen und erwarten, dass jedes Ticket gelöst wird. Das erfordert eine Planung, die über das nächste Daily Stand-up hinausgeht.
7. Tools und Reporting: Raus aus dem Elfenbeinturm
Keep it Simple: Jira & Co.
Verbringe nicht zu viel Zeit damit, die Methode zu perfektionieren. Lege den Fokus auf die Tools. Ich rate dringend zum Einsatz von Standard-Tools.
- Jira: Hat sich für das Aufgabenmanagement (Task Tracking) durchgesetzt.
- Vermeide exotische Tools. Wenn neue Mitarbeiter ins Projekt kommen, ist es Gold wert, wenn sie die Werkzeuge bereits kennen. Der Einarbeitungsaufwand sinkt massiv.
Die Reporting-Falle
Oft müssen PowerPoint und Excel für das Management-Reporting herhalten.
Frameworks wie Hermes bieten hier gute Strukturen, erzeugen aber bei dogmatischer Anwendung unnötigen Overhead.
Die grösste Gefahr ist jedoch die Führung über Reporting.
Manager, die sich nur auf grüne Ampeln in Excel-Tabellen verlassen, erleben oft ein böses Erwachen. Nur ein tiefes Verständnis der Materie und der wirklichen Stolpersteine schützt vor dem Scheitern.
Manager müssen aus dem Elfenbeinturm herabsteigen.
Sie müssen sich mit der technischen Seite und den Experten auseinandersetzen.
8. Die „Panic Zone“ vor dem Abschluss
Warum ist diese abstrakte Betrachtung so wichtig?
Weil ich in fast allen meinen Projekten, ob als Entwickler, Scrum Master oder Projektleiter dasselbe Muster beobachtet habe.
Der offene Kampf
Wenn Projekte auf den Abschluss zusteuern, entbrennt oft ein Kampf zwischen Projektleitung und Stakeholdern.
- Kosten laufen aus dem Ruder.
- Komponenten spielen nicht zusammen.
- Teams blockieren sich gegenseitig.
- Die Vision ist unklar.
In diesen Momenten stützt sich das Management panisch auf undurchsichtige Reportings.
Es wird Druck ausgeübt („Wir müssen liefern!“).
Entscheidungen werden getroffen, die die Situation verschlimmern.
Die Task Force ist keine Lösung
Eine gängige (und schlechte) Praktik ist der Einsatz einer Task Force.
Meine Erfahrung: Task Forces bringen primär Unruhe. Sie generieren Overhead durch endlose Meetings, in denen gerechtfertigt werden muss, warum es nicht läuft.
Das hält die Experten von der eigentlichen Arbeit ab.
Das Resultat sind Nachtschichten, Wochenendarbeit und frustrierte Mitarbeiter.
9. Der Schlüssel zum Erfolg: Vision, Empathie und Kommunikation
Wenn Methoden und Tools an ihre Grenzen kommen, was rettet das Projekt?
1. Kommunikation und Empathie
Viel wichtiger als Jira-Tickets ist die Art, wie wir miteinander reden.
Empathie im Team sorgt dafür, dass man sich gegenseitig unterstützt, wenn es brennt, anstatt Schuldige zu suchen (Blame Game).
2. Die abgestützte Vision
Zentral für das Gelingen ist eine Vision, die auf allen Ebenen verstanden und geteilt wird („Shared Vision“). Diese Vision muss immer wieder gechallenged werden.
- Wissen alle, warum wir das bauen?
- Ziehen alle am gleichen Strang?
Wenn sich das Team als Teil einer Mission empfindet, entsteht die Motivation, auch in kritischen Momenten die Extrameile zu gehen.
Ohne diese intrinsische Motivation scheitert jede Methode.
Fazit: Pragmatismus gewinnt
Zusammenfassend lässt sich sagen: Die Methode, die du wählst, kann das Problem der Softwareentwicklung nur in Teilen lösen.
Versteife dich nicht auf Dogmen.
- Nutze Wasserfall-Elemente für die grobe Planung, Budgetierung und Architektur.
- Nutze agile Elemente für die Umsetzung, Feedback-Schleifen und das Stakeholder-Management.
- Führe mit Verstand und Nähe zum Team, nicht nur mit Excel-Listen.
Suchst du nach jemandem, der dein Projekt oder Programm pragmatisch abwickelt, anstatt nach Lehrbuch zu arbeiten? Jemand, der eine Vision mit allen Beteiligten erarbeitet und die wirklichen Stolpersteine identifiziert, bevor die Kosten explodieren?
Hole Unterstützung für dein Projekt
Ich bin bereit, mir dein Projekt im Detail anzusehen. Ob du noch in der Planungsphase steckst („Agil oder Wasserfall?“) oder mitten in einem Projekt bist, das an Grenzen stösst.
Als erfahrener Projekt- und Programmleiter, sowie als Turnaround-Manager für Projekte in Schieflage, biete ich dir eine realitätsnahe Analyse und Umsetzung.
👉 Vereinbare jetzt einen Termin für eine Besprechung!
Lass uns gemeinsam schauen, wo der Schuh drückt und wie wir dein Projekt zum Erfolg führen können.
FAQ: Häufige Fragen zu Projektmethoden
Ist Wasserfall heute noch zeitgemäss? Ja, besonders in Phasen der Initialisierung, bei strikten regulatorischen Anforderungen oder bei der Definition von Schnittstellen und Architektur ist eine sequenzielle Planung oft unumgänglich.
Warum scheitern agile Projekte oft am Budget? Weil Agilität oft als „wir planen nicht“ missverstanden wird. Ohne ein Grobkonzept und ein Kostendach (Budgetrahmen) fehlt die finanzielle Orientierung, was zu einem „Feature Creep“ führen kann.
Was mache ich, wenn mein Team die Methode ablehnt? Höre zu. Oft ist der Widerstand begründet durch Praxiserfahrung. Passe die Methode an das Team an, nicht das Team an die Methode.
Brauche ich einen externen Projektleiter? Ein externer Blick ist oft wertvoll, da er unvoreingenommen ist und keine internen politischen „Altlasten“ trägt. Speziell in Krisensituationen (Turnaround) ist Neutralität ein mächtiges Werkzeug.