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.

Executive Summary

2001 unterzeichneten siebzehn Engineers 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 haben sich mehrere dieser Autoren öffentlich von dem distanziert, wozu der Begriff geworden ist. 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 treiben, 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 späteren Vorträgen, leisten weiterhin die Unternehmen selbst. Die Beratungen bringen wie in der Fabel von der Steinsuppe meistens nur den Topf.

„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. Das Muster zeigt sich auch in den Daten aus der Praxis. Die langjährigen jährlichen State-of-Agile-ähnlichen Umfragen unter Agile-Praktikern berichten, das größte Hindernis der Einführung sei nicht technisch, sondern kulturell. 2023 nannte fast die Hälfte der Befragten allgemeine organisatorische Veränderungsresistenz oder einen Kulturkonflikt als Grund dafür, dass die Business-Seite Agile nicht annahm. Dieser Anteil stieg von Jahr zu Jahr. Branchenberichte bis 2024 dokumentierten die Kehrseite: die sinkende Beliebtheit von Agile in großen Unternehmen, wobei Developer-Burnout als zentraler Faktor genannt und der „Kultstatus“ der Methode offen hinterfragt wurde. Wenn Menschen innerhalb des Rollouts Kulturkonflikt und Erschöpfung statt Streit über Technik melden, wird die Diagnose der Unterzeichner von unten bestätigt.

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 längst keine Metapher mehr, sondern eine Bilanzposition. Stripes Developer Coefficient von 2018, basierend auf rund 3.000 Developern, ergab, dass ein durchschnittlicher Engineer etwa 13,5 Stunden jeder Arbeitswoche mit Technical Debt und weitere 3,8 Stunden mit schlechtem Code verbringt. Rund 42 Prozent der Woche fließen damit nicht in neue Funktionen. Der Bericht bezifferte den verlorenen globalen Output auf etwa 85 Milliarden US-Dollar pro Jahr (6). McKinseys Forschung zu Tech Debt bringt dasselbe Phänomen in die Bilanz: Befragte CIOs schätzten Technical Debt auf 20 bis 40 Prozent des Gesamtwerts ihrer Technologie-Landschaft vor Abschreibung, und ein Fünftel des nominell für neue Produkte bestimmten Budgets werde still zur Bedienung dieser Schuld umgeleitet (7). Das Consortium for Information & Software Quality schätzte 2022 die von US-Unternehmen angehäufte Technical Debt auf rund 1,52 Billionen US-Dollar, innerhalb von insgesamt 2,41 Billionen US-Dollar Kosten schlechter Softwarequalität (8). Diese Zahlen sind zwangsläufig ungenau, und die beauftragenden Anbieter haben ein Interesse an alarmierenden Ergebnissen. Doch ihre Größenordnung wird durch unabhängige Studien bestätigt und beschreibt genau den Zinseszinseffekt, den Cunningham 1992 benannte. Die Disziplinen, die De-Engineering entfernt, sind jene, die diese Zahl niedrig hielten.

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. Thomas bemerkte, 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. 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 DORA-Programm von Nicole Forsgren, Jez Humble und Gene Kim, gestützt auf die State-of-DevOps-Umfragen und 2018 in Accelerate zusammengeführt, zeigte mit strengen statistischen Methoden über Zehntausende Befragte hinweg, dass genau jene technischen Fähigkeiten, die dieser Artikel als „Handwerk“ bezeichnet, messbare Treiber sowohl der Delivery-Performance als auch organisatorischer Ergebnisse sind: Continuous Integration, Testautomatisierung, Trunk-based Development und lose gekoppelte Architektur (13). 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. DORA zeigt, dass die verworfenen Disziplinen jene sind, die funktionieren. Das macht ihre Aufgabe zu einer schwereren Anklage gegen die verordneten Frameworks, nicht zu einer leichteren. Die Verantwortlichen des Programms sprachen zudem ungewöhnlich offen über den Fehlermodus. Im Oktober 2023 warnte das DORA-Team ausdrücklich davor, seine vier Metriken zum Vergleich von Teams zu verwenden, also genau für jene Nutzung, die Unternehmen besonders begeistert übernahmen. Unabhängige Forschung des Informatikers Junade Ali mit dem Meinungsforschungsinstitut Survation ergab, dass Engineers und Nutzer Faktoren, die von den vier Kennzahlen nicht erfasst werden, höher gewichteten als die Geschwindigkeitsmaße selbst. Die Lektion stimmt mit allem zuvor überein: Sobald eine sinnvolle Fähigkeitsmessung zum teamübergreifenden Ziel erhoben wird, verschlechtert Goodharts Gesetz sie genauso wie Velocity. DORA legitimierte nicht die Metrikfixierung, die Unternehmen in seinem Namen praktizieren. Es warnte davor. Die richtigen Dinge zu messen und sie zum Ziel 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, Velocity und sogar DORAs vier Schlüsselmetriken werden zu 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

1. Beck, K. et al. (2001) Manifesto for Agile Software Development. Available at: https://agilemanifesto.org (Accessed: 23 June 2026).
2. Cunningham, W. (1992) ‘The WyCash portfolio management system’, OOPSLA ’92 Experience Report. (Origin of the ‘technical debt’ metaphor.) Available at: https://c2.com/doc/oopsla92.html (Accessed: 23 June 2026).
3. Thomas, D. (2014) ‘Agile is dead (long live agility)’. Available at: https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html (Accessed: 23 June 2026).
4. Jeffries, R. (2018) ‘Developers should abandon Agile’. Available at: https://ronjeffries.com/articles/018-01ff/abandon-1/; see also the ‘Dark Scrum’ collection: https://ronjeffries.com/categories/dark-scrum/ (Accessed: 23 June 2026).
5. Fowler, M. (2018) ‘The state of agile software in 2018’. Available at: https://martinfowler.com/articles/agile-aus-2018.html (Accessed: 23 June 2026).
6. Stripe and Harris Poll (2018) The Developer Coefficient: Software Engineering Efficiency and Its $3 Trillion Impact on Global GDP. Available at: https://stripe.com/files/reports/the-developer-coefficient.pdf (Accessed: 23 June 2026).
7. McKinsey & Company (2020) ‘Tech debt: reclaiming tech equity’. Available at: https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business (Accessed: 23 June 2026).
8. Consortium for Information & Software Quality (2022) The Cost of Poor Software Quality in the US: A 2022 Report. (Author: H. Krasner.) Available at: https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/ (Accessed: 23 June 2026).
9. Strathern, M. (1997) ‘“Improving ratings”: audit in the British university system’, European Review, 5(3), pp. 305-321. Available at: https://doi.org/10.1017/S1062798700002660 (Accessed: 23 June 2026).
10. Goodhart, C.A.E. (1975) ‘Problems of monetary management: the UK experience’, in Papers in Monetary Economics, Reserve Bank of Australia. Available at: https://doi.org/10.1007/978-1-349-17295-5_4 (Accessed: 23 June 2026).
11. DeMarco, T. (2009) ‘Software engineering: an idea whose time has come and gone?’, IEEE Software, 26(4), pp. 95-96. Available at: https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf (Accessed: 23 June 2026).
12. Conway, M.E. (1968) ‘How do committees invent?’, Datamation, 14(4), pp. 28-31. Available at: https://www.melconway.com/Home/Conways_Law.html (Accessed: 23 June 2026).
13. Forsgren, N., Humble, J. and Kim, G. (2018) Accelerate: The Science of Lean Software and DevOps. Portland: IT Revolution Press. Available at: https://itrevolution.com/product/accelerate/ (Accessed: 23 June 2026).
14. Taylor, F.W. (1911) The Principles of Scientific Management. New York: Harper & Brothers. Available at: https://www.gutenberg.org/ebooks/6435 (Accessed: 23 June 2026).
15. Ensmenger, N. (2010) The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise. Cambridge, MA: MIT Press. (On the “black art” of programming, the 1968 NATO conference, and the rationalisation of programming labour.) Available at: https://doi.org/10.7551/mitpress/9780262050937.001.0001 (Accessed: 23 June 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. Brussels: NATO Scientific Affairs Division, pp. 138-155. Available at: https://www.cs.dartmouth.edu/~doug/components.txt (Accessed: 23 June 2026).
17. Cusumano, M.A. (1991) Japan’s Software Factories: A Challenge to U.S. Management. New York: Oxford University Press. (On the industrialisation of programming via the “software factory”.) Available at: https://global.oup.com/academic/product/japans-software-factories-9780195062168 (Accessed: 23 June 2026).

Presse- und Webquellen (nummeriert zur Faktenprüfung)

Wenn der Haupttext einer namentlich genannten Person eine konkrete Aussage zuschreibt, steht die Primärquelle oben unter „Literatur“. Die folgenden Einträge dokumentieren die verwendete Sekundärberichterstattung und Umfragedaten sowie die jeweils gestützten Punkte.

• InfoQ (2018). ‘Ron Jeffries says developers should abandon “Agile”.’ “Faux/Dark Agile”; enterprise-vs-developer asymmetry; imposition via SAFe/LeSS. infoq.com/news/2018/06/developers-should-abandon-agile
• pragdave (2014). ‘Agile is Dead (Long Live Agility).’ Noun-vs-adjective argument; “marketing term”; ballet/trade-union analogies. pragdave.me
• Martin Fowler (2018). ‘The State of Agile Software in 2018.’ “faux-agile”; the name used against its own principles. martinfowler.com/articles/agile-aus-2018.html
• Wikipedia (2026). ‘Technical debt.’ Cunningham’s 1992 origin and the “standstill” quotation; extension of the metaphor to architecture and social structures. en.wikipedia.org/wiki/Technical_debt
• Chaco Canyon Consulting (2019). ‘Conway’s Law and Technical Debt.’ Conway’s 1968 Datamation observation; architecture mirrors communication structure. chacocanyon.com/pointlookout/190130.shtml
• Ensmenger, N. (2010), The Computer Boys Take Over (MIT Press), and the “black art” chapter; programming reframed as “too artistic” at the 1968 NATO conference and rationalised thereafter; software engineering as a management response to a crisis of control. Author’s companion site: thecomputerboys.com
• Laws of Software Engineering (2026). ‘Goodhart’s Law.’ Strathern phrasing; velocity, coverage and bug counts as gamed targets. lawsofsoftwareengineering.com/laws/goodharts-law
• Java Code Geeks (2026). ‘We have been measuring developer productivity wrong for forty years.’ LOC → velocity history; estimate inflation (“a 3 becomes a 5”); cross-team comparison breakdown. javacodegeeks.com
• InfoQ (2009) and IEEE Software (2009). DeMarco, ‘Software Engineering: An Idea Whose Time Has Come and Gone?’ Recantation of “you can’t control what you can’t measure”; software as experimental/uncontrollable; primacy of transformation. infoq.com/news/2009/08/demarco-software-engineering
• Wikipedia (2026). ‘DevOps Research and Assessment.’ DORA’s October 2023 warning against team-by-team comparison; Junade Ali / Survation findings on factors beyond the four key metrics. en.wikipedia.org/wiki/DevOps_Research_and_Assessment
• IT Revolution / dora.dev (2018-2026). Accelerate research scope (four years; 23,000+ respondents; 2,000+ organisations); the four key metrics and their capability drivers. dora.dev/resources
• DevClass (2024). ‘Enterprises struggle with Agile methodology.’ Practitioner survey: organisational resistance / culture clash cited by ~half, rising year on year. devclass.com
• IT Pro (2024). ‘Agile development is fading in popularity at large enterprises, and developer burnout is a key factor.’ itpro.com
• The Agile Revolution Podcast, Ep. 119 (2016). Dave Thomas interview: “1,000 working on one thing can never be agile”; enterprise must become agile before any project can be. theagilerevolution.com
• Smartpedia, t2informatik (2025). ‘What is Technical Debt.’ Cunningham as one of the 17 Manifesto authors; taxonomy of debt including Conway-driven “service debt”. t2informatik.de/en/smartpedia/technical-debt
• Stripe / Harris Poll (2018). The Developer Coefficient (survey of ~3,000 developers). 13.5 hrs/week on technical debt and 3.8 hrs on bad code (~42% of the week); ~$85bn global opportunity cost. stripe.com/files/reports/the-developer-coefficient.pdf
• McKinsey & Company (2020). ‘Tech debt: reclaiming tech equity.’ CIOs estimate tech debt at 20-40% of technology-estate value before depreciation; ~20% of new-product budget diverted to servicing it. mckinsey.com
• CISQ (2022). The Cost of Poor Software Quality in the US: A 2022 Report (H. Krasner). Accumulated US technical debt ~$1.52tn; total cost of poor software quality ~$2.41tn. it-cisq.org