In fast jedem Unternehmen, in dem ich arbeite, läuft dasselbe Vorgehen – unabhängig davon, was gebaut wird. Kernsystemmigration. Neues digitales Produkt. Regulatorische Anpassung. Alle drei bekommen dasselbe Framework, denselben Sprint-Rhythmus, dieselben Zeremonien. Das Ergebnis: Der Fokus liegt auf dem Projekt – selten auf dem Produkt.
Ich schreibe das aus dem Kontext von Enterprise- und B2B-Umfeldern: Organisationen mit gewachsenen Systemen, eingebetteten Prozessen und Produkten, die in ein bestehendes Ökosystem integriert werden müssen. Nicht aus dem Kontext von Startups oder Greenfield-Projekten.
In diesem Umfeld hat sich Scrum durchgesetzt. Nicht als Vorgehen, um zu lernen, ob das Richtige gebaut wird – sondern als Delivery-Maschine.
Die Zeremonien erzeugen Struktur und Takt. Aber sie erzeugen nicht automatisch Klarheit darüber, ob das Richtige gebaut wird. Sprints laufen. Backlogs werden abgearbeitet. Retros sagen «gut gelaufen». Und das Produkt wirkt trotzdem nicht – weil die Fragen, die vor dem ersten Sprint hätten gestellt werden müssen, nie auf dem Tisch lagen.
Das ist kein Agile-Problem. Es ist ein Fokusproblem.
Dave Thomas, einer der Mitautoren des Agile Manifesto, erklärte Agile bereits 2014 für tot – nicht weil die Werte falsch wären, sondern weil der Begriff von Consultants und Zertifizierungsanbietern übernommen und ausgehöhlt wurde. Martin Fowler nannte dasselbe Phänomen «Flaccid Scrum»: Agile dem Namen nach, ohne die Haltung dahinter. Daran hat sich wenig geändert.
Das Projektabschluss-Meeting läuft gut. Das System wurde geliefert, das Budget eingehalten, der Scope erfüllt. Niemand fragt, ob das System auch genutzt wird.
Das ist kein Einzelfall. Projektbeteiligte werden am Projekt gemessen, nicht am Produkt. Solange das System läuft, läuft es. Ob Qualität und Effizienz wirklich gegeben sind, würde eine Messung zeigen – die aber oft nicht stattfindet.
Die Konsequenz ist direkt: Man kämpft fast ausschliesslich gegen Projektrisiken. Was kostet das? Wann wird geliefert? Was dabei selten gefragt wird: Bringt das Produkt den erwarteten Mehrwert? Gibt es eine einfachere Lösung, die denselben Nutzen bringt? Passt das Produkt in bestehende Prozesse – und kann die Organisation es überhaupt betreiben?
In meiner Erfahrung scheitern Vorhaben selten nur am Budget. Die eigentlichen Kosten entstehen später – wenn sich zeigt, dass das Produkt in der Praxis nicht den erwarteten Effekt hat. Oder bereits während des Bauens, wenn man mitten im Projekt merkt, dass man das Falsche budgetiert hat. Viele Teams liefern zuverlässig – nur leider das Falsche.
Mein Ansatz – und der Ansatz, den ich bei ERNI als eigenständige Leistung anbiete – setzt früher an: mit einer strukturierten Klärungsphase, bevor das grosse Budget freigegeben wird. Ich nenne diesen Schritt den Digital Design Approach – kurz DDA.
Der DDA ist keine neue Methode und kein Ersatz für bestehende Vorgehensmodelle. Er ergänzt sie um einen Schritt, der in Enterprise- und B2B-Kontexten heute oft fehlt.
Was in dieser Phase passiert: Das Problem wird nicht nur beschrieben, sondern hinterfragt. Welche Annahmen stecken dahinter – und welche davon sind kritisch? Nicht jede Annahme muss geprüft werden. Aber die, die das Vorhaben kippen würde, wenn sie nicht stimmt, muss auf dem Tisch liegen, bevor auch nur eine Zeile Code geschrieben wird. Stellt sich heraus, dass das Produkt keinen echten Mehrwert schafft, kann das Vorhaben zu diesem Zeitpunkt mit sehr geringen Kosten gestoppt werden.
Wie gross diese Phase ist, hängt vom Vorhaben ab. Was immer gleich bleibt: das Ziel. Das Risikoprofil des Vorhabens muss verstanden sein, bevor gebaut wird.
Das klingt selbstverständlich. Es ist es nicht. Wer ein Projekt startet, will es auch erfolgreich abschliessen – nicht stoppen. Eine Phase, die explizit das Stoppen ermöglicht, widerspricht der politischen Logik vieler Organisationen. Das ist der eigentliche Grund, warum dieser Schritt so selten stattfindet – nicht weil er methodisch unbekannt wäre, sondern weil er organisatorisch unbequem ist.
In Enterprise- und B2B-Kontexten ist diese Klärung trotzdem besonders wichtig. Man kann hier nicht beliebig Versionen veröffentlichen und das Produkt bei jedem Release grundlegend verändern. Systeme sind eingebettet in Prozesse, Verträge und Organisationen. Fehler werden teuer.
Was folgt nach dem DDA, ist keine Überraschung: Das Vorhaben wird budgetiert, das Team zusammengestellt, die Auslieferung so gestaltet, wie es für Organisation, Markt und Zielgruppe sinnvoll ist. Das Ergebnis ist oft kein klassisches MVP – sondern ein Minimum Marketable Product: das kleinste Produkt, das tatsächlich nutzbar ist und einen klaren Mehrwert liefert.
Und das Vorgehen – Scrum, Kanban, SAFe, oder etwas dazwischen – wird dem Vorhaben angepasst. Nicht umgekehrt.
Die entscheidende Frage am Anfang lautet nicht: Welches Framework setzen wir ein? Sondern: Was wissen wir schon – und was müssen wir erst herausfinden?
Viele Projekte scheitern nicht daran, dass Teams schlecht arbeiten. Sie scheitern daran, dass niemand früh genug gefragt hat, welches Problem überhaupt gelöst werden soll – und ob die gewählte Lösung das richtige Mittel dafür ist.
Das grösste Risiko liegt selten in der Umsetzung. Es liegt in der falschen Problemdefinition. Fehler, die dort entstehen, lassen sich später kaum noch korrigieren – weil sie ins System eingebaut sind: in die Architektur, in die Verträge, in die Organisation. Wer dann nachbessert, finanziert das Vorhaben ein zweites Mal.
Und genau dort – vor dem ersten Sprint, vor dem ersten Budget, vor dem ersten Release– fängt sinnvolle Produktarbeit an. Nicht im Sprint, sondern davor.