Agile De-Engineering

Wie eine Bewegung zur Befreiung von Engineers die Engineering-Kultur im Enterprise aushöhlte

Veröffentlicht von Polity | Juni 2026
Autoren: Alexandre Kotcherguine, Vision Officer & Investor, Polity;
Kevin Riedl, Managing Partner, Wavect GmbH

Dieser Artikel befasst sich mit Methoden der Softwareentwicklung und Organisationsdesign. Er stützt sich auf öffentlich zugängliche Quellen, darunter die Schriften der Unterzeichner des Agile Manifesto selbst, sowie auf empirische Forschung im Software Engineering. Nichts darin stellt professionelle, rechtliche oder Anlageberatung dar.

Das Wichtigste vorab

2001 unterzeichneten siebzehn Softwarepraktiker das Manifesto for Agile Software Development. Es war eine Revolte gegen die schwerfälligen, kontrollorientierten Prozesse der vorangegangenen Jahrzehnte und eine Verteidigung des Handwerks, funktionierender Software und der Menschen, die sie schreiben. Zwei Jahrzehnte später kritisierten mehrere dieser Autoren öffentlich, was aus der markenförmigen Umsetzung von Agile geworden war. Dieser Artikel argumentiert, dass das, was große Organisationen heute unter dem Agile-Banner praktizieren, häufig De-Engineering ist: die schrittweise Entfernung jener technischen Disziplinen, architektonischen Freiräume und handwerklichen Urteile, die langlebige Software erst möglich machen, während die sichtbaren Zeremonien bestehen bleiben. Er zieht die Aussagen der Unterzeichner Thomas, Jeffries, Fowler und Cunningham heran und verbindet sie mit einem breiteren Kanon von Taylor und dem Arbeitshistoriker Ensmenger über Goodhart und Strathern bis Conway, DeMarco und dem DORA-Forschungsprogramm. Daraus zeichnet sich ein wiederkehrender Mechanismus ab: Eine Handwerksbewegung wird als Marke vereinnahmt; ihre prüfbaren Rituale bleiben, während ihre langsamen Engineering-Praktiken verschwinden; ihre Prognosewerkzeuge werden zu Druckinstrumenten umfunktioniert; und das Ganze wird von oben in einem Maßstab verordnet, für den es nie gedacht war. Das stärkste Gegenargument, nämlich dass Engineering-Praktiken empirisch nachweisbar Leistung vorhersagen, wird direkt geprüft und stützt die These, statt sie zu widerlegen. Die letzten Abschnitte wiederholen die Lektion, die die Unterzeichner seit fast zwei Jahrzehnten zu vermitteln versuchen: Das Gegenmittel zu De-Engineering ist kein besseres Framework, sondern die Wiederherstellung der Engineering-Kultur selbst.

Das Manifesto war ein Engineering-Dokument

Erinnern wir uns daran, wozu sich die ursprünglichen Autoren tatsächlich bekannten. Das Manifesto formulierte vier Wertpräferenzen: Individuen und Interaktionen über Prozesse und Werkzeuge, funktionierende Software über umfassende Dokumentation, Zusammenarbeit mit dem Kunden über Vertragsverhandlung sowie Reagieren auf Veränderung über das Befolgen eines Plans. Zugleich bestätigte es ausdrücklich, dass auch die Werte auf der rechten Seite Bedeutung haben. Das Dokument war eine Reaktion auf die damaligen Probleme der Softwareentwicklung und der Versuch konkurrierender Methodologen, gemeinsamen Boden zu finden (1).

Entscheidend ist, dass die Bewegung auf der Engineering-Seite keineswegs mit leeren Händen kam. Mehrere Unterzeichner stammten direkt aus dem Extreme Programming (XP), einer Disziplin, die durch testgetriebene Entwicklung, Continuous Integration, Pair Programming, Refactoring und kollektive Codeverantwortung definiert war. Kent Beck, ihr wichtigster Autor, erklärte, eines seiner Ziele bei der Erfindung von XP sei gewesen, die Arbeitsumgebung von Programmierern sicherer zu machen. Ron Jeffries, sein Mitstreiter und ebenfalls Unterzeichner, kehrte seither immer wieder zu diesem Punkt zurück. Ward Cunningham, ein weiterer der Siebzehn, hatte dem Feld bereits seinen beständigsten Begriff technischer Umsicht gegeben: Technical Debt. Die Metapher besagt, dass ein wenig nicht ganz richtiger Code die Lieferung nur so lange beschleunigt, wie er zeitnah durch Neuschreiben zurückgezahlt wird, und dass eine Organisation, die nie zurückzahlt, unter den aufgelaufenen Zinsen zum Stillstand kommen kann (2). Agilität war in ihrer Gründungsform untrennbar mit technischer Praxis verbunden. Die Leichtigkeit des Prozesses musste durch die Stärke des darunterliegenden Engineerings verdient werden.

Das Wort wurde zur Marke, und die Marke wurde verkauft

Der Niedergang beginnt nach Aussage der Autoren selbst dort, wo agile kein Adjektiv mehr war, das die Art der Arbeit beschrieb, sondern ein Substantiv, das man kaufen, zertifizieren und ausrollen konnte. 2014 veröffentlichte Unterzeichner Dave Thomas „Agile is Dead (Long Live Agility)“. Er argumentierte, das Wort sei zum Magneten für alle geworden, die abrechenbare Stunden oder Produkte zu verkaufen hätten, und zu einem Marketingetikett verkommen, ähnlich wie eco oder natural. Er habe sich bewusst von der Agile-Industrie ferngehalten, verglich Konferenzen über Agilität mit Konferenzen über Balletttanzen und einen Branchenverband rund um vier Werte mit einer Gewerkschaft für Menschen, die atmen. Hinter seiner grammatischen Kritik stand ein substanzieller Vorwurf: „do Agile right“ ist so bedeutungslos wie „do orange right“, denn Agilität ist eine Eigenschaft des Handelns und kein Produkt, das installiert wird (3).

Das ist der erste Mechanismus des De-Engineerings: Kommerzialisierung. Eine Bewegung, die Praktiker zum Schutz von Praktikern geschaffen hatten, wurde zu einer Zertifizierungsökonomie, in der die Verkäufer der Methode oft nicht diejenigen waren, die den Code schrieben. Die harte Engineering-Arbeit, so Thomas in einem Interview von 2016, leisten weiterhin die Unternehmen selbst. Die Beratungen bringen wie in der Fabel von der Steinsuppe meistens nur den Topf (20).

„Dark Agile“: Wenn der Name gegen Engineers gewendet wird

Beschrieb Thomas die kommerzielle Verwässerung, so beschrieb Ron Jeffries etwas Schärferes. 2018 riet er Developern, „Agile“, also die großgeschriebene, zur Marke gewordene Variante, aufzugeben und zu den zugrunde liegenden Werten zurückzukehren. Er unterschied „Faux Agile“ und „Dark Agile“, beim dominanten Framework auch „Dark Scrum“, um jene Formen zu benennen, die das Leben von Developern seiner Ansicht nach schlechter statt besser machten. Das war die genaue Umkehrung der ursprünglichen Absicht von XP. Seine Diagnose verdient Klartext: Wenn Agile-Ideen schlecht angewandt werden, erzeugen sie tendenziell mehr Eingriffe in die Arbeit der Developer, weniger Zeit für die eigentliche Arbeit, höheren Druck und die dauerhafte Forderung des Managements, schneller zu werden (4).

Martin Fowler, ebenfalls Unterzeichner, formulierte im selben Jahr auf einer Konferenz denselben Punkt. Der aktuelle Kampf bestehe nicht mehr darin, Menschen von Agile zu überzeugen, sondern Faux Agile entgegenzutreten: Agile dem Namen nach, ohne die Praktiken oder Werte. Noch schlimmer als bloßes Vortäuschen sei es, das Wort agile aktiv gegen die Prinzipien zu verwenden, zu deren Verteidigung es geprägt wurde (5). Zwei der siebzehn von Snowbird waren unabhängig voneinander zum selben Schluss gekommen: Das Label war vereinnahmt worden, und die Folgen trafen besonders die Engineers, denen es dienen sollte.

Das ist nicht bloß die Enttäuschung der Gründer. Digital.ai befragte für seinen 17th State of Agile Report im Jahr 2023 insgesamt 788 Personen. Der Anbieter berichtete, dass kleine Organisationen Agile weiterhin positiv bewerteten, während mittlere und große Organisationen weniger zufrieden waren und erhebliche Hürden für eine organisationsweite Einführung sahen. Außerdem nutzten 42 Prozent der Befragten ein Hybridmodell, wobei große Organisationen dies besonders häufig taten (18). Das ist eine richtungsweisende Anbieterumfrage, keine repräsentative Schätzung für alle Softwareorganisationen. Sie belegt auch nicht, dass Agile Burnout oder Unzufriedenheit verursacht hat. Sie zeigt jedoch, dass die Einführungserfahrung stark vom Organisationskontext abhängt. Das passt zu den Warnungen der Unterzeichner, eine Methode nicht wie ein installierbares Produkt zu behandeln.

Die Praktiken waren optional, also fielen sie zuerst weg

Hier liegt der strukturelle Fehler, der De-Engineering antreibt. Die sichtbaren, steuerbaren Teile von Agile, also Stand-ups, Sprints, Backlogs, Story Points und Velocity-Charts, lassen sich billig verordnen und leicht auditieren. Die Teile, die tatsächlich Engineering-Qualität liefern, also testgetriebene Entwicklung, Continuous Integration, Refactoring, Pairing und die bewusste Pflege der Codegesundheit, sind langsam zu erlernen, für nicht technische Führungskräfte unsichtbar und produzieren keine sofortige Zeremonie. Übernimmt eine Organisation das Framework, aber nicht das Handwerk, behält sie die Rituale und wirft das Engineering weg. Jeffries beobachtete, ein Grund für die Ablehnung technischer Praktiken sei die Erwartung, sie brächten keinen Nutzen. Deshalb werden sie aufgegeben, bevor ihr Wert überhaupt erfahren wurde, und ihre Abwesenheit gilt danach als Beweis dafür, dass sie verzichtbar waren.

Cunninghams Metapher erklärt die Folge mit unbequemer Präzision. Ohne Refactoring und Testdisziplin liefert jeder Sprint ein wenig mehr nicht ganz richtigen Code. Die Schuld wird nie zurückgezahlt. Die Zinsen wachsen, weil jede spätere Änderung langsamer und gefährlicher wird. So erreicht die Organisation durch eine Reihe lokal vernünftiger Entscheidungen genau den Stillstand, vor dem er warnte. „Working software over comprehensive documentation“ wird als Erlaubnis missverstanden, weder Tests noch Dokumentation zu schreiben. „Responding to change“ wird zum Freibrief für permanente Scope-Änderungen ohne den architektonischen Freiraum, sie aufzunehmen. Genau jene Disziplinen, die Technical Debt begrenzen sollten, wirkten optional und wurden deshalb gestrichen.

Der Stillstand ist nicht mehr nur eine Metapher. Organisationen versuchen auch, ihn zu beziffern. Der Developer Coefficient von Stripe und Harris Poll aus dem Jahr 2018 befragte mehr als 1.000 Developer und mehr als 1.000 Führungskräfte auf C-Level in fünf Ländern. Der Bericht nannte eine durchschnittliche Developer-Arbeitswoche von 41,1 Stunden, davon 13,5 Stunden für Technical Debt und 3,8 Stunden für schlechten Code. Stripes Schätzung von rund 85 Milliarden US-Dollar jährlichem Opportunitätsverlust bezog sich auf diese 3,8 Stunden schlechten Codes, nicht auf den gesamten Wartungsaufwand (6). McKinseys Umfrage vom Juli 2020 war noch enger: 50 CIOs von Finanzdienstleistungs- und Technologieunternehmen mit mehr als einer Milliarde US-Dollar Umsatz. Diese Befragten schätzten Technical Debt auf 20 bis 40 Prozent des Werts ihrer Technologielandschaft vor Abschreibung und gaben an, dass 10 bis 20 Prozent des Technologiebudgets für neue Produkte dorthin umgeleitet wurden (7). Das Modell des Consortium for Information & Software Quality von 2022 schätzte die angehäufte Technical Debt in den USA auf rund 1,52 Billionen US-Dollar innerhalb von mindestens 2,41 Billionen US-Dollar Gesamtkosten schlechter Softwarequalität (8). Diese Schätzungen verwenden unterschiedliche Definitionen, Stichproben, Auftraggeber und Methoden. Sie veranschaulichen, dass Schulden erhebliche Kapazität binden. Sie belegen weder eine universelle Rate noch, dass Agile die Kosten verursacht hat.

Messung, umfunktioniert: Goodhart im Sprint

Der zweite Mechanismus ist die Umwandlung von Prognosewerkzeugen in Kontrollinstrumente. Story Points und Velocity waren als grobe, teamrelative Planungshilfen gedacht. Sobald sie zu Managementzielen werden, greift Goodharts Gesetz. In der viel zitierten Formulierung der Anthropologin Marilyn Strathern über den Ökonomen Charles Goodhart gilt: „when a measure becomes a target, it ceases to be a good measure.“ (9) Sobald Velocity belohnt wird, wird aus einer ehrlich geschätzten Drei eine Fünf. Schätzungen blähen sich auf, teamübergreifende Vergleiche verlieren jede Aussagekraft und die Zahl bildet nicht mehr die Kapazität ab, die sie beschreiben sollte. Das ist keine Unehrlichkeit, sondern rationale Optimierung durch gemessene Menschen. Es ist derselbe strukturelle Effekt, den Goodhart beobachtete, als Zentralbanken begannen, jene Geldmengenaggregate als Ziele zu verwenden, die zuvor nützliche Indikatoren gewesen waren (10).

Gewarnt wurde das Feld ausgerechnet von jenem Mann, der ihm das Messen beigebracht hatte. Tom DeMarco, dessen Diktum von 1982 „you can’t control what you can’t measure“ eine ganze Generation des Softwaremanagements prägte, widerrief 2009 öffentlich. Softwareprojekte seien grundsätzlich experimentell statt kontrollierbar. Die von ihm geförderte Fixierung auf Metriken habe die Disziplin von der einzigen Frage abgelenkt, die zählt: ob die Software etwas Wertvolles verändert. Wenn der Autor des Kontrollparadigmas es verwirft, hält das Velocity-getriebene Enterprise an einer Methode fest, die ihr eigener Architekt aufgegeben hat (11).

Skalierung war nie der Punkt, doch im Enterprise ist alles Skalierung

Ein wiederkehrendes Thema in späteren Aussagen der Gründer lautet, dass Agilität für kleine, gemeinsam arbeitende und ermächtigte Teams gedacht war, nicht für Tausende Menschen, die über eine Unternehmenshierarchie koordiniert werden. Im selben Interview von 2016 bemerkte Thomas, tausend Menschen, die an einer Sache arbeiten, könnten im ursprünglichen Sinn niemals agil sein. Ein Enterprise müsse selbst agil werden, bevor es irgendein Projekt darin sein könne (20). Der kommerzielle Anreiz zeigte jedoch in die Gegenrichtung: Der größte Umsatz lag in skalierenden Frameworks wie SAFe, LeSS und ihren Verwandten, verkauft an genau jene großen hierarchischen Organisationen, für die die ursprüngliche Idee am wenigsten geeignet war.

Jeffries benannte die Folge direkt. Großflächige Rollouts werden typischerweise oben beschlossen und nach unten verordnet. Die meisten Mitarbeitenden müssen den neuen Prozess ohne angemessene Schulung und ohne Verständnis der dahinterliegenden Denkweise übernehmen. Beim Engineer kommt damit die exakte Umkehrung des ersten Manifesto-Werts an: nicht Individuen und Interaktionen, sondern ein vorgeschriebener Prozess und ein Werkzeug. Conways Gesetz schärft den Punkt. Melvin Conways Beobachtung von 1968, dass die Architektur eines Systems die Kommunikationsstruktur der Organisation spiegelt, die es baut, bedeutet: Eine starre, hierarchische und zeremoniengebundene Organisation wird tendenziell starre, spröde und schuldenbeladene Software hervorbringen, ganz gleich, welche Agile-Schilder an der Wand hängen. Das Framework skaliert die Zeremonie, nicht das Urteil. Die Architektur hält den Unterschied fest (12).

Der stärkste Einwand: Aber die Praktiken sind messbar wirksam

Der ernsthafteste Einwand gegen dieses Argument kommt nicht von Beratungen, sondern aus der besten empirischen Forschung des Feldes und verdient seine stärkste Form. Das mit Nicole Forsgren, Jez Humble und Gene Kim verbundene DORA-Programm wertete mehrjährige State-of-DevOps-Umfragedaten statistisch aus und führte die Ergebnisse 2018 in Accelerate zusammen. Dabei wurden technische Fähigkeiten wie Continuous Integration, Testautomatisierung, Trunk-based Development und lose gekoppelte Architektur als Prädiktoren für Delivery-Performance und organisatorische Ergebnisse identifiziert (13). Das ist ein starker Beleg für Zusammenhang und Vorhersagekraft, aber kein Nachweis, dass eine einzelne Praxis jedes Ergebnis in jedem Kontext verursacht. Wenn sich der Ertrag von Engineering-Disziplin nachweisen lässt, so der Einwand, wird der Markt sie auswählen. Von De-Engineering zu sprechen, sei daher fehlgeleiteter Pessimismus.

Der Einwand hat sachlich recht und liefert gerade deshalb Belege für die These. DORAs Ergebnisse zeigen, dass die verworfenen Disziplinen mit besseren Resultaten zusammenhängen. Das macht ihre Aufgabe zu einer schwereren Anklage gegen verordnete Frameworks, nicht zu einer leichteren. Ebenso wichtig ist die eigene Messanleitung des Programms. Laut DORA eignen sich die Delivery-Metriken am besten dazu, dieselbe Anwendung im Zeitverlauf zu beobachten. Direktoren sollen reduktive Aggregationen über Teams hinweg und Vergleiche zwischen unterschiedlichen Kontexten vermeiden. Die offizielle Historie hält außerdem fest, dass sich das bekannte Modell der vier Schlüsselmetriken 2024 zu fünf Software-Delivery-Metriken weiterentwickelte. Hinzu kam die Deployment Rework Rate, und die Metriken wurden in Durchsatz und Instabilität gruppiert (19). Die Lektion stimmt mit allem zuvor überein: Sobald eine sinnvolle Messung zu einem kontextfreien teamübergreifenden Ziel erhoben wird, kann Goodharts Gesetz sie genauso wie Velocity entwerten. DORA legitimiert keine Metrikfixierung, sondern setzt Messung zum Lernen und Verbessern ein. Die richtigen Dinge zu messen und sie zu Zielen zu machen sind verschiedene Handlungen. In der Lücke dazwischen lebt De-Engineering.

Das tiefere Muster: Scientific Management kehrt im Agile-Gewand zurück

Tritt einen Schritt zurück, und die Form ist vertraut, denn sie ist älter als Software. Frederick Winslow Taylors Principles of Scientific Management von 1911 schrieb drei Schritte vor, die industrielles Management bis heute definieren: Arbeit in messbare Einheiten zerlegen, den Arbeitsablauf standardisieren und, entscheidend, Planung und Ausführung trennen, also dem Arbeiter das Urteil nehmen und im Management konzentrieren (14). Der Historiker Nathan Ensmenger zeigt in The Computer Boys Take Over von 2010, dass genau dieses Programm auf die Programmierung angewandt wurde (15). Ein Handwerk, das in den 1950er Jahren als „black art“ gefeiert worden war, wurde ab der NATO Conference on Software Engineering von 1968 als „too artistic“ umgedeutet und bewusst rationalisiert. Selbst der Begriff „Software Engineering“ war nach Ensmengers Darstellung eine Managementantwort auf eine wahrgenommene Kontrollkrise über eine undiszipliniert und teuer erscheinende Arbeitskraft. Die zeitgenössische „Software Factory“-Bewegung machte den tayloristischen Anspruch explizit: Douglas McIlroys Forderung von 1968 nach massenproduzierten, aus Katalogen bestellbaren Softwarekomponenten (16) und die später von Hitachi, Toshiba, NEC und Fujitsu errichteten industriellen Softwarefabriken sollten Programmierung von einer Kunstform in eine „repeatable, scientifically managed“ Lieferkette verwandeln (17).

Die historische Ironie von Enterprise Agile liegt darin, dass es genau dieses Paradigma unter dem Banner einer Bewegung wiederhergestellt hat, die ihm entkommen wollte. Schwerfällige Phasenprozesse waren das erste tayloristische Erbe der Softwareindustrie. Das Manifesto rebellierte dagegen. Das skalierte, zeremoniengebundene Agile, das zwei Jahrzehnte später verordnet wurde, führte es leise wieder ein. Der Sprint wird zur Stoppuhr, der Story Point zur Zeit-und-Bewegungs-Einheit, das Burndown-Chart zum Vorarbeiterbuch und die „Velocity“ gibt dem Management genau jene Kontrolle zurück, die „individuals and interactions over processes and tools“ verdrängen sollte. Der Mechanismus reproduziert sogar Taylors charakteristische Trennung von Planung und Ausführung: Der Top-down-Rollout bestimmt den Prozess, der Engineer führt ihn nur aus. Deshalb verletzt das Ergebnis so oft den ersten Wert des Manifesto, während es dessen Flagge trägt. Die Position muss präzise sein, weil sie leicht als Forderung nach gar keinem Prozess missverstanden wird. Das Argument lautet nicht, Planung, Messung oder Koordination seien illegitim. Große Softwarevorhaben brauchen alle drei, und die damit verbundene Arbeitsteilung bildet seit Adam Smith die Grundlage produktiver Unternehmen. Wenn aber der Messapparat vom handwerklichen Urteil getrennt und zum Instrument des Tempos gemacht wird, misst er kein Engineering mehr, sondern unterdrückt es. DeMarcos Widerruf ist letztlich das Eingeständnis, dass das Kontrollparadigma eine kreative, experimentelle Tätigkeit mit einer deterministischen verwechselt hat und dass dieser Fehler genau dort teuer wurde, wo er am selbstsichersten angewandt wurde.

Was „De-Engineering“ tatsächlich bedeutet

Zusammengeführt ist Agile De-Engineering nicht das Scheitern einer Idee, sondern das Fortbestehen ihrer Verpackung, nachdem ihre Substanz entfernt wurde. Es verläuft in einer erkennbaren Abfolge:

1. Kommerzialisierung. Die Methode wird zu einem Produkt, zertifiziert, skaliert und von Parteien verkauft, die nicht die Software schreiben.
2. Rituelle Vereinnahmung. Die auditierbaren Zeremonien bleiben; die langsamen, unsichtbaren Engineering-Disziplinen wie Tests, Refactoring und Integration verschwinden leise.
3. Metrikumkehr. Prognosehilfen wie Points und Velocity, aber auch Software-Delivery-Metriken, werden zu kontextfreien Zielen. Goodharts Gesetz degradiert sie zu Tempoinstrumenten.
4. Verordnung im großen Maßstab. Scaling-Frameworks werden Organisationen von oben vorgeschrieben, für die die Methode nie gedacht war. Mitarbeitende erhalten Prozess ohne Denkweise.
5. Erosion des Handwerks. Technical Debt wächst unbezahlt weiter, die Architektur erstarrt in der Form der Hierarchie nach Conway, und der von Cunningham vorhergesagte Stillstand kommt eine vernünftige Entscheidung nach der anderen.

Jeder Schritt ist lokal rational und kollektiv korrosiv. Niemand beschließt De-Engineering. Es entsteht daraus, dass Sichtbares und Abrechenbares gegenüber Technischem und Langsamem optimiert wird. Das ist kein moralisches Versagen einzelner Manager. Wie jeder Goodhart-Effekt ist es eine strukturelle Eigenschaft der Anreizarchitektur, genau jene Art von Systemverhalten, der handwerkliches Urteil entgegenwirken soll und die verordnete Frameworks systematisch entfernen.

Die Erholung ist kein neues Framework

Bemerkenswert ist, dass die Gründer, die das Problem diagnostizierten, kein Agile 2.0 forderten. Thomas erklärte ausdrücklich, ein zweites Manifesto wäre ein tragischer Fehler. Die Antwort sei kein weiteres Substantiv, das zur Marke gemacht und verkauft werden könne, sondern die Rückkehr zur zugrunde liegenden Denkweise: kleine Einheiten wirklich funktionierender Software liefern, Feedbackschleifen kurz halten und vor allem jene technischen Praktiken wiederherstellen, die Agilität überhaupt antrieben. Jeffries’ Rezept ist ebenso konkret und unpathetisch: in kleinen Scheiben arbeiten, ehrlich über echte Delivery-Kapazität sein und dem Druck widerstehen, einfach nur schneller zu werden. DeMarco geht noch weiter: Er fragt, warum überhaupt so viele Projekte mit geringem Wert unter strenger Kontrolle laufen, statt die Kontrolle immer weiter zu perfektionieren.

Die Lektion für das Enterprise ist deshalb unbequem. Das Gegenmittel zu De-Engineering ist kein aufgeräumteres Board, keine höhere Zertifizierungsstufe und kein treuerer Framework-Rollout. Es ist die Wiederherstellung der Engineering-Kultur selbst: das Handwerk, der Freiraum und das professionelle Urteil, von denen die ursprünglichen Unterzeichner annahmen, sie würden immer unter dem Wort liegen. Entferne sie, und es bleibt Zeremonie: das tägliche Stand-up über einem leeren Fundament, das steigende Velocity-Chart, während die Architektur verfault. Die Autoren des Manifesto versuchen seit fast zwei Jahrzehnten, genau das in ihrem eigenen Namen und gegen ihr eigenes wirtschaftliches Interesse zu sagen. Das Enterprise behielt weitgehend die Rituale und verfehlte den Punkt. Die wichtigste Leistung des „doing Agile“ bestand in zu vielen großen Organisationen darin, Softwareentwicklung zu de-engineeren, während man glaubte, sie zu perfektionieren.

Die Finanzkrise 2008 bis 2009 lehrte eine Generation, dass elegante Modelle gefährlich werden, wenn sie von Werkzeugen zu Dogmen aufsteigen. Die Geschichte von Enterprise Agile lehrt dieselbe Lektion in einer benachbarten Disziplin: Eine Methode wird nicht dann gefährlich, wenn sie falsch ist, sondern wenn ihre Zeremonien das Handwerk überleben, das ihnen Bedeutung gab.

Über Polity

Dieser Artikel ist Teil eines fortlaufenden Programms für Governance- und Thought-Leadership-Publikationen, das innerhalb des Polity-Governance-Modells entwickelt wird. Politys zentrale These lautet, dass dauerhafte Ergebnisse, in Märkten wie in Organisationen, von der Governance-Architektur geformt werden: den Regeln, Anreizen und Institutionen, durch die Arbeit, Wert und Verpflichtung entstehen. Software Engineering ist in diesem Sinn ein Governance-Problem. Das hier beschriebene De-Engineering entsteht, wenn die Anreizarchitektur einer Organisation das Sichtbare über das Dauerhafte stellt. Polity baut Infrastruktur für regulierte digitale Finanzsysteme und Governance-Frameworks, die dezentrale Systeme mit institutionellen Compliance-Anforderungen verbinden.

Über Wavect

Die Wavect GmbH ist eine österreichische Software-Engineering-Agentur, die produktorientierte Software für Start-ups, Scale-ups und Enterprises entwickelt. Das Spektrum reicht von Full-Stack-Entwicklung über Fractional Engineering und Product Leadership bis zu Software Quality Assurance und angewandter Arbeit in künstlicher Intelligenz, Blockchain und Zero-Knowledge-Systemen. Wavect hat für das Polity-Programm Softwareentwicklungs- und Qualitätssicherungsleistungen erbracht. Co-Autor Kevin Riedl ist Managing Partner des Unternehmens. Weitere Informationen unter https://wavect.io.

Disclaimer: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken. Er stellt weder professionelle, rechtliche, finanzielle noch Engineering-Management-Beratung dar und ist keine Empfehlung für eine Methode, ein Produkt, einen Service oder eine Organisation. Verweise auf das Agile Manifesto und seine Unterzeichner, auf genannte Forscher, Frameworks, Unternehmen und Publikationen Dritter dienen ausschließlich Analyse und Kommentar. Die Aufnahme einer Quelle bedeutet weder Empfehlung durch noch Zugehörigkeit zu Polity. Co-Autor Kevin Riedl ist Managing Partner der Wavect GmbH, die Softwareentwicklungs- und Qualitätssicherungsleistungen für das Polity-Programm erbringt, siehe „Über Wavect“. Diese Geschäftsbeziehung wird im Interesse der Transparenz offengelegt und beeinträchtigt die Unabhängigkeit der Analyse nicht. Die geäußerten Ansichten sind jene der Autoren.

Literatur und Primärquellen

1. Beck, K. et al. (2001), Manifesto for Agile Software Development. agilemanifesto.org (Reviewed 2 September 2026).
2. Cunningham, W. (1992), ‘The WyCash portfolio management system’, OOPSLA ’92 Experience Report. c2.com/doc/oopsla92.html (Reviewed 2 September 2026).
3. Thomas, D. (2014), ‘Agile is dead (long live agility)’. pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html (Reviewed 2 September 2026).
4. Jeffries, R. (2018), ‘Developers should abandon Agile’. ronjeffries.com/articles/018-01ff/abandon-1/ (Reviewed 2 September 2026).
5. Fowler, M. (2018), ‘The state of agile software in 2018’. martinfowler.com/articles/agile-aus-2018.html (Reviewed 2 September 2026).
6. Stripe and Harris Poll (2018), The Developer Coefficient. stripe.com/files/reports/the-developer-coefficient.pdf (Reviewed 2 September 2026).
7. McKinsey & Company (2020), Tech debt: Reclaiming tech equity. McKinsey research PDF (Reviewed 2 September 2026).
8. Krasner, H. for the Consortium for Information & Software Quality (2022), The Cost of Poor Software Quality in the US. it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/ (Reviewed 2 September 2026).
9. Strathern, M. (1997), ‘Improving ratings: audit in the British university system’, European Review, 5(3), pp. 305-321. doi.org/10.1017/S1062798700002660 (Reviewed 2 September 2026).
10. Goodhart, C.A.E. (1975), ‘Problems of monetary management: the UK experience’. doi.org/10.1007/978-1-349-17295-5_4 (Reviewed 2 September 2026).
11. DeMarco, T. (2009), ‘Software engineering: an idea whose time has come and gone?’, IEEE Software, 26(4), pp. 95-96. doi.org/10.1109/MS.2009.101 (Reviewed 2 September 2026).
12. Conway, M.E. (1968), ‘How do committees invent?’, Datamation, 14(4), pp. 28-31. melconway.com/Home/Conways_Law.html (Reviewed 2 September 2026).
13. Forsgren, N., Humble, J. and Kim, G. (2018), Accelerate: The Science of Lean Software and DevOps. itrevolution.com/product/accelerate/ (Reviewed 2 September 2026).
14. Taylor, F.W. (1911), The Principles of Scientific Management. gutenberg.org/ebooks/6435 (Reviewed 2 September 2026).
15. Ensmenger, N. (2010), The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise. MIT Press (Reviewed 2 September 2026).
16. McIlroy, M.D. (1968), ‘Mass-produced software components’, in Naur, P. and Randell, B. (eds.), Software Engineering: Report on a Conference Sponsored by the NATO Science Committee. cs.dartmouth.edu/~doug/components.txt (Reviewed 2 September 2026).
17. Cusumano, M.A. (1991), Japan’s Software Factories: A Challenge to U.S. Management. Oxford University Press (Reviewed 2 September 2026).
18. Digital.ai (2023), 17th State of Agile Report. digital.ai/resource-center/analyst-reports/state-of-agile-report/ (Reviewed 2 September 2026).
19. DORA, ‘How to empower software delivery teams as a business leader’ and ‘A history of DORA’s software delivery metrics’. current measurement guidance; metric history (Reviewed 2 September 2026).
20. The Agile Revolution Podcast (2016), ‘Episode 119: Agile is Dead with Dave Thomas’. theagilerevolution.com/2016/11/25/episode-119-agile-is-dead-dave-thomas/ (Reviewed 2 September 2026).