What can be calculated and what remains missing

There are four deployments: D1, D2, D3 and D4. Recorded frequency is four per window, or 0.8 per calendar day. D1 contains two commits but counts once. Rollback counts because our definition includes artifact changes; excluding it changes the denominator.

Only D2 causes degradation requiring remediation: one of the four recorded deployments, or 25%, under this exercise's contract. The median first-arrival duration across all four changes is 23 h (6, 22, 24, 28 when sorted); this local measure includes C and must not be called DORA lead time. Among the three successfully deployed changes (A, B and D), durations are 28, 22 and 24 h, with a 24 h median. This small subset does not hide the remaining case: C is still pending functional completion.

The single incident lasts 30 min, from degradation onset to restoration. One point cannot describe a distribution or support robust cross-team comparison. Including detection and response differs from starting the clock only when someone begins fixing the problem.

The ledger does not explain the queue yet. For A, investigate review, tests, approval and deployment waiting between Monday and Tuesday. PR-open-to-close is not commit-to-production: it can conceal waiting after merge. Keep each timestamp attached to the event it represents rather than combining convenient values from different tools.

Interventions need plausible mechanisms

Suppose investigation finds a large batch awaiting repetitive approval. One hypothesis separates small changes and automates the evidence approval uses while retaining risk controls. Establish whether that stage checks compatibility, security or an external obligation before changing it.

Smaller batches may ease diagnosis and rollback, but require genuinely independent changes. Artificially separated commits that must deploy together cannot provide the same capability. Automating a click without evidence might merely remove a protection.

Assign ownership and a reversal condition. Observe comparable changes across multiple windows while retaining criteria. If lead time falls while failures or support worsen, investigate transferred costs. Research informs the hypothesis; the team must still learn its behavior in this system.

Technical capability and culture must interact

Reliable tests, frequent integration and automated deployment can shorten decision-to-feedback distance. Tests failing without real defects teach people to ignore results. A fast pipeline cannot help if nobody trusts what it reports.

Reporting trouble must be feasible too. Incidents reducing individual performance scores may lead to incomplete records. A culture allowing bad news and following through on improvements supports useful metrics. Operations and security collaboration belongs during development as well as at final approval.

Architecture and organization influence waiting. A small change requiring five coordinated teams cannot become independent merely through a separate repository. Examine contracts and dependencies before choosing automation as the sole answer to every delay.

Incentives can corrupt measures

Higher frequency alone establishes neither better products nor stability. Remediation deployments can increase the count, as D3 does here. Deploying useless changes to meet a target can improve dashboard appearance while consuming capacity.

Failure-rate denominators need care. Making rollbacks invisible breaks comparisons. Recording more incidents after improving observation can worsen an indicator by improving information rather than reflecting newly deteriorated service.

Do not rank individual developers using these measures. People depend on shared review, testing, approval and operations. Discuss a service and its flow over time with context about change size, risk and user outcomes.

Criticism and limits

The strength is making practices debatable beyond personal preference. The risk is converting association into a universal command or research groups into permanent identities. A team cannot become mature by copying a frequency band, nor lose its value because it works within constraints.

Indicators approximate a broader reality. They cannot independently describe accessibility, security, product usefulness or exhaustion. Local gains may conceal work transferred elsewhere. Review these consequences even when they resist reduction to one number.

Research concepts and definitions evolved after 2018. This review retains the historical setting. Building a current measurement system requires checking the chosen reference and documenting definition changes instead of silently joining incompatible time series.

Intended readers and reasons to wait

I recommend it to developers, operations, managers and leaders participating in production delivery. Familiarity with version control, tests, deployment and incidents helps. Statistical mastery is unnecessary to begin, but give methods and limits attention instead of reading only striking comparisons.

If you are learning Git or making a first deployment, practice those foundations before measuring an organization. During an active incident, stabilize the service; the book can inform subsequent investigation. Expect neither a ready-made tool nor a dashboard recipe.

Peopleware broadens human-condition discussion. Release It! connects protection and operation. Team Topologies examines dependencies between teams. Accelerate provides research for relating these capabilities to delivery performance.

A reading plan and verdict

Read measures and methods against a familiar service. Write a collection contract and reconstruct a small window of commits, deployments and incidents. Expose pending work and exceptions without immediately classifying the team.

Choose a bottleneck, propose an intervention and specify observations contradicting your hypothesis. Compare results with stability and user consequences. One observed change supplies an investigation case; conclusions about the organization need more evidence.

I recommend Accelerate for replacing vague pressure with better questions about delivery systems. You have used it well when you can explain change flow, measurement limits and why an intervention deserves testing. The objective is learning to deliver better while owning the consequences.