Accelerate: Measure Delivery, Not Lines of Code

Igor explains his choice through his own work: he came from operations, worked at Skype and Microsoft, then grew DevOps as a consultant at Express 42 and wrote the first state of DevOps study in Russia after working through the book's methodology. He lays out the chronology: the state of DevOps research began at Puppet as an internal marketing exercise; in 2012 it invited Gene Kim and Jez Humble to make it public, and the first open report came out in 2013. The four key metrics appeared next; a year later a researcher named Nicole joined, bringing the statistics and the research model, and a year after that they founded DORA and ran the study with Puppet until 2018. Igor calls the book a large report on five years of observation, 2013 through 2017 — five cubes on the slide. After publication the founders sold DORA to Google Cloud, put out the 2019 report by Igor's reckoning and left; there is no 2020 report, but a new team regrouped and keeps re-checking its predecessors' findings.

The book has three parts: the findings, the research methodology and a section on applying it. Alexander has his own short summary of the first two parts — the case study struck him as dull — and Igor agrees the structure is raw: you want the whole model from the appendix first. Alexander still defends the ordering: the big picture is frightening, the cognitive load goes through the roof, so the elephant is eaten piece by piece and the diagram assembled later from familiar parts. The participants go the other way and open with that diagram: leadership, engineering practices and lean product development on the left; software delivery performance with the four metrics and organisational performance as the ultimate goal on the right. Arrows point back, too: predictable delivery throughput frees the product side from project-style predictability. The authors write plainly that these are correlations, not causal links; in the studio they recall the correlation between cheese consumption and deaths from becoming tangled in bedsheets, but note the survey constructs were designed up front, so this is not bare statistics.

The authors set their capability model against maturity models, and Igor does not follow them: Fowler wrote against maturity models, yet nobody hears the call — even fresh movements step on the same old rakes. He proposes looking for balance: tie practices, metrics and outcomes together with a capability model, while still grading the maturity of an individual practice in levels. Alexander explains why managers love levels: five rungs fit in the head better than 125 practices, and in his own company the spread of practices is tracked with a practice map — a wave in which mandatory practices are adopted first and the set widens later. They settle on the line that all models are wrong but some are useful. Then come the metrics the authors attack: lines of code, velocity and utilisation. Alexander has seen bonuses paid for closed story points, and compares utilisation to a doctor booked solid all day: a patient with an emergency injury waits forever.

The four metrics — lead time, deployment frequency, time to restore and change fail rate — split into tempo and stability and, in Igor's words, balance one another: speed one up and you spoil another. None was new: ten deploys a day was discussed at the Velocity conference back in 2009. The participants like the logic behind deployment frequency: you cannot ask a respondent about small batches directly, but you can measure how often the next thin slice comes out from under the knife. For culture the authors do not use Schein's model, which they merely mention, but the typology of the sociologist Westrum: pathological, bureaucratic and generative cultures differ in how information moves through the organisation. In the questionnaire that becomes six characteristics on a Likert scale, and alongside it a ladder of responses to anomalies: suppression, "everything is under control", a local fix, a global fix and the search for root causes. Alexander holds Boeing against that ladder: local fixes until several aircraft had crashed, and a global fix driven more by outside pressure.

The engineering half opens with continuous delivery: quality built in, small changes for fast feedback, automation of repetitive parts and a shared goal instead of local optimisation, with configuration management and infrastructure as code, continuous integration on short-lived branches and continuous testing as foundations. Alexander notes that six years ago this had to be justified; today it is table stakes. On architecture the authors claim the type of application — greenfield or brownfield, in-house or outsourced, mainframe or mobile — has no effect on the key metrics; Igor disagrees from experience, and Alexander adds a statistical caveat: failing to find an effect does not prove its absence, and separating application types was never the study's aim. Then come Conway's law and the reverse manoeuvre, platform and stream-aligned teams, and the chart where the high-performing cluster raises deployments per developer as the team grows while laggards slow down. Both read the security chapter as the information-security team turning into a platform team: checks built into the pipeline and handed to developers as convenient tools.

The second part explains why the surveys can be trusted: primary quantitative research on a Likert scale, though the authors use only the three simplest types of statistical analysis, so they speak of correlation and prediction rather than causation — you cannot manipulate variables in a survey. The performance clusters come from a clustering algorithm and their boundaries drift: the elite cluster was added, dropped in 2022 and later brought back, so comparing a team against the industry is always tied to a year. Igor admits the 2020 Russian study could not reproduce the constructs — DORA had not published its questionnaires — so they took only the key metrics, the cluster analysis and some practices. Alexander explains why tooling data is no rescue: even inside a thousand-person unit you must agree on task types, decomposition, workflow and the commitment point, and between companies comparability is lost. Igor calls the Dutch bank case with its nine thousand engineers weak, while Alexander merely found it uninteresting; the refreshed DORA Core 2024 model also measures performance at team level and studies AI's influence.