Agile De-engineering

How a Movement Built to Liberate Engineers Came to Erode Engineering Culture in the Enterprise

Published by Polity | June 2026
Authors: Alexandre Kotcherguine, Vision Officer & Investor, Polity;
Kevin Riedl, Managing Partner, Wavect GmbH

This article concerns software-development methodology and organisational design. It draws on the public record, including the writings of the Agile Manifesto’s own signatories, and on the empirical software-engineering literature. Nothing in it constitutes professional, legal or investment advice.

Executive Summary

In 2001, seventeen engineers signed the Manifesto for Agile Software Development as a revolt against the heavyweight, control-oriented processes of the preceding decades, a defence of craft, of working software, and of the people who write it. Two decades later, several of those same authors have publicly disowned what the word has become. This article argues that what large organisations now practise under the Agile banner frequently amounts to de-engineering: the progressive removal of the technical disciplines, architectural slack and craft judgement that make durable software possible, leaving the visible ceremonies intact. It draws on the testimony of the signatories themselves, Thomas, Jeffries, Fowler, Cunningham, and on a wider canon spanning Taylor and the labour historian Ensmenger, Goodhart and Strathern, Conway and DeMarco, and the DORA research programme. From these it traces a recognisable mechanism: a craft movement is captured as a brand; its auditable rituals are retained while its slow engineering practices are discarded; its forecasting tools are repurposed as instruments of pressure; and the whole is imposed top-down at a scale it was never designed for. The strongest counter-argument, that engineering practices have been shown, empirically, to drive performance, is examined directly, and found to support the thesis rather than rebut it. The closing sections restate the lesson the signatories spent the better part of two decades trying to deliver: the cure for de-engineering is not a better framework, but the restoration of engineering culture itself.

The Manifesto Was an Engineering Document

Recall what the original authors actually committed to. The Manifesto set out four value preferences: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan, while explicitly affirming that there is value in the items on the right as well. The document was a reaction to the problems of development as practised at the time, an attempt by competing methodologists to find common ground (1).

Crucially, the movement did not arrive empty-handed on the engineering side. Several signatories came directly from Extreme Programming (XP), a discipline defined by test-driven development, continuous integration, pair programming, refactoring and collective code ownership. Kent Beck, its principal author, stated that one of his goals in inventing XP was to make the programmer’s working environment safer; Ron Jeffries, his collaborator and a fellow signatory, has returned to that point repeatedly since. Ward Cunningham, another of the seventeen, had already given the field its most durable concept of engineering prudence: technical debt, the metaphor that a little not-quite-right code speeds delivery only so long as it is repaid promptly by rewriting, and that an organisation which never repays can be brought to a standstill under the accumulated interest (2). Agility, in its founding form, was inseparable from technical practice. The lightness of process was meant to be earned by the strength of the engineering beneath it.

The Word Became a Brand, and the Brand Was Sold

The decline begins, by the testimony of the authors themselves, when agile stopped being an adjective describing how work was done and became a noun to be bought, certified and rolled out. In 2014, signatory Dave Thomas published “Agile is Dead (Long Live Agility)”, arguing that the word had become a magnet for anyone with hours to bill or products to sell, and had degraded into a marketing label in the manner of eco or natural. He observed that he had deliberately stayed away from the Agile industry, likening conferences about agility to conferences about ballet dancing, and an industry body built around four values to a trade union for people who breathe. His grammatical complaint carried a substantive charge: “do Agile right” is as meaningless as “do orange right”, because agility is a quality of conduct, not a product to be installed (3).

This is the first mechanism of de-engineering: commercialisation. A movement authored by practitioners to protect practitioners became a certification economy in which the parties selling the method were frequently not the parties writing the code. The hard engineering work, as Thomas put it in later talks, is still done by the companies themselves; the consultancies, in the manner of the stone-soup fable, mostly bring the pot.

“Dark Agile”: When the Name Is Turned Against the Engineers

If Thomas described commercial dilution, Ron Jeffries described something sharper. In 2018 he advised developers to abandon “Agile”, the capitalised, branded version, and return to the underlying values. He distinguished “Faux Agile” and “Dark Agile” (and, for the dominant framework, “Dark Scrum”) to name the forms that, in his account, made developers’ lives worse rather than better: the precise inverse of XP’s founding intention. His diagnosis is worth stating plainly: when Agile ideas are applied poorly, they tend to produce more interference with developers, less time to do the work, higher pressure, and a standing managerial demand to go faster (4).

Martin Fowler, another signatory, made the same point from a conference stage that year. The present struggle, he argued, was no longer persuading people to adopt agile but confronting faux-agile: agile in name, with none of the practices or values in place. Worse than merely pretending, he noted, was using the word agile actively against the principles it was coined to defend (5). Two of the Snowbird seventeen, independently, had reached the same conclusion: the label had been captured, and the capture was being felt most acutely by the engineers it was meant to serve.

This is not merely the disappointment of the founders. The pattern shows up in the practitioner data. The long-running annual State of Agile-style surveys of agile practitioners report that the leading obstacle to adoption is not technical but cultural: by 2023, close to half of respondents named general organisational resistance to change or a clash of cultures as the reason the business side was not embracing agile, a share that had risen, not fallen, year on year. Trade reporting through 2024 documented the corollary: agile’s waning popularity at large enterprises, with developer burnout identified as a central factor and the method’s “cult following” openly questioned. When the people inside the rollout report culture clash and exhaustion rather than disagreement over technique, the diagnosis the signatories offered is being confirmed from below.

The Practices Were Optional, So They Were Dropped First

Here is the structural flaw that drives de-engineering. The visible, manageable parts of Agile, stand-ups, sprints, backlogs, story points, velocity charts, are cheap to impose and easy to audit. The parts that actually deliver engineering quality, test-driven development, continuous integration, refactoring, pairing, the deliberate maintenance of code health, are slow to learn, invisible to non-technical managers and yield no immediate ceremony. When an organisation adopts the framework but not the craft, it keeps the rituals and discards the engineering. Jeffries observed that one reason teams decline to learn the technical practices is an expectation of no benefit; the practices are therefore abandoned before their value is ever realised, and their absence is then read as proof that they were dispensable.

Cunningham’s metaphor explains the consequence with uncomfortable precision. Stripped of refactoring and test discipline, each sprint ships a little more not-quite-right code; the debt is never repaid; the interest compounds as every subsequent change becomes slower and more dangerous; and the organisation arrives, by a sequence of locally reasonable decisions, at the standstill he warned of. “Working software over comprehensive documentation” is misread as licence to write neither tests nor documents. “Responding to change” becomes a warrant for perpetual scope churn without the architectural slack to absorb it. The disciplines designed to contain technical debt were precisely the optional-looking parts that got cut.

The standstill is no longer a metaphor; it is a line item. Stripe’s 2018 Developer Coefficient, surveying some 3,000 developers, found that the average engineer spends roughly 13.5 hours of each working week on technical debt and a further 3.8 hours on bad code (about 42 per cent of the week not building anything new), which the report priced at around $85 billion in lost global output annually (6). McKinsey’s tech-debt research puts the same phenomenon on the balance sheet: surveyed CIOs estimated that technical debt amounts to 20-40 per cent of the entire value of their technology estate before depreciation, and that a fifth of the budget nominally allocated to new products is quietly diverted to servicing it (7). The Consortium for Information & Software Quality, in its 2022 report, put the accumulated technical debt carried by US firms at roughly $1.52 trillion, within a total cost of poor software quality of $2.41 trillion (8). These figures are necessarily imprecise, and the vendors who commission them have an interest in alarm; but their order of magnitude is corroborated across independent studies, and it describes exactly the compounding interest Cunningham named in 1992. The disciplines that de-engineering discards are the ones that were keeping that number down.

Measurement, Repurposed: Goodhart in the Sprint

The second mechanism is the conversion of forecasting tools into instruments of control. Story points and velocity were conceived as rough, team-relative aids to planning. The moment they become managerial targets, Goodhart’s Law applies, in the anthropologist Marilyn Strathern’s widely cited rendering of the economist Charles Goodhart, “when a measure becomes a target, it ceases to be a good measure.” (9) Once velocity is rewarded, a task that was honestly a three becomes a five; estimates inflate; cross-team comparison becomes meaningless; and the number ceases to track the capacity it was meant to describe. This is not dishonesty but the rational optimisation of people who are measured: the same structural effect Goodhart first observed when central banks began targeting the monetary aggregates that had, until then, served as useful indicators (10).

The field has been warned about this by the very figure who taught it to measure. Tom DeMarco, whose 1982 dictum “you can’t control what you can’t measure” shaped a generation of software management, publicly recanted in 2009. Software projects, he concluded, are fundamentally experimental rather than controllable; the metrics orientation he had championed had distracted the discipline from the only question that matters, which is whether the software transforms anything of value. When the author of the control paradigm disavows it, the velocity-driven enterprise is persisting in a method its own architect abandoned (11).

Scale Was Never the Point, and the Enterprise Is All Scale

A recurring theme in the founders’ later commentary is that agility was conceived for small, co-located, empowered teams, not for thousands of people coordinated through a corporate hierarchy. Thomas has remarked that a thousand people working on one thing can never be agile in the original sense, and that an enterprise must itself become agile before any project within it can be. Yet the commercial incentive ran the other way: the largest revenue lay in scaling frameworks, SAFe, LeSS and their relations, sold into precisely the large, hierarchical organisations least suited to the original idea.

Jeffries identified the consequence directly. Large-scale rollouts are typically decided at the top and imposed downward, with most staff required to adopt the new process without proper training and without any grasp of the mindset behind it. What reaches the engineer is therefore the exact inversion of the Manifesto’s first value: not individuals and interactions, but a mandated process and a tool, handed down. Conway’s Law sharpens the point. Melvin Conway’s 1968 observation, that a system’s architecture comes to mirror the communication structure of the organisation that builds it, implies that a rigid, hierarchical, ceremony-bound organisation will tend to produce rigid, brittle, debt-laden software, whatever the agile signage on the wall. The framework scales the ceremony; it cannot scale the judgement, and the architecture records the difference (12).

The Strongest Objection: But the Practices Are Measurably Effective

The most serious objection to this argument comes not from the consultancies but from the best empirical work in the field, and it deserves to be stated at full strength. The DORA programme, Nicole Forsgren, Jez Humble and Gene Kim, drawing on the State of DevOps surveys and synthesised in Accelerate (2018), used rigorous statistical methods across tens of thousands of respondents to show that exactly the technical capabilities this article has called “the craft” (continuous integration, test automation, trunk-based development, loosely coupled architecture) are not soft preferences but measurable drivers of both delivery performance and organisational outcomes (13). If engineering discipline can be shown to pay, the objection runs, then the market will surely select for it, and talk of “de-engineering” is misplaced pessimism.

The objection is correct on its facts, and it is also evidence for the thesis rather than against it. DORA demonstrates that the disciplines being discarded are the ones that work, which makes their abandonment a more serious indictment of the imposed frameworks, not a lesser one. And the programme’s own custodians have been unusually candid about the failure mode. In October 2023 the DORA team issued an explicit warning against using its four metrics to compare teams against one another, the very use to which enterprises most enthusiastically put them. Independent research by the computer scientist Junade Ali, with the polling firm Survation, found that engineers and users alike weighted factors the four key metrics do not capture more heavily than the speed measures themselves. The lesson is consistent with everything above: a sound measure of capability, once elevated into a cross-team target, is degraded by Goodhart’s Law exactly as velocity is. DORA did not licence the metric-fixation enterprises practise in its name; it warned against it. Measuring the right things and targeting them are different acts, and the gap between them is where de-engineering lives.

The Deeper Pattern: Scientific Management Returns in Agile Dress

Step back, and the shape is familiar, because it is older than software. Frederick Winslow Taylor’s Principles of Scientific Management (1911) prescribed three moves that still define industrial management: decompose work into measurable units, standardise the workflow, and (the decisive one) separate the planning of work from its execution, removing judgement from the worker and concentrating it in management (14). The historian Nathan Ensmenger, in The Computer Boys Take Over (2010), shows that this was precisely the programme applied to programming (15). He documents how a craft that the 1950s had celebrated as a “black art” was, from the 1968 NATO Conference on Software Engineering onward, recast as “too artistic” and deliberately rationalised, the very coinage of “software engineering” being, on his account, a management response to a perceived crisis of control over an undisciplined and expensive labour force. The contemporaneous “software factory” movement made the Taylorist ambition explicit: Douglas McIlroy’s 1968 call for mass-produced, catalogue-ordered software components (16), and the industrial software factories later built by Hitachi, Toshiba, NEC and Fujitsu, sought to convert programming from an art form into a “repeatable, scientifically managed” supply chain (17).

The historical irony of enterprise Agile is that it has reconstituted this very paradigm under the banner of a movement founded to escape it. Heavyweight, phase-gated process was the software industry’s first inheritance of Taylor; the Manifesto rebelled against it; and the scaled, ceremony-bound Agile imposed two decades later has quietly restored it. The sprint becomes the stopwatch; the story point becomes the time-and-motion unit; the burndown chart becomes the foreman’s ledger; and “velocity” returns to management precisely the control that “individuals and interactions over processes and tools” was written to dislodge. The mechanism even reproduces Taylor’s signature separation of planning from execution: the top-down rollout decides the process; the engineer merely executes it, which is why the result so often violates the Manifesto’s first value while flying its flag. The position must be stated precisely, because it is easily mistaken for a counsel of no process at all. The argument is not that planning, measurement or coordination are illegitimate; large software plainly requires all three, and the division of labour they imply is, since Adam Smith, the foundation of productive enterprise. It is that when the apparatus of measurement is severed from craft judgement and turned into an instrument of pace, it stops measuring engineering and begins suppressing it. Tom DeMarco’s recantation is, in the end, the admission that the control paradigm mistook a creative, experimental activity for a deterministic one, and that the mistake proved costly exactly where it was most confidently applied.

What “De-engineering” Actually Means

Pulling the threads together, Agile de-engineering is not the failure of an idea but the survival of its packaging after its substance has been removed. It proceeds in a recognisable sequence:

1. Commercialisation. The method becomes a product, certified, scaled and sold by parties other than those who write the software.
2. Ritual capture. The auditable ceremonies are retained; the slow, invisible engineering disciplines (testing, refactoring, integration) are quietly dropped.
3. Metric inversion. Forecasting aids, points, velocity, even DORA’s four keys, are repurposed as targets, and Goodhart’s Law degrades them into instruments of pace.
4. Imposition at scale. Scaling frameworks are mandated top-down across organisations the method was never designed for; staff receive process without mindset.
5. Craft erosion. Technical debt compounds unrepaid, the architecture ossifies in the shape of the hierarchy (Conway), and the standstill Cunningham warned of arrives one reasonable decision at a time.

Each step is locally rational and collectively corrosive. No one decides to de-engineer; it is the emergent result of optimising for what is visible and billable over what is technical and slow. That is not a moral failing of any individual manager. It is, as with every Goodhart effect, a structural property of the incentive architecture, exactly the kind of system-level behaviour that craft judgement exists to counteract and that imposed frameworks systematically remove.

The Recovery Is Not a New Framework

Notably, the founders who diagnosed the problem did not call for an Agile 2.0. Thomas argued explicitly that a sequel manifesto would be a tragic mistake: that the answer is not another noun to be branded and sold, but a return to the underlying way of thinking: deliver small increments of genuinely working software, keep the feedback loops short and, above all, re-establish the technical practices that were the engine of agility in the first place. Jeffries’ prescription is similarly concrete and un-grand: work in small slices, be honest about real delivery capacity, and resist the pressure merely to go faster. DeMarco’s is more radical still: question why so many low-value projects are being run under tight control at all, rather than perfecting the control.

The lesson for the enterprise is therefore uncomfortable. The cure for de-engineering is not a cleaner board, a higher certification tier or a more faithful framework rollout. It is the restoration of engineering culture itself: the craft, the slack and the professional judgement that the original signatories assumed would always sit beneath the word. Strip those out and what remains is ceremony: the daily stand-up performed over an empty foundation, the velocity chart climbing while the architecture rots. The Manifesto’s authors have spent the better part of two decades trying to say so, in their own names and against their own commercial interest. The enterprise has mostly kept the rituals and missed the point. The signal achievement of “doing Agile”, in too many large organisations, has been to de-engineer software development while believing itself to be perfecting it.

The 2008-09 financial crisis taught one cohort that elegant models become dangerous when they graduate from tools into dogma. The history of enterprise Agile teaches the same lesson in an adjacent discipline: a method becomes dangerous not when it is wrong, but when its ceremonies outlive the craft that gave them meaning.

About Polity

This article is part of an ongoing programme of governance and thought-leadership publications developed within the Polity governance model. Polity’s central thesis is that durable outcomes, in markets and in organisations alike, are shaped by governance architecture: the rules, incentives and institutions through which work, value and obligation are formed. The engineering of software is a governance problem in this sense, and the de-engineering described here is what happens when an organisation’s incentive architecture rewards the visible over the durable. Polity builds infrastructure for regulated digital finance, with governance frameworks designed to bridge decentralised systems and institutional-grade compliance requirements.

About Wavect

Wavect GmbH is an Austrian software engineering agency that builds product-led software for startups, scale-ups and enterprises, spanning full-stack development, fractional engineering and product leadership, software quality assurance, and applied work in artificial intelligence, blockchain and zero-knowledge systems. Wavect has provided software development and quality-assurance services to the Polity programme, and co-author Kevin Riedl is a Managing Partner of the firm. More information is available at https://wavect.io.

Disclaimer: This article is published for informational and educational purposes only. It does not constitute professional, legal, financial or engineering-management advice, nor an endorsement of any methodology, product, service or organisation. References to the Agile Manifesto and its signatories, to named researchers, frameworks and companies, and to third-party publications are made solely for analysis and commentary. All third-party sources are cited for reference; their inclusion does not imply endorsement by, or affiliation with, Polity. Co-author Kevin Riedl is a Managing Partner of Wavect GmbH, which provides software development and quality-assurance services to the Polity programme (see “About Wavect” above); this commercial relationship is disclosed in the interest of transparency and does not affect the independence of the analysis. Views expressed are the authors’ own.

References

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).

Press and Web Sources (numbered for fact-verification)

Where the body attributes a specific claim to a named author, the primary source is listed under References above. The items below document the secondary reporting and survey data relied upon, and the points each supports.

• 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