Warum „agile“ Transformationen scheiternohne Continuous Delivery von Funktionen
0,5 % der Großprojekte werden pünktlich, im Budget und mit dem erwarteten Mehrwert geliefert. Die übrigen 99,5 % sind keine Zufälle. Sie sind die strukturellen Folgen eines Preis- und Projektmanagementmodells, dessen Grenzen seit Jahrzehnten dokumentiert sind.
0,5 %
der Projekte werden pünktlich, im Budget und mit dem erwarteten Mehrwert geliefert
Flyvbjerg, How Big Things Get Done, 2023 (16.000 Projekte)
52,1 %
der Projekte überschreiten ihr ursprüngliches Budget
Flyvbjerg, How Big Things Get Done, 2023 (16.000 Projekte)
2/3
der entwickelten Funktionen liefern keinen messbaren Mehrwert
Kohavi et al., Microsoft Research, 2009
Wenn Umfang, Budget und Zeitplan gleichzeitig festgelegt werden (das eiserne Dreieck), hat das Projekt keinen Spielraum zur Anpassung. Der Druck steigt, bis etwas nachgibt: der tatsächliche Umfang (Funktionen verschwinden stillschweigend), die Codequalität (Abkürzungen häufen sich) oder das Budget (Nachträge, Refinanzierungen, ein zweiter Vertrag, um das abzuschließen, was der erste hätte liefern sollen).
Story Points veranschaulichen diesen Mechanismus gut. Ursprünglich schätzten Extreme-Programming-Teams in „idealen Tagen,“ einer Abstraktion der ununterbrochenen Arbeitszeit. Kunden lasen „3 ideale Tage“ und verstanden „Mittwoch.“ Sie machten Zusagen an ihre Geschäftsleitung auf dieser Grundlage, und Teams wurden an Fristen gebunden, die sie nie genannt hatten. Story Points wurden geschaffen, um diese Verbindung zum Kalender zu brechen: eine bewusst abstrakte Einheit, ohne mögliche Umrechnung in Tage.
Die Branche stellte die Umrechnung wieder her. Story Points wurden mit einem willkürlichen Koeffizienten multipliziert, um Tage zu erhalten, dann Termine, dann vertragliche Verpflichtungen. 2019 schrieb Ron Jeffries, einer der Erfinder der Story Points: „I may have invented story points, and if I did, I’m sorry now.“ Der Sprint Backlog ist nichts anderes als ein um 90 Grad gedrehtes Gantt-Diagramm (Frédéric Leguedois).
Milliarden an öffentlichen Mitteln verschwendet, dokumentiert von Rechnungshöfen und Parlamenten mehrerer Länder.
EUR 3,2 Mrd.
Vergleichssumme für ein satellitengestütztes Mautsystem, das sich um 18 Monate verzögerte und 14 Jahre Schiedsverfahren auslöste. Das längste und teuerste öffentliche IT-Schiedsverfahren in der europäischen Geschichte.
Deutsche Telekom / Global Arbitration Review, 2018CAD 5,1 Mrd.
für ein Gehaltsabrechnungssystem für 300.000 Beamte, das nach mehr als 10 Jahren Entwicklung noch immer nicht in der Lage ist, sie korrekt zu bezahlen. Ursprüngliches Budget: 310 Millionen.
Auditor General von Kanada, 2026EUR 400 Mio.
für ein HR-System für 1,1 Millionen Beamte. Das Projekt wurde nach 11 Jahren eingestellt und hatte nur 2 % der betroffenen Beamten erreicht.
Cour des comptes, 2020Organisationen, die Continuous Delivery praktizieren, erzielen dagegen messbare Ergebnisse:
182x
mehr Kapazität, Mehrwert an Kunden zu liefern
8x
weniger Produktionsausfälle
2.293x
schnellere Wiederherstellung bei Ausfällen
DORA State of DevOps 2024
„Agile Softwareentwicklung funktioniert, weil sie die Anwendung der wissenschaftlichen Methode auf die Softwareentwicklung ist.“
Dave Farley, Hypothesis Based Development
Jede Idee ist eine Hypothese. Jede Auslieferung ist ein Experiment. Jedes Nutzerfeedback ist ein Datenpunkt.
Agile Softwareentwicklung: was das Manifest tatsächlich sagt
Das Agile Manifest und seine 12 Grundprinzipien passen auf eine Seite. Vier Werte:
- Funktionierende Software über umfassende Dokumentation
- Zusammenarbeit mit dem Kunden über Vertragsverhandlung
- Reagieren auf Veränderung über das Befolgen eines Plans
- Individuen und Interaktionen über Prozesse und Werkzeuge
Sprint Planning, Story Points, Scrum-Zeremonien (Daily Standup, Sprintplanung, Sprint Review), der Scrum Master, Velocity-Diagramme, agile Methodologien, agiles Management, SAFe und Skalierungs-Frameworks: nichts davon steht im Manifest.
Die Regeln wurden wichtiger als die Prinzipien, denen sie dienen sollten. Das Ergebnis wird in Milliarden gemessen, investiert in Software, die niemand nutzt.
Das Problem ist nicht das, was das Manifest sagt, sondern das Preismodell und der Projektmanagementprozess, die es umgeben.
Bei DEVEDANOS, in unserem agilen Ansatz, bauen wir jede Funktion als zu verifizierende Hypothese, konfrontieren sie mit der Realität Ihrer Nutzer und passen das Produkt an, basierend auf dem, was wir beobachten. Der Plan entwickelt sich im Kontakt mit der Wirklichkeit weiter. Die Spezifikationen entwickeln sich mit. Der Entwicklungsprozess ist darauf ausgelegt zu lernen, anstatt ein Dokument auszuführen, das niemand mehr lesen wird.
Wie wir arbeiten
Agiler Ansatz: Wir entscheiden gemeinsam, was wir bauen
Prioritäten
Der klassische Ansatz
Ein Projektmanager entscheidet, auf Basis eines vor Monaten geschriebenen Dokuments (Wasserfallmodell, V-Modell)
Unser Ansatz
Sie sind der Product Owner: Sie kennen Ihren Markt, Sie steuern die Nutzerforschung, Sie entscheiden, was den größten Mehrwert hat. Jede Woche wählen wir gemeinsam die nächste Hypothese zum Testen. Wir beobachten, was Nutzer tatsächlich in der Software tun. Wenn deren Bedürfnisse nicht mit Ihren Prioritäten übereinstimmen, sagen wir es Ihnen
Richtungswechsel
Der klassische Ansatz
Nachtrag, Mehrkosten, Verzögerung
Unser Ansatz
Sie ändern die Prioritäten, wann immer Sie wollen, in voller Flexibilität und Reaktionsfähigkeit. Der Vertrag ändert sich nicht. Der Preis auch nicht
Validierung
Der klassische Ansatz
Gesamtlieferung am Projektende (Tunneleffekt). Ihre einzige Wahl: das Abnahmeprotokoll unterschreiben
Unser Ansatz
Jede Funktion wird von Ihnen validiert, bevor sie in Produktion geht. Sie genehmigen oder Sie lehnen ab
Fortschrittssichtbarkeit
Der klassische Ansatz
Monatliche Demonstrationen. Fortschrittsprozentzahlen, die von der tatsächlichen Software abgekoppelt sind
Unser Ansatz
Sie öffnen die Anwendung jederzeit und nutzen, was geliefert wurde. Funktionierende Software in Produktion ist der wichtigste Maßstab für den Fortschritt. Unser Kanban-Board und Backlog sind ebenfalls jederzeit einsehbar
Zwei Drittel der entwickelten Funktionen liefern keinen messbaren Mehrwert. Das lässt sich nur durch Auslieferung feststellen. Wir bauen daher jede Idee als minimales Inkrement, bringen es in Produktion und beobachten, was Ihre Nutzer tun. Was wir lernen, bestimmt das Weitere: fortsetzen, anpassen oder einstellen. Die Wartungskosten einer nutzlosen Funktion betragen das 3- bis 4-Fache der ursprünglichen Entwicklungskosten (Capers Jones, Applied Software Measurement, 2008). Ein flexibler Umfang und iterative Entwicklung sind kein Luxus: Sie sind der einzige Lean-Mechanismus, der diese Blutung stoppt und Kundenzufriedenheit sicherstellt. Gemeinsam bilden wir ein agiles Team. Die agilen Praktiken, die wir anwenden, decken den gesamten Softwarelebenszyklus ab.
Jede Funktion ist eine Iteration: ein vollständiger Entwicklungszyklus
Wir definieren gemeinsam, was die Software leisten soll.
Wir untersuchen, planen und synchronisieren uns kontinuierlich, durch die Arbeit selbst.
Wir identifizieren, was gerade den größten Mehrwert für Ihre Nutzer hat, und zerlegen es in lieferbare User Stories.
Für diese Funktion formulieren wir konkrete Kriterien: Was muss die Software genau tun, damit Sie die Arbeit validieren können? Diese Kriterien werden in automatisierte Tests übersetzt. Wenn die Tests bestehen, ist die Arbeit lieferbar. Wenn nicht, dann nicht.
Jede Änderung wird automatisch verifiziert, bevor sie Ihre Abnahmeumgebung erreicht.
Jede Codeänderung löst eine Kette aus kontinuierlicher Integration und automatisierter Verifizierung aus (die „Pipeline“). Schnelle Prüfungen (Unit-Tests, Typprüfung, statische Analyse) dauern weniger als 5 Minuten. Abnahmetests und Integrationstests, die das von Ihren Nutzern erwartete Verhalten nachbilden, dauern weniger als 30 Minuten.
Eine Änderung, die in einer dieser Stufen scheitert, erreicht niemals Ihre Abnahmeumgebung. Technische Mängel werden vorab abgefangen. Nur Funktionen, die den in Schritt 1 definierten Kriterien entsprechen, erreichen Sie.
Sie validieren; wir gehen live.
Sie testen jede Funktion in einer Abnahmeumgebung, die identisch mit der Produktion ist. Parallel führt die Pipeline Sicherheitsaudits und Leistungstests durch. Von der Änderung bis zum vollständigen Ergebnis: weniger als eine Stunde.
Wenn das Ergebnis Ihren Erwartungen entspricht, machen wir die neue Version für Ihre Nutzer sichtbar. Der Code ist bereits über automatisiertes Deployment (Git, Docker, GitLab CI) bereitgestellt; er wartet auf Ihre Freigabe zur Aktivierung. Idealerweise mindestens ein Produktions-Release pro Woche. Nichts geht ohne Ihre Genehmigung live.
Was kontinuierliche Verbesserung in 6 Monaten bewirkt
Ihre Nutzer bleiben und Ihr Umsatz wächst
Software, die jede Woche von echten Nutzern validiert wird. Sie messen, was funktioniert, Sie entfernen, was nicht dient, und Ihre Investition liefert sichtbare Ergebnisse ab den ersten Wochen.
Sie geben Ihren Wettbewerbern das Tempo vor
Sie besetzen das Feld. Sie iterieren schneller.
Jeder investierte Euro finanziert eine Funktion, die tatsächlich genutzt wird
Was nicht diente, wurde innerhalb von Tagen entfernt. Das Budget finanziert ausschließlich das, was Ihre Nutzer tatsächlich nutzen.
Ihr Unternehmen absorbiert Wachstum, ohne proportional mehr Personal einzustellen
Die Software übernimmt, was Neueinstellungen erfordert hätte: wiederkehrende Verarbeitungen, Nachverfolgungen, Synchronisierungen, Berichtswesen. Ihr Geschäft wächst und Ihr aktuelles Team reicht aus, weil die Software das zusätzliche Volumen auffängt.
Die Null-Regressions-Garantie
Jede Funktion, die Sie genehmigen, wird durch einen automatisierten Test gesichert. Wenn eine spätere Änderung ihr Verhalten verändert, erkennt der Test die Regression, bevor Ihre Nutzer es bemerken.
Die Person, die den Code geschrieben hat, ist diejenige, die Ihnen antwortet.
Abgedeckt
- Jede in der Abnahme genehmigte Funktion, deren Verhalten sich durch eine spätere Änderung verändert
- Korrektur bereitgestellt in Stunden statt in Wochen
Nicht abgedeckt
- Anfragen für neue Funktionen (als reguläre Arbeit gezählt, nicht als Regression)
- Ausfälle von Drittanbieterdiensten (Hosting, externe APIs)
Ihr Monatsbudget steht fest und ist ab dem ersten Gespräch bekannt. Wir legen es gemeinsam beim Erstgespräch fest, für 15 Entwicklungstage pro Monat.
15 Tage, um sich eine Meinung zu bilden. Keine Rechnung, wenn das Ergebnis Sie nicht überzeugt.
Der erste Monat ist eine Testphase. Wir rahmen die Arbeit mit Ihnen, dann entwickeln und deployen wir kontinuierlich. Sie prüfen jede Funktion. Wenn die Arbeit Sie nicht überzeugt, wird keine Rechnung gestellt und Sie schulden nichts.
Sébastien Nobour
Software-Entwickler · Gründer von DEVEDANOS
Die Person, die den Code schreibt, ist Ihr Ansprechpartner.
Häufig gestellte Fragen
Liefern Sie Schätzungen?
Wir legen keine Anzahl von Tagen pro Funktion fest. Wir legen Ihr Monatsbudget fest und unsere Zusage, jede Woche die wertvollsten Funktionen für Ihr Unternehmen zu liefern. Sie testen, Sie genehmigen, wir deployen. Wenn sich Ihre Prioritäten ändern, ändern wir uns mit. Sie kennen Ihre genaue Ausgabe im Voraus: ein festes Monatsbudget, das wir gemeinsam beim Erstgespräch festlegen. Der Inhalt jeder Lieferung entwickelt sich jedoch mit der Realität weiter, weil sich Ihre Prioritäten weiterentwickeln werden. Und genau das schützt Sie.
Wie funktioniert Ihr Modell?
Ein festes Monatsbudget, ein flexibler Umfang. Wenn Umfang, Budget und Zeitplan gleichzeitig festgelegt werden, hat das Projekt keinen Spielraum zur Anpassung. Das schätzungsbasierte Preismodell legt den Umfang fest, bevor irgendjemand das Problem versteht. Fehlende Funktionen werden zu einem zweiten Vertrag, und fragiler Code erzeugt fakturierbaren Wartungsaufwand.
Wir legen das Monatsbudget fest und liefern jede Woche die wertvollsten Funktionen für Ihr Unternehmen. Sie ändern die Richtung, wann immer Sie wollen, ohne Nachtrag. Sie prüfen jede Funktion vor dem Produktionsgang. Und Sie können das Abonnement jederzeit per einfacher schriftlicher Mitteilung beenden.
Können wir die Prioritäten während des Projekts ändern?
Jederzeit. Sie ändern die Prioritäten, wann immer Sie wollen; der Vertrag ändert sich nicht, der Preis auch nicht. Jede Woche wählen wir gemeinsam die nächste Hypothese zum Testen.
Was passiert, wenn Ihr leitender Entwickler nicht verfügbar ist?
Die Continuous-Delivery-Pipeline ist die lebendige Dokumentation des Projekts: Testautomatisierung, die das erwartete Geschäftsverhalten beschreibt, kontinuierliches Deployment über mehrere Umgebungen, Infrastructure as Code. Ein kompetenter Entwickler kann die Entwicklung innerhalb weniger Tage wiederaufnehmen, wenn die Testsuite grün ist und das Deployment per Knopfdruck läuft. Der Quellcode, die Infrastruktur, die Deployment-Pipeline und die Dokumentation sind ab der ersten Zahlung Ihr geistiges Eigentum. Die Pipeline verifiziert weiterhin jede zukünftige Änderung, unabhängig davon, welcher Entwickler daran arbeitet.
Was ist der Unterschied zwischen Ihrem Ansatz und einem klassischen agilen Projekt?
Ein klassisches agiles Projekt legt den Umfang in einem Backlog fest, teilt die Arbeit in Sprints auf und misst die Velocity des Teams. Iterative Entwicklung liefert Inkremente, aber der Umfang bleibt durch den ursprünglichen Vertrag festgelegt. Unser Ansatz hält ein festes Budget und einen flexiblen Umfang aufrecht: Das Entwicklungsteam liefert jede Woche die wertvollsten Funktionen. Prioritäten ändern sich mit Ihrem Markt, nicht mit einem vor Monaten geschriebenen Dokument. Wir verpflichten uns, die Software dauerhaft in einem deploybaren Zustand zu halten und jeden Monat funktionierende Software in Produktion zu liefern.
Bin ich an eine Mindestvertragslaufzeit gebunden?
Nein. 15 Tage, um sich eine Meinung zu bilden. Keine Rechnung, wenn das Ergebnis Sie nicht überzeugt. Danach ist das Abonnement monatlich, jederzeit kündbar per einfacher schriftlicher Mitteilung. Festes Monatsbudget, gemeinsam auf Basis Ihres Projekts festgelegt.
Bereit, den Unterschied zu sehen?
30 Minuten. Wir hören Ihr Problem und sagen Ihnen, ob wir helfen können.