„Agiles Projektmanagement“
Stellen wir uns vor, eine Oper würde agil produziert. Nach vier Wochen gibt es den ersten Sprint-Review, und das Publikum bekommt eine halb fertige Version der ersten Szene zu sehen. Die Ouvertüre fehlt, das Bühnenbild ist noch ein grober Prototyp, und der Tenor singt schon mal die Arie, obwohl die Sopranistin noch gar nicht weiß, dass sie sterben soll.
Macht nichts, das wird im nächsten Sprint geliefert!
Klingt absurd? Ist es auch. Denn Opern funktionieren nicht in Iterationen. Niemand möchte sich nach jedem Sprint eine unfertige Fassung anhören und am Ende hoffen, dass die Generalprobe alle Bugs beseitigt. Hier zählt nur das Gesamtkunstwerk.
Während eine Oper als Gesamtkomposition gedacht ist, gibt es viele Projekte, in denen agile Methoden perfekt passen – vor allem in Bereichen, wo kontinuierliches Feedback und Anpassungen gefragt sind.
Produktion einer neuen Opern-App
Schauen wir uns ein sinnvolles Beispiel an:
🎼 Sprint 1: Die Grundfunktionen werden entwickelt – etwa eine einfache Übersicht über Spielpläne.
🎼 Sprint 2: Erste Feedbackrunde mit Nutzer:innen, danach Verbesserung der Navigation.
🎼 Sprint 3: Einführung eines Ticketbuchungssystems, erneutes Feedback.
🎼 Sprint 4: Erweiterung um eine Streaming-Funktion für verpasste Aufführungen.
Jeder dieser Schritte bringt eine nutzbare Verbesserung – selbst wenn das Gesamtprodukt noch nicht fertig ist. Ein Opernhaus könnte seine digitale Präsenz nach und nach ausbauen, statt jahrelang an einer Mammutlösung zu arbeiten, die am Ende vielleicht an den Bedürfnissen der Nutzerer vorbeigeht.
Wenn Wagner agil komponiert hätte
Doch stellen wir uns vor, Richard Wagner hätte „Der Ring des Nibelungen“ agil entwickelt:
🎼 Nach dem ersten Sprint gibt es nur das „Rheingold“, der Rest folgt „inkrementell“.
🎼 „Die Walküre“ wird komplett überarbeitet, weil sich das User-Feedback geändert hat.
🎼 „Siegfried“ kommt mit neuen Features, aber einer völlig anderen musikalischen Linie.
🎼 Und „Götterdämmerung“ wird gestrichen, weil sich die Stakeholder gegen eine vierte Iteration entschieden haben.
Herzlichen Glückwunsch, jetzt haben wir eine fragmentierte Opernlandschaft und das Publikum ist komplett verwirrt.
Mozarts „Die Zauberflöte“ als Minimum Viable Product (MVP)
Nehmen wir doch mal die berühmteste aller Opern und verfolgen ein mögliches Vorgehen:
🎼 Sprint 1: Die ersten drei Arien sind fertig, aber Tamino bekommt noch keine Zauberflöte – er muss improvisieren.
🎼 Sprint 2: Papageno erhält seine Glocken, aber der Rest der Geschichte ist noch unklar.
🎼 Sprint 3: Die Königin der Nacht hat plötzlich eine zweite große Arie, weil das User-Feedback mehr Dramatik wollte.
🎼 Sprint 4: Sarastro wird gestrichen, weil das Stakeholder-Meeting entschieden hat, dass es ohne ihn „schneller zum Punkt“ kommt.
Kurz gesagt: Eine agile Zauberflöte wäre ein surrealer Flickenteppich aus spontanen Ideen.
Fazit: Die Methode muss zur Bühne passen
Agil ist eine großartige Strategie – aber nicht für jedes Szenario. Wenn ein Werk als Ganzes funktionieren muss, dann bringt es nichts, nach jedem Sprint ein halb fertiges Ergebnis abzuliefern. Manche Projekte brauchen eine durchdachte Dramaturgie von Anfang bis Ende – sonst steht am Schluss ein Flickwerk auf der Bühne, das niemand versteht.
Für Software, Produktentwicklung oder Bereiche mit laufendem Feedback? Perfekt.
Für eine durchkomponierte Oper, die als einheitliches Erlebnis wirken muss? Eher nicht.
Also: Wer agil arbeiten will, sollte sich fragen, ob sein Projekt eine Oper oder eine Serie von Sprints ist. Und wenn es doch ein Gesamtkunstwerk werden soll – dann lieber klassisch planen.