Accelerate The Science of DevOps

1. 1Establish the two architectural characteristics as your test target: teams must be able to do most testing without an integrated environment, and deploy or release their application independently of the services it depends upon. These are the measurable properties, not abstract 'decoupling.'
2. 2Audit whether your teams can make large-scale design changes to their own systems without permission from anyone outside the team, and without depending on other teams to change their systems or creating significant work for them. Each 'no' is a coupling defect to fix.
3. 3Bring integration targets in-house where feasible. Low performers were more likely to be building or integrating against custom software developed by another company (e.g., an outsourcing partner); reducing external custom-software dependencies removes a barrier to independent testing and deployment.
4. 4Match organizational structure to the architecture ('an organizational structure to match'). Encapsulate so that a delivery team owns a service end-to-end and can complete work without communicating and coordinating with people outside the team.
5. 5Verify service boundaries actually permit independent test and deploy. Many so-called service-oriented or microservices architectures do not, so stress-test each service by attempting to deploy it on demand regardless of the services it depends upon, and to test it without an integrated environment.
6. 6Redirect the freed communication bandwidth deliberately. The goal is not to stop teams collaborating; it is to stop fine-grained implementation-level decision-making from overwhelming bandwidth, so reserve that bandwidth for higher-level shared goals and how to achieve them.
7. 7Instrument scaling with deploys per day per developer among those who deploy at least once per day. Track this metric as you add engineers to confirm you are scaling productivity linearly or better rather than losing individual productivity to coordination overhead.
8. 8Confirm deployability under real conditions: perform deployments during normal business hours with negligible downtime as evidence the architecture is genuinely loosely coupled.

In the 2017 analysis the authors measured whether teams could make large-scale system changes without outside permission, deploy on demand regardless of dependencies, and test without an integrated environment. This bundle of properties — a loosely coupled, well-encapsulated architecture — turned out to be the biggest single contributor to continuous delivery, larger even than test and deployment automation. To show it enables scaling, they calculated deploys per day per developer for respondents deploying at least once per day. As the number of developers grew, low performers deployed with decreasing frequency, medium performers held constant, and high performers deployed with significantly increasing frequency. This directly contradicts the orthodox view that individual developer productivity must fall as teams grow due to communication and integration overhead. The difference was explained by teams needing little cross-team communication to get work done — architecture and teams both loosely coupled.

• If a team cannot deploy or release its application independently of the services it depends on, then treat that as a coupling defect blocking continuous delivery, not a process problem.
• If most testing requires an integrated environment, then the architecture is not yet loosely coupled — fix testability before expecting delivery gains.
• If a team needs permission from outside the team or creates significant work for other teams to make a large design change, then the boundaries are wrong regardless of what the architecture is labeled.
• If you are integrating against custom software developed by another company, then prioritize bringing that capability in-house, since this is associated with low performance.
• If adding developers is lowering deploys per day per developer, then you have coordination overhead from tight coupling — do not add more people until the architecture and org structure are decoupled.

• Calling an architecture 'microservices' or 'service-oriented' while services still cannot be tested and deployed independently. The tell: deploying one service requires an integrated environment or coordinated release of others.
• Optimizing system type instead of coupling. The tell: teams debate greenfield vs. mainframe vs. system-of-record when the data shows no correlation between system type and performance for medium and high performers — coupling is what matters.
• Interpreting 'loosely coupled' as teams working in isolation. The tell: cross-team collaboration on shared goals disappears; the intent is only to remove fine-grained implementation-level coordination, not all communication.
• Fixing architecture without matching organizational structure. The tell: services are technically separable but a change still requires sign-off or work from another team, so decision-making bandwidth stays overwhelmed.
• Assuming productivity must degrade at scale and accepting it. The tell: deploys per developer per day flatten or fall as headcount grows, and leaders treat this as inevitable rather than as evidence of tight coupling.

• ▸Team/service name: the delivery team and the service it owns.
• ▸Independent deploy: can you deploy/release on demand regardless of dependent services? (yes/no)
• ▸Independent test: can you do most testing without an integrated environment? (yes/no)
• ▸Design autonomy: can you make large-scale design changes without outside permission? (yes/no)
• ▸Dependency load: do your changes require other teams to change their systems or create significant work for them? (yes/no)
• ▸Communication need: can you complete work without coordinating with people outside the team? (yes/no)
• ▸External custom software: are you building or integrating against custom software from another company? (yes/no + in-house plan)
• ▸Business-hours deploy: can you deploy during normal hours with negligible downtime? (yes/no)
• ▸Scaling metric: current deploys per day per developer, and trend as team grows (up/flat/down).

1. 1Default to practitioner choice: unless there is a documented good reason not to, let the team building the infrastructure and applications choose their own tools. Ownership of the choice drives investment in the work.
2. 2Tie tool choice to the outcome you care about: because empowered teams predict continuous delivery, and CD predicts delivery performance, treat tool selection as an architecture capability, not a procurement formality.
3. 3Reverse the direction of standardization pressure: if the organization must standardize, require that procurement and finance act in the interests of the teams — not the teams bending to procurement's convenience.
4. 4Pair tool freedom with a loosely coupled architecture so teams can test and deploy on demand without orchestrating with other services; tool choice only pays off when teams can act independently.
5. 5Instrument job satisfaction as a signal: ask whether employees feel they have the tools and resources to do their job well, since that is a major contributor to satisfaction and a leading indicator that tool choice is working.
6. 6Create sharing loops — demo days, forums, lunch-and-learns, lightning talks — so tool decisions made by one team spread by demonstrated value rather than by mandate.
7. 7Guard the freedom from the top: senior leaders must demonstrate commitment in actions, extract reality by making teams comfortable surfacing risks, and treat failure as inquiry rather than blame.

Courtney Kissler describes Nordstrom's shift from an IT organization optimized for cost to one optimized for speed. Early on the traps were top-down: a mandate to adopt Agile treated as one-size-fits-all, no focus on the right measurements, and leadership behavior that didn't change. The turn came from moving to outcome-based team structures, limiting the blast radius by starting with one to two teams instead of boiling the ocean, and using data to drive decisions — including treating NFRs, technical debt, and operational work as one backlog rather than separate ones. As teams gained ownership over how they worked, the teams practicing these techniques scored highest on eNPS across the technology organization. The pattern held across mainframe, packaged-software, and product teams, showing empowerment is methodology-agnostic. The lesson: empowerment plus senior support produces both better results and happier teams.

• If a team is closest to the work and no good reason exists to restrict them, then let them choose their own tools — no one knows better than practitioners what they need.
• If the organization insists on standardizing tools, then require procurement and finance to justify the choice in the interests of teams, not the reverse.
• If teams cannot test and deploy on demand without waiting on other teams, then fix the coupling in the architecture before blaming or changing the tools.
• If job-satisfaction or eNPS scores lag, then check whether teams actually have the tools and resources they judge necessary — that is a named contributor to satisfaction.
• If you are starting a transformation, then limit the blast radius to one or two teams and use data to expand, rather than a top-down mandate across everything at once.

• Enforcing an approved-tools list chosen for other stakeholders (procurement convenience, cost optimization). Tell: teams describe fighting the tooling instead of using it, and satisfaction scores drop.
• Top-down mandate treated as one-size-fits-all. Tell: the same rollout is imposed on mainframe, packaged, and product teams identically, and adoption stalls.
• Granting tool freedom while leaving a tightly coupled architecture in place. Tell: teams still need orchestration with other services to deploy, so the freedom produces no delivery gains.
• Dismissing empowered teams' results as flukes — 'of course it worked for the mobile app team, they're a unicorn.' Tell: skeptics use exceptionalism to block spreading the practice.
• Leaders who only show up at failures and don't make it safe to surface risk. Tell: teams stop reporting problems, so leadership never sees reality and the freedom erodes.

• ▸Team & scope: which team and what products/services it owns end to end
• ▸Current tool constraints: which tools are mandated and by whom
• ▸Reason for each constraint: the documented 'good reason' — or blank if none
• ▸Whose interest it serves: team, procurement, finance, or other stakeholder
• ▸Independence check: can the team test/deploy on demand without other teams? (Y/N)
• ▸Satisfaction signal: do team members feel they have the tools/resources to do the job? (score)
• ▸Sharing mechanism: where this team demos tool decisions to others (demo day/forum/none)
• ▸Blast radius: is this change piloted on 1-2 teams or org-wide?
• ▸Leadership action: what senior leaders are doing (not saying) to protect the choice

1. 1Instrument the four Lean management components from Figure 7.1: WIP limits, visualizing work, monitoring, and change approval processes. Start by measuring where you are on each before changing anything—the Nordstrom account calls out 'not focusing on measurement (or the right things to measure)' as a common trap.
2. 2Set explicit work-in-progress limits per team and per work stage. Cap the number of active items so that queues become visible and idle work forces prioritization rather than accumulation.
3. 3Consolidate into a single backlog. Following Kissler's account, do not maintain separate backlogs for features, technical debt, and operational work; treat NFRs as features and technical-debt reduction as stability work, so everything competes in one prioritized queue.
4. 4Build visual displays of quality and status that both practitioners and leaders read from the same source. The transformation chapter references a leadership obeya (Figure 16.1) and a stand-up/catchball rhythm (Figure 16.3)—make status, quality, and WIP visible on shared boards.
5. 5Use monitoring data to drive daily business decisions, not just alerting. Wire proactive notification (Chapter 13) so teams act on signals; Kissler names 'using data to drive actions and decisions' as a load-bearing practice.
6. 6Make change approval lightweight. Move away from heavyweight external approval boards toward peer review and automated checks so approval does not become the bottleneck the chapter groups under Lean management.
7. 7Limit the blast radius when rolling this out: start with one to two teams rather than 'boiling the ocean,' then expand as you learn.
8. 8Treat this as continuous improvement, not a program. The research shows the best keep getting better year over year; run experiments, adjust, and never declare the transformation 'done.'

Courtney Kissler's Nordstrom journey, beginning summer 2011, is the concrete case the book supplies. The organization made a strategic decision to focus on digital as the growth engine, and her 'aha' moment was shifting the IT organization from being optimized for cost to being optimized for speed. She applied Lean management directly: understanding cycle time through a value stream map, limiting the blast radius by starting with one to two teams instead of boiling the ocean, using data to drive actions and decisions, and collapsing separate feature, technical-debt, and operational backlogs into a single backlog because 'NFRs are features and reducing technical debt improves stability of the product.' She notes this worked across mainframe environments, traditional packaged-software delivery teams, and product teams—evidence the practices are methodology agnostic. Her stated failures are as instructive as her wins: a top-down mandate to adopt Agile, treating it as one size fits all, and running the effort as a program instead of building a learning organization. The outcome she reports from experience: adopting this guidance makes the organization higher performing, but it took discipline, persistence, and continuous experimentation.

• If a team has multiple separate backlogs (features, tech debt, ops), then merge them into one—NFRs and debt reduction are features that compete for the same capacity.
• If you are starting a transformation, then limit the blast radius to one or two teams; do not attempt an org-wide mandate.
• If change approval requires an external board on the critical path, then replace it with lightweight peer review and automated checks.
• If you cannot see current WIP and quality status on a shared visual display, then you cannot make daily Lean decisions—build the board before optimizing flow.
• If leadership behavior is not changing alongside the practices, then the transformation will stall; leaders must supply consistent time, actions, and resources.

• Top-down Agile mandate treated as one size fits all. Tell: leaders announce a framework rollout without team-level adaptation—Kissler names this as a trap she stepped in.
• Treating the transformation as a program with an end date instead of a learning organization. Tell: there is a 'done' milestone or a project close-out rather than ongoing experimentation.
• Not measuring, or measuring the wrong things. Tell: teams report activity (velocity, deploys) but cannot state cycle time or value stream flow.
• Fragmented backlogs. Tell: separate queues for features, technical debt, and operational work, causing NFRs and stability work to lose to feature pressure.
• Executives overestimating progress versus practitioners. The Forrester report notes executives are especially prone to overestimating DevOps maturity; the tell is a gap between leadership's self-assessment and what the people doing the work report.

• ▸WIP limit per stage: set the max active items each workflow stage can hold
• ▸Single-backlog check: list any separate backlogs still in use and the merge date
• ▸Visual display location: where status, quality, and WIP are shown and who reads it daily
• ▸Monitoring-to-decision link: which daily decision each key metric drives
• ▸Change approval path: current approver(s) and the lightweight replacement (peer review/automated check)
• ▸Blast radius: the one or two teams piloting first and their expansion criteria
• ▸Cycle time / value stream: current measured cycle time and the mapped bottleneck
• ▸Leadership commitment: specific time, actions, and resources leaders are providing
• ▸Experiment log: current hypothesis, change made, and next adjustment date

1. 1Decompose planned work into small batches: break features into increments small enough to move from commit to production in about an hour, the lead time the passages attribute to high performers, rather than months.
2. 2Make the flow of work visible across the entire value stream: use the leadership Obeya (Figure 16.1, a 360-degree panorama) so the state of work is visible to team, management, and leadership in one place.
3. 3Establish a stand-up and catchball rhythm (Figure 16.3) so information moves both up and down—teams surface blockers, leaders push back objectives and constraints iteratively rather than issuing a top-down mandate.
4. 4Build customer feedback into the loop: because high performers update software many times a day, use each release to explore the market and respond to events, then feed what users do back into the next small batch.
5. 5Enable team experimentation: give teams authority to try changes and evolve structure—model on ING's Agile organizational model (Figure 16.2), which has no fixed structure and constantly evolves.
6. 6Pair product-development practices with continuous delivery so speed does not cost stability: the passages show updates fail at a fraction of the rate and are usually fixed within the hour, so treat stability as the enabler of speed, not its trade-off.
7. 7Run this as continuous improvement, not a one-time rollout: software delivery is an exercise in continuous improvement, and the best keep getting better year over year while non-improvers fall behind.

Courtney Kissler describes her journey starting at Nordstrom in summer 2011, where the strategic decision was to make digital the growth engine. Up to that point the IT organization was optimized for cost; her stated 'aha' moment, shared in her DevOps Enterprise Summit 2014 presentation, was the shift to optimizing for speed. She admits stepping into common traps—one being a top-down mandate to adopt Agile, treating it as one size fits all. That trap is the opposite of lean product-development practice: instead of mandating a method from above, the lean approach works in small batches, makes flow visible, gathers customer feedback, and lets teams experiment their way to what fits. Her regret—wishing she'd had the information in this book back then—shows the cost of skipping these practices. The lesson is that optimizing for speed only works when paired with the visible, feedback-driven, experimental practices rather than a decree.

• If a work item can't move from commit to production in roughly an hour, then it is too large—split it into a smaller batch.
• If leaders are issuing a top-down 'adopt Agile' mandate, then stop and replace it with a stand-up and catchball rhythm so objectives and feedback flow both ways.
• If speed improvements are threatening stability, then treat stability as the prerequisite—the research refutes the bimodal choice, so fix the delivery pipeline rather than slowing down.
• If the flow of work is not visible across the value stream, then build an Obeya-style shared view before adding more work.
• If a team's structure is fixed and unable to evolve, then grant experimentation authority—model ING's constantly evolving structure rather than a permanent org chart.

• Top-down mandate to adopt Agile as one-size-fits-all (Kissler's named trap); the tell is a method imposed by leadership without team experimentation or feedback loops.
• Optimizing solely for cost so long lead times and buggy output persist; the tell is slow lead times, complicated features that add expense, and frustrated users.
• Treating speed and stability as a trade-off (the bimodal IT myth); the tell is teams deliberately slowing releases to protect uptime instead of improving the pipeline.
• Confusing IT delivery (commit to production) with the whole product-development process; the tell, per Fowler, is optimizing only the delivery journey while ignoring upstream feedback and experimentation.
• Running practices as a one-time transformation rather than continuous improvement; the tell is a completed rollout with no steady improvement program, causing the team to fall further behind.

• ▸Work item: name the increment being delivered.
• ▸Batch size / lead time: estimated commit-to-production time (target ~1 hour).
• ▸Value-stream visibility: where this item's status is shown (e.g., Obeya panorama).
• ▸Customer feedback source: how user response to this release is captured.
• ▸Feedback-to-next-batch: what the last release's data changed in this one.
• ▸Experiment: the hypothesis the team is testing this cycle.
• ▸Stand-up/catchball note: objective pushed down and blocker pushed up.
• ▸Stability check: last release's failure rate and time-to-restore.
• ▸Improvement action: one change to make delivery faster or more stable next cycle.

1. 1Measure culture before you try to change it: administer the Likert-type survey items (Figure 3.1) that place your team on Westrum's pathological-bureaucratic-generative continuum, capturing perceptions of information flow, cooperation, and how failures are handled.
2. 2Read the position, not just the score: pathological (power-oriented, information hoarded, failures punished), bureaucratic (rule-oriented, messengers ignored), generative (performance-oriented, information actively sought, failures lead to inquiry). Locate your team honestly.
3. 3Do not treat culture as a mystical prerequisite — treat it as an outcome. The book's finding is 'you can act your way to a better culture by implementing these practices.' Pick from the 24 concrete capabilities (continuous delivery, architecture, product/process, lean management, cultural) to shift culture.
4. 4Model the leadership behavior that generative culture requires: as Kissler puts it, 'honor and extract reality' — show up with genuine curiosity, not only when there is a failure, so the team feels safe surfacing risks.
5. 5Establish that failure leads to inquiry, not blame. Make this an explicit, repeated leadership practice so information flows freely and messengers are not shot.
6. 6Provide consistent senior support in actions, not words — time, resources, and demonstrated commitment to building a learning organization, never a finished program.
7. 7Re-measure over time. Software delivery is continuous improvement; track whether information flow, cooperation, and failure-handling perceptions move toward generative, and pair with delivery-performance metrics.
8. 8Corroborate rather than assume: note Google's work on team cultures independently supports the importance of a Westrum-generative culture, so use it to convince skeptics.

Courtney Kissler's journey at Nordstrom (starting summer 2011) is the concrete case. The IT organization had been optimized for cost, and her 'aha' moment was the shift to optimizing for speed. She hit the common traps — a top-down Agile mandate, treating it as one-size-fits-all, not measuring the right things, leadership behavior not changing, and running it as a program instead of a never-finished learning organization. She corrected course by limiting the blast radius (one to two teams instead of boiling the ocean), using data to drive decisions, and treating all work as a single backlog. On culture specifically, she modeled 'honoring and extracting reality': if her team didn't feel safe sharing risks she would never know reality, and if she only showed up at failures she was failing as a leader — so she built trust by demonstrating that failure leads to inquiry. The result: teams practicing these techniques had the highest eNPS scores across the technology organization.

• If your team hides risks or only surfaces problems after failure, then you are pathological/bureaucratic — start by making failure lead to inquiry, not punishment.
• If leaders only appear during failures, then trust is absent; require leaders to show genuine, ongoing curiosity to reach generative.
• If someone insists culture must change before practices can improve, then reverse it — implement the 24 capabilities to drive the culture change ('act your way to a better culture').
• If you're tempted to mandate transformation top-down across everything, then instead limit the blast radius to one or two teams and use data to drive the next move.
• If senior leadership offers words but not time, actions, and resources, then improvement will stall — secure demonstrated commitment first.

• Top-down Agile mandate treated as one-size-fits-all — tell: adoption is announced org-wide but teams report no change in daily reality.
• Leadership behavior never actually changes — tell: leaders talk about learning but only engage when something breaks.
• Treating transformation as a finite program — tell: a 'done' date exists; the correct framing is a learning organization that is never done.
• Not measuring, or measuring the wrong things — tell: no baseline of culture or delivery performance, so you can't tell if perceptions are moving.
• Assuming culture is 'mystical magic' rather than an outcome of concrete practices — tell: endless culture workshops with no capability implementation and no improvement.

• ▸Current placement: pathological / bureaucratic / generative — mark where survey perceptions land
• ▸Information flow: how freely is information sought and shared? (evidence)
• ▸Cooperation: do teams work across boundaries or protect turf? (evidence)
• ▸Failure handling: are failures punished, ignored, or met with inquiry? (evidence)
• ▸Leader behavior check: do I show curiosity always or only at failures? (yes/no + fix)
• ▸Selected capabilities: which of the 24 (continuous delivery, architecture, product/process, lean mgmt, cultural) will we implement to shift culture
• ▸Blast radius: which 1-2 teams pilot this
• ▸Senior support secured: time / actions / resources committed (specifics)
• ▸Re-measure date and metric: when we re-survey and which delivery metric we pair with it

1. 1Score yourself against the five Rafferty and Griffin dimensions before acting: Vision (can you state where the organization should be in five years?), Inspirational communication, Intellectual stimulation, Supportive leadership, Personal recognition. Rate each honestly, then pick your two weakest to work on.
2. 2Convert support from words to actions. Courtney Kissler's tell: 'leadership behavior not changing' was one of the common traps. Demonstrate commitment to a learning organization through visible behavior, not mandates.
3. 3Practice honoring and extracting reality: create conditions where teams share risks with you. If your team doesn't feel comfortable sharing risks, you will never know reality. Show up out of genuine curiosity, not only when there is a failure.
4. 4Build trust by demonstrating that failure leads to inquiry, not blame (the Westrum model). This is the mechanism that makes risk-sharing safe.
5. 5Avoid the top-down mandate. Kissler stepped in the trap of 'trying a top-down mandate to adopt Agile, thinking it was one size fits all.' Instead limit the blast radius: start with one to two teams rather than boiling the ocean.
6. 6Use transformational leadership to enable technical and Lean capabilities (per Figure 11.1, Impacts of Transformational Leadership on Technical and Lean Capabilities) — the leader's job is to make the practices in this book adoptable, not to do the work personally.
7. 7Provide air cover and change incentives. Use your authority and budget to make large-scale changes and to change the incentives of entire groups — development, QA, operations, information security.
8. 8Treat the transformation as never-done. Kissler's trap was 'treating the transformation like a program instead of creating a learning organization (never done).' Sustain vision, communication, and recognition continuously.

Courtney Kissler's Nordstrom journey (starting summer 2011) is the passage's worked example. Nordstrom made a strategic decision to focus on digital as the growth engine, and Kissler's 'aha' moment was shifting the IT organization from optimizing for cost to optimizing for speed. She applied transformational leadership by focusing on people, moving to outcome-based team structures, understanding cycle time through value stream mapping, and using data to drive decisions. Rather than a top-down Agile mandate, she limited the blast radius to one or two teams. She modeled specific behaviors — honoring and extracting reality, being genuinely curious rather than showing up only at failures, and demonstrating that failure leads to inquiry (Westrum). The measurable result: when they began measuring eNPS, the teams practicing these techniques had the highest scores throughout the technology organization. Her summary: it takes discipline, persistence, transformational leadership, and a focus on people, and the team ended up both higher performing and happier.

• If your team won't surface risks to you, then you don't yet have reality — fix trust before you push new practices.
• If you only engage when something breaks, then you are failing as a senior leader — schedule curiosity, not just incident reviews.
• If you're about to issue a one-size-fits-all top-down mandate, then stop and pick one or two teams to start instead.
• If you're choosing a leadership model to develop, then favor transformational over servant leadership here: you want followers identifying with organizational objectives, not only individual development.
• If work is fragmented into separate backlogs (features, tech debt, ops), then consolidate to a single backlog — NFRs are features and reducing tech debt improves stability.

• Support in words only. Tell: leaders announce the transformation but their own behavior never changes.
• Blame-on-failure culture. Tell: teams hide risks; you keep being 'surprised' by problems you should have known about.
• Boiling the ocean. Tell: a simultaneous org-wide rollout with no team small enough to learn from safely.
• Confusing transformational with servant leadership. Tell: you optimize for individual follower development but never get followers to identify with and support organizational objectives.
• Running it as a finite program. Tell: a 'transformation complete' milestone, a declared end date, and no ongoing learning mechanism.

• ▸Vision statement: write where the organization should be in five years in one sentence.
• ▸Inspirational communication: note one recent message you delivered that motivated even amid uncertainty.
• ▸Intellectual stimulation: list one problem you reframed so your team thought about it in a new way.
• ▸Supportive leadership: record one action showing care for a follower's personal needs this week.
• ▸Personal recognition: name a specific person whose quality improvement you praised, and when.
• ▸Reality signal: rate 1-5 how safely your team shares risks with you, and cite evidence.
• ▸Blast radius: name the one or two teams you are starting with, not the whole org.
• ▸Learning-org proof: describe one behavior showing this is ongoing, not a program with an end date.
• ▸Outcome metric: track a people measure (e.g., eNPS) alongside delivery performance.

1. 1Define your four metrics precisely before measuring anything. Use the book's operational definitions: lead time is the time from code commit to code in a deployable state; deployment frequency is how often you push to production; time to restore service is how long to recover from a degradation; change fail rate is the percentage of changes that require remediation (hotfix, rollback, patch).
2. 2Separate the two dimensions the construct measures: tempo (lead time, deployment frequency) and stability (time to restore, change fail rate). Track both — the research shows high performers do well on both simultaneously, disproving the speed-versus-stability tradeoff.
3. 3Collect the data via a survey worded so respondents self-classify into ranges (e.g. lead time less than one hour vs. one week to one month), rather than pulling raw system data — the passages explain system data across thousands of teams is impractical and definitions drift between teams.
4. 4Guard against definitional confusion. The passages warn that 'lead time' and 'cycle time' get used interchangeably though they measure different things; force one shared definition across every team before aggregating.
5. 5Classify each team into high, medium, or low performer using the four measures together, then compare year over year against the tempo and stability trend baselines (Figures 2.2 and 2.3).
6. 6Tie the classification to outcomes: check whether your high performers are also exceeding organizational and noncommercial goals, since the research shows software delivery performance predicts (not just correlates with) business performance.
7. 7Improve the score by acting on the upstream capabilities — the passages state 'you can act your way to a better culture by implementing these practices,' pointing to the 24 concrete capabilities (continuous delivery, lean management, architecture) rather than chasing the metrics directly.

The authors' own program is the worked case: starting with the 2014 State of DevOps Report and continuing through 2017, Forsgren, Humble, and Kim surveyed thousands of respondents from thousands of organizations, gathering data in a four-to-six-week window each year. Rather than pulling raw system data (impossible at that scale — legal clearances and inconsistent measures alone would defeat it), they used survey questions letting respondents place themselves in performance bands. They analyzed lead time, deployment frequency, time to restore service, and change fail rate, then classified respondents as high, medium, or low performers (Tables 2.2 and 2.3 for 2016 and 2017). This produced the finding Martin Fowler initially wanted to 'toss into the rubbish bin' until Forsgren walked him through the methodology: high performers were twice as likely to exceed objectives in quantity of goods and services, operating efficiency, customer satisfaction, quality, and mission goals (Figure 2.4). The relationship was established as predictive, not merely correlational.

• If a team is fast on tempo but weak on stability (or vice versa), then it is not a high performer — the construct requires strength on both dimensions at once.
• If two teams report the same metric under different names or the same name for different measures, then stop and standardize definitions before aggregating, or the analysis is corrupted at the source.
• If you need data from many teams in a short window, then use a validated survey with banded self-classification rather than attempting system-data extraction.
• If software delivery is strategic to your business, then bring the capability in-house — the passages cite delivery performance as a strong argument against outsourcing strategic software.
• If you want to raise the classification, then invest in the underlying capabilities (continuous delivery, lean management, small-batch experimentation), because these drive the metrics rather than the reverse.

• Treating speed and stability as a tradeoff. The tell: teams deliberately slowing releases to 'protect' stability — the research shows high performers achieve both together.
• Confusing lead time with cycle time. The tell: two teams reporting identical numbers under different labels, or identical labels covering different measurement windows (commit-to-deployable vs. dev-start-to-deployable).
• Chasing the four metrics as targets while ignoring the capabilities that produce them. The tell: dashboards improve cosmetically but no underlying practice changed.
• Assuming correlation only. The tell: dismissing the findings as 'bogus science' (Fowler's first instinct) without examining the inferential-prediction methodology behind the arrows.
• Measuring only commercial teams. The tell: no data on noncommercial or mission goals, missing that high performers were twice as likely to exceed objectives on validated noncommercial scales too.

• ▸Lead time: time from code commit to code in deployable state (state your band)
• ▸Deployment frequency: how often you deploy to production
• ▸Time to restore service: how long to recover from a service degradation
• ▸Change fail rate: percent of changes requiring hotfix/rollback/patch
• ▸Tempo score: combined read of lead time + deployment frequency
• ▸Stability score: combined read of time to restore + change fail rate
• ▸Classification: high / medium / low (requires strength on BOTH tempo and stability)
• ▸Definition check: confirm every team uses the same wording for each metric (yes/no)
• ▸Outcome link: which organizational or mission goals is this team exceeding?

1. 1Measure software delivery performance first using the four keys the research validates: deployment tempo (frequency and lead time) and stability (change fail rate and time to restore). These are the predictive inputs to organizational performance.
2. 2Split your outcome measures into two families: commercial goals (profitability, productivity, market share, ROI) and noncommercial goals (quantity of goods and services, operating efficiency, customer satisfaction, quality of products/services, achieving mission goals). Track both, because the research shows delivery performance predicts both.
3. 3Use the validated Cavalluzzo and Ittner (2004) scale for noncommercial goals rather than inventing your own survey items, so your measures stay comparable and defensible.
4. 4Frame the measure as 'likelihood of exceeding objectives' relative to peers, not raw dollars — the research reports high performers are twice as likely to exceed goals, and this framing is robust to economic cycles.
5. 5Establish predictive, not just correlational, links: treat delivery capability as an upstream driver you can improve, then watch whether org-level outcomes move in the direction the research predicts.
6. 6Benchmark against the performance clusters (high/medium/low) and re-measure yearly, because the high-performing cluster is pulling away — last year's 'good enough' loses ground.
7. 7Attack the underlying obstacles — rearchitecture, process improvement, automation — rather than pushing 'work harder,' which raises tempo temporarily while stability collapses.
8. 8Improve the 24 concrete capabilities (technical, management, product, cultural) as the levers; organizational performance is the downstream result, not something you tune directly.

The 2014 State of DevOps Report claimed high IT performance 'correlates with strong business performance, helping to boost productivity, profitability, and market share.' Martin Fowler's instinct was to bin it as pseudo-science until he learned the analysis behind it. The mechanism: the research measured software delivery performance (tempo and stability), then linked it to commercial outcomes, finding high-performing organizations were consistently twice as likely to exceed ROI-related goals as low performers. In 2017 the authors extended this to noncommercial goals using the Cavalluzzo and Ittner (2004) scale, and again found high performers twice as likely to exceed objectives in quantity of goods and services, operating efficiency, customer satisfaction, product quality, and mission goals. The key move that made this credible was going beyond correlation to inferential prediction — showing delivery capability predicts organizational performance, not merely coincides with it. This is why the passages assert software delivery capability 'can in fact provide a competitive advantage to your business,' whether or not you are chasing profit.

• If your organization is non-profit or mission-driven, then still measure delivery performance — the research shows it predicts mission-goal achievement, not just revenue.
• If tempo is rising while change fail rate is also rising, then you are pushing 'work harder' without fixing rearchitecture, process, or automation — stop and address the underlying obstacles.
• If you want a robust outcome metric across economic conditions, then use the goal-exceedance framing tied to ROI, which the research found robust to economic cycles.
• If a report claims a business impact, then demand the reasoning and method behind it (as Fowler did) before trusting it — correlation claims without disclosed analysis are a red flag.
• If your improvement stalled while peers advanced, then re-benchmark: the high-performing cluster pulls away yearly, so a static program is effectively regressing.

• Measuring only commercial outcomes (profit, revenue) and ignoring operating efficiency, customer satisfaction, and mission goals — the tell: you cannot explain your value in a non-profit or shared-services context.
• Confusing correlation with causation and treating org performance as a side effect rather than a predictable result of delivery capability — the tell: you invest in outcome dashboards but never touch the upstream capabilities.
• Chasing tempo alone ('work harder!') so stability degrades and technical debt accumulates — the tell: change fail rate climbs and rework crowds out new work, as seen in medium/low performers.
• Inventing bespoke survey items instead of using validated scales — the tell: your results can't be compared year over year or against benchmarks, undermining credibility.
• Assuming last year's performance level is sufficient — the tell: you feel stable while the high-performing cluster accelerates past you and the industry redefines 'good.'

• ▸Delivery tempo (deploy frequency + lead time): record current measured values.
• ▸Delivery stability (change fail rate + time to restore): record current measured values.
• ▸Commercial goals tracked (profitability, productivity, market share, ROI): note likelihood of exceeding vs. peers.
• ▸Noncommercial goals tracked (quantity, operating efficiency, customer satisfaction, quality, mission): use Cavalluzzo & Ittner scale.
• ▸Performance cluster this period (high/medium/low): state where you sit and last period's position.
• ▸Underlying obstacles being addressed (rearchitecture / process / automation): list active workstreams, not 'work harder.'
• ▸Predicted vs. observed outcome movement: did org outcomes shift as delivery capability improved?
• ▸Re-measure date: schedule the next benchmark to catch the cluster pulling away.

1. 1Measure burnout directly rather than inferring it: use a Likert-type survey (Strongly Disagree to Strongly Agree) covering the three symptom clusters — feeling exhausted, cynical, or ineffective; little or no sense of accomplishment; and work negatively affecting other aspects of life. Take the numerical value of each response and calculate the mean across questions.
2. 2Trace the upstream driver first: because deployment pain can lead to burnout if left unchecked, audit your deployment process for fear, manual steps, and irreproducibility before treating burnout as a standalone morale problem.
3. 3Attack deployment pain with the continuous delivery capabilities that reduce it: design systems deployable into multiple environments, ensure production state is reproducible from version control in an automated fashion, and build intelligence into the app/platform so deployment approaches a single command.
4. 4Check for pathological or bureaucratic culture, since burnout is correlated with pathological cultures and unproductive, wasteful work. Score your Westrum construct (trust, collaboration, mission emphasis, level playing field) to locate where information hides and fear festers.
5. 5Never repurpose your burnout or delivery metrics as instruments of control — in pathological/bureaucratic cultures measurement is used for control and people hide information, and 'whenever there is fear, you get the wrong numbers.'
6. 6Fix the conditions that cause burnout, not the individuals: foster a supportive work environment, ensure work is meaningful, and build work identity (a factor likely to decrease burnout).
7. 7Adopt Lean management and Lean product management practices upstream — work in small batches that deliver measurable outcomes quickly, since these practices measurably affect workforce outcomes including burnout and deployment anxiety.
8. 8Re-measure on a cadence and treat it as iteration: revalidate results over time, benchmark teams against the wider organization and industry, and watch for backsliding as well as improvement.

The authors' own multi-year research is the worked case. In year two (2015) they moved beyond asking whether technical and Lean management practices only affect delivery speed, and explicitly asked: 'Do technical practices and Lean management practices impact aspects of work that affect our workforce — such as anxiety associated with code deployments and burnout?' Their hypotheses were supported. In year three (2016) they added questions on employee Net Promoter Score and work identity, naming work identity as 'a factor that is likely to decrease burnout.' Across the largest survey of its kind, they showed continuous delivery practices have a measurable impact on burnout and deployment pain — and, notably, that change management boards are negatively correlated with tempo and stability, meaning a control mechanism many organizations add actually degrades the outcomes it claims to protect. The lesson: burnout is a measurable outcome downstream of concrete, changeable practices, not an unavoidable cost of the work.

• If deployment is painful, manual, or irreproducible, then treat it as an active burnout driver and automate/reduce it before addressing morale directly.
• If the culture is pathological or bureaucratic, then do not deploy metrics as control instruments — fear produces wrong numbers and hidden information, so fix culture first.
• If you are proposing a change management board (or similar control gate) to 'protect' delivery, then reconsider: they are negatively correlated with tempo and stability and add friction without benefit.
• If employees report low sense of accomplishment or work bleeding into life, then intervene at the organizational level — supportive environment, meaningful work, work identity — rather than expecting individuals to cope.
• If you can move survey questions from yes/no to Likert scales, then do so — the nuance lets you detect burnout trends and revalidate over time instead of seeing only black-and-white snapshots.

• Treating burnout as an individual weakness. Tell: interventions target the person (resilience training, 'take a break') while deployment pain and pathological culture remain untouched.
• Ignoring deployment pain as a source. Tell: teams dread releases and describe helplessness around deploys, yet leadership frames burnout as unrelated to the delivery process.
• Using measurement as control. Tell: numbers look suspiciously good, people hide information that challenges rules, and fear is present — 'whenever there is fear, you get the wrong numbers.'
• Adding control gates like change management boards to reduce risk. Tell: tempo and stability drop, delivery slows, and stress rises even though the gate was meant to help.
• Measuring only speed and organizational performance while omitting workforce outcomes. Tell: dashboards track lead time and deploy frequency but never track exhaustion, cynicism, ineffectiveness, or work identity, so burnout accrues invisibly until turnover and sick time appear.

• ▸Exhaustion score (mean of Likert responses on feeling exhausted, 1-7)
• ▸Cynicism score (mean of Likert responses on cynical/detached feelings, 1-7)
• ▸Ineffectiveness score (mean of Likert responses on low sense of accomplishment, 1-7)
• ▸Work-life spillover score (Likert: work negatively affecting other aspects of life, 1-7)
• ▸Deployment pain rating (manual steps, fear, irreproducibility — high/medium/low)
• ▸Westrum culture score (mean of trust/collaboration/mission/level-playing-field questions, 1-7)
• ▸Metric-use check (is any measure being used for control? yes/no + fear present?)
• ▸Work identity / meaningfulness rating (do employees find the work meaningful? high/med/low)
• ▸Chosen intervention & re-measure date (supportive environment / meaningful work / reduce deploy pain — and when you will revalidate)

1. 1Measure deployment pain directly: ask your team three survey questions — are deployments feared, are they disruptive to your work, or are they easy and pain-free. Follow up by asking what specific things cause the pain. This is the straightforward measure the research used.
2. 2Check for the out-of-hours tell. If deployments have to be performed outside normal business hours, treat that as a signal of architectural problems that need addressing, not as a scheduling preference to accommodate.
3. 3Trace pain to its root: most deployment problems come from a complex, brittle deployment process. Look for software not written with deployability in mind — the symptom is complex, orchestrated deployments needed because the software expects its environment and dependencies set up in a very particular way and tolerates no deviation, while giving administrators little useful information on what is failing and why.
4. 4Attack pain with the technical capabilities the research links to lower pain: comprehensive test and deployment automation, continuous integration including trunk-based development, shift left on security, effective test data management, loosely coupled architecture, teams that can work independently, and version control of everything required to reproduce production environments.
5. 5Prioritize deployability and testability as architectural properties. Because loosely coupled architecture lets teams deploy independently, invest here so deployments stop requiring all-hands orchestration and zero-downtime automated deployment becomes achievable.
6. 6Watch burnout alongside pain — the two are correlated in the data. Treat rising deployment pain as an early warning of attrition, illness, and lost productivity, and use effective leadership and Lean management (both negatively correlated with burnout) as counterweights.
7. 7Re-measure after each change. Because improving key technical capabilities demonstrably reduces pain, track whether pain scores drop as automation, CI, and version control coverage rise — this closes the loop between practice and human outcome.

Microsoft engineering is cited as a team feeling the benefits of continuous delivery. Thiago Almeida, a Senior Software Development Engineer Lead at Microsoft, drives cloud computing, open source, and DevOps practices. The relevant pattern from the research: where deployments are most painful, you find the poorest software delivery performance, organizational performance, and culture — so a team living this pain typically has manual, orchestrated releases run after hours by a separate ops group. Applying the research remedy, a team implements deployment automation, continuous integration with trunk-based development, and version control of everything needed to reproduce the production environment. As those capabilities mature, deployments move inside business hours and become routine rather than feared. The measured result is reduced fear, disruption, and anxiety — the same technical practices that improve speed and stability also lower the stress of pushing code to production.

• If deployments must happen outside business hours, then treat it as evidence of an architectural problem and prioritize decoupling and zero-downtime automation over better scheduling.
• If deployments require complex, orchestrated sequences because software assumes an exact environment, then the root cause is poor deployability — fix the software's tolerance and diagnostics, not just the runbook.
• If pain scores stay high after you add tooling, then check whether version control covers everything required to reproduce the production environment; missing configuration or scripts keeps deployments brittle.
• If deployment pain is rising, then check burnout too — they are correlated, and effective leadership plus Lean management are the levers shown to reduce burnout.
• If you cannot deploy independently of other teams, then invest in loosely coupled architecture so releases stop needing all-hands coordination.

• Assuming who deploys matters: teams believe moving deployments to ops (or dev) fixes pain, but the research found whether operations or development performs deployments does not predict performance. The tell: reorganizing ownership without changing the deployment process.
• Treating a change approval board as the safety mechanism: the research found CAB implementation does not predict performance. The tell: adding approval gates while pain and lead time stay flat.
• Scheduling around the pain instead of removing it: accepting midnight and weekend deploys as normal. The tell: a standing after-hours deployment window that nobody questions.
• Automating a brittle process without fixing deployability: wrapping a fragile, environment-sensitive release in scripts. The tell: automation that still fails cryptically and gives administrators little information on what is wrong or why.
• Chasing delivery speed by brute force at the expense of the team: hitting deploy targets while pain and burnout climb. The tell: performance metrics improve while eNPS and attrition worsen.

• ▸Feared? — rate how much the team dreads the next deployment (1-7)
• ▸Disruptive? — rate how much deployments disrupt other work (1-7)
• ▸Pain-free? — rate how easy/routine deployments feel (1-7)
• ▸Specific pain causes — list the concrete things causing the pain
• ▸Out-of-hours flag — do deployments require work outside business hours? (yes/no)
• ▸Deployability symptoms — note any orchestration/exact-environment dependence and poor failure diagnostics
• ▸Capability coverage — check which are in place: test automation, deployment automation, CI/trunk-based, shift-left security, test data mgmt, loosely coupled architecture, independent team work, full version control of production-reproducing artifacts
• ▸Independence — can this team deploy without coordinating other teams? (yes/no)
• ▸Burnout check — note current burnout signals to correlate with pain trend

1. 1Measure loyalty with eNPS: ask the single question 'How likely is it that you would recommend our company as a great place to work?' on a 0-10 scale. Classify 9-10 as promoters, and calculate the net score. Track this over time as your baseline for loyalty.
2. 2Measure identity as a distinct construct from loyalty: use Likert-type items capturing whether employees identify with the organization's values and goals, are willing to exert effort on its behalf, and feel proud to be part of it. Identity is the factor the research links to reduced burnout.
3. 3Measure job satisfaction with items covering meaningful work, having adequate tools and resources to do the job, and having skills matched to work. Treat 'adequate tools and resources' as an actionable lever, not a soft perk.
4. 4Check for values alignment on two axes: employee-to-organization, and organization's stated values versus lived values. Audit whether values on placards match everyday behavior, because it is the lived values that count.
5. 5Invest in the technical and Lean management practices the research shows drive identity and job satisfaction (version control, deployment automation, continuous integration, trunk-based development, test automation, Lean product management). These reduce deployment pain and burnout while improving satisfaction.
6. 6Close the feedback loop by re-surveying periodically and reading the constructs as predictive: satisfaction and identity feed loyalty, reduce burnout, and predict organizational outcomes (profitability, productivity, market share).

The Accelerate research team introduced eNPS in year three (2016) to measure company loyalty and added a work-identity construct as a factor likely to decrease burnout. They found employees in high-performing organizations were 2.2 times more likely to recommend their organization as a great place to work, a signal correlated with better business outcomes (Azzarello et al. 2012). Separately, they found that technical and Lean management practices contributed to reductions in both burnout and deployment pain (Figure 9.1), and that these same practices had measurable impacts on identity (Figure 10.1) and job satisfaction (Figure 10.2). The mechanism they surfaced: where stated and lived values align, employees thrive; where there is a values mismatch, burnout becomes a concern. So a manager reading these figures would not treat satisfaction as an isolated HR metric but as an outcome driven by the delivery capabilities their teams work in every day.

• If stated values and lived, everyday behaviors diverge, then expect burnout regardless of the placards—fix the behavior, not the poster.
• If eNPS is low but you want organizational-performance gains, then treat improving technical and Lean practices as a lever, since they predict both satisfaction and loyalty.
• If employees report inadequate tools and resources, then prioritize that gap before engagement initiatives, because it is a measurable component of job satisfaction.
• If you are running a transformation, then measure identity separately from loyalty—identity is the factor tied to reduced burnout, so tracking only eNPS misses it.
• If you can only run a survey once, then still use validated Likert-type constructs rather than ad hoc questions, so the results discriminate meaningfully.

• Treating eNPS as the whole picture: it measures loyalty, but you also need distinct identity and job-satisfaction constructs. Tell: your survey has one recommendation question and nothing on values, effort, or tools.
• Publishing values without living them: the values-mismatch drives burnout. Tell: employees can quote the placard but describe daily behavior that contradicts it.
• Chasing engagement perks while ignoring deployment pain and inadequate tooling: the research ties satisfaction to technical/Lean practices. Tell: on-call staff paged after hours by broken systems while morale programs run in parallel.
• Confusing correlation with intent by cherry-picking a single team's anecdote: the research uses statistical, predictive analysis across 23,000+ responses. Tell: decisions justified by 'our best team feels great' rather than measured constructs.
• Measuring once and never again: software delivery is continuous improvement and those who fail to improve fall behind. Tell: no year-over-year trend, no re-survey after interventions.

• ▸eNPS score: enter net promoter result from the 0-10 'recommend as a great place to work' question
• ▸Promoter %: percentage scoring 9-10
• ▸Identity rating: Likert agreement that employees identify with org values/goals and will exert effort
• ▸Job satisfaction rating: Likert agreement on meaningful work + skills-to-work match
• ▸Tools & resources adequacy: Likert agreement that people have what they need to do the job
• ▸Values alignment check: note any gap between stated (placard) and lived values
• ▸Deployment pain / burnout signal: log after-hours paging and broken-system disruption
• ▸Technical/Lean practice gaps: list missing capabilities (version control, CI, test/deploy automation, trunk-based, Lean product mgmt)
• ▸Re-measure date: next survey date to establish year-over-year trend

1. 1Put everything required to build, deploy, and run the software in version control: application code, configuration, scripts, and infrastructure definitions (version control is the foundational CD capability listed in Chapter 4).
2. 2Establish continuous integration so every commit triggers an automated build and test run, giving developers fast feedback on whether their change kept the software deployable.
3. 3Adopt trunk-based development: keep branches short-lived and merge to trunk frequently rather than maintaining long-lived feature branches that accumulate integration risk.
4. 4Automate testing with reliable, comprehensive suites and manage test data so tests are repeatable and independent — this is what lets you trust that a green build is genuinely deployable.
5. 5Automate deployment so promoting a build to any environment (including production) is a push-button, low-risk operation rather than a manual, error-prone event.
6. 6Shift left on security by building infosec review and controls into the delivery lifecycle rather than bolting them on at the end (Chapter 6).
7. 7Treat all work as one backlog: fold NFRs, technical debt reduction, and operational work into the feature backlog so deployability is maintained continuously, not deferred (Kissler's single-backlog principle).
8. 8Measure and improve continuously — track tempo and stability outcomes year over year, because the research shows the best keep getting better and non-improvers fall behind.

Courtney Kissler's team at Nordstrom, starting in 2011, shifted from an IT organization optimized for cost to one optimized for speed. Rather than mandating Agile top-down or trying to transform everything at once, they limited the blast radius by starting with one or two teams instead of boiling the ocean. They understood their cycle time by mapping the value stream and used data to drive actions and decisions. A concrete practice change: they stopped maintaining separate backlogs for features, technical debt, and operational work, and instead kept a single backlog — because NFRs are features and reducing technical debt improves the stability of the product. The transformation was not treated as a finite program but as building a learning organization (never done), and it required experimentation, discipline, transformational leadership, and a focus on people. Kissler reports this worked across mainframe environments, traditional packaged software delivery teams, and product teams alike.

• If a change cannot be reproduced from version control, then it is not yet under continuous delivery — put its config, scripts, and infrastructure in version control first.
• If deployment to production requires manual steps or a special event, then automate it before adding more features, because manual work is where stability breaks down.
• If you maintain separate backlogs for features, technical debt, and operational work, then merge them — treat NFRs as features and debt reduction as stability work.
• If you are starting a transformation, then limit the blast radius to one or two teams and use their data rather than mandating change org-wide.
• If leadership behavior is not changing and support (time, actions, resources) is inconsistent, then expect the effort to stall regardless of tooling.

• Top-down mandate to adopt Agile as one-size-fits-all — the tell: teams comply on paper but cycle time and stability don't move.
• Treating the transformation as a finite program with an end date — the tell: momentum dies once the 'program' is declared complete instead of becoming a permanent learning practice.
• Not measuring, or measuring the wrong things — the tell: decisions are driven by opinion rather than value-stream and delivery-performance data.
• Separate backlogs for features vs. technical debt vs. ops — the tell: debt and NFRs never get prioritized, so the software drifts out of a deployable state.
• Long-lived feature branches instead of trunk-based development — the tell: painful, high-risk merges and integration surprises late in the cycle.
• Boiling the ocean by transforming all teams simultaneously — the tell: the blast radius of failures is org-wide and no clean learning signal emerges.

• ▸Version control scope: list what is / is not yet under version control (code, config, scripts, infra).
• ▸Continuous integration status: does every commit trigger an automated build+test? (yes/no + gaps)
• ▸Branching model: trunk-based or long-lived branches? Max branch age observed.
• ▸Test automation coverage: which tests are automated, and how is test data managed?
• ▸Deployment automation: is production deploy push-button? List remaining manual steps.
• ▸Security integration point: where in the lifecycle does infosec review occur (shift-left or end-stage)?
• ▸Backlog structure: single unified backlog or separate feature/debt/ops backlogs?
• ▸Blast radius: which one or two teams pilot first, and what's the value-stream cycle-time baseline?
• ▸Leadership support evidence: specific time, actions, and resources committed to improvement.

1. 1Put four artifact classes under version control, not just one: application code, system configuration, application configuration, and scripts for automating build and configuration. Treat any artifact missing from VC as a gap.
2. 2Prioritize getting system and application configuration into version control, since the research shows these correlate more strongly with software delivery performance than application code does.
3. 3Make version control the single source of truth: it should be possible to provision environments and build, test, and deploy software in a fully automated fashion purely from information stored in version control.
4. 4Wire every change to environments or software through an automated process from version control—manual approvals are allowed, but once approved, all changes apply automatically rather than by hand.
5. 5Trigger a build process on each change (commit) that runs unit tests; if any part fails, developers fix it immediately rather than deferring.
6. 6Run automated unit and acceptance tests against every commit to version control to give developers fast feedback, and ensure developers can run all tests on their own workstations.
7. 7Keep branches short-lived (less than one day's work) and integrate to trunk/master frequently, so version control reflects a continuously integrated state rather than divergent long-lived branches.

To measure whether teams actually practice comprehensive version control, the authors ask respondents to rate agreement on a Likert scale with four statements: our application code is in a version control system; our system configurations are in a version control system; our application configurations are in a version control system; and our scripts for automating build and configuration are in a version control system. Taken together, these four items form the version control construct, which statistical analysis showed has a strong positive impact on software delivery performance. The most interesting finding was that keeping system and application configuration in version control was more highly correlated with performance than keeping application code in version control. This challenges the common misconception that configuration is a secondary concern to application code in configuration management. A team that version-controls only its code, then, is leaving the higher-leverage artifact classes uncovered. The practical test is whether you can rebuild an environment and deploy purely from what is stored in version control.

• If you can't provision an environment and build, test, and deploy purely from version control, then your configuration management is not yet comprehensive—find and commit the missing artifacts.
• If a change is approved, then apply it automatically from version control; reserve manual steps for the approval decision, not the execution.
• If you have limited effort to invest, then prioritize putting system and application configuration under version control before optimizing code workflows, because configuration correlates more strongly with delivery performance.
• If a branch has lived longer than one day's work, then integrate it to trunk/master—long-lived branches undermine continuous integration.
• If a build or its unit tests fail on a commit, then developers fix it immediately rather than continuing to add work.

• Version-controlling only application code and treating configuration as secondary—the tell is that you cannot rebuild an environment without undocumented manual tweaks or tribal knowledge.
• Applying approved environment or software changes by hand instead of through an automated process from version control—the tell is drift between environments and 'works on my machine' incidents.
• Keeping configuration in wikis, spreadsheets, or ad hoc files outside version control—the tell is that no single source of truth exists and rollbacks require guesswork.
• Long-lived feature branches accumulating days or weeks of work—the tell is significant time and rework spent integrating branches back to trunk.
• Treating version control as a storage bucket disconnected from automation—the tell is that commits don't trigger a build with unit tests, so failures are discovered late instead of on each change.

• ▸Application code in VC? — Yes/No; name the repo and note any code living outside it.
• ▸System configuration in VC? — Yes/No; list OS, network, and infra config not yet committed.
• ▸Application configuration in VC? — Yes/No; list app settings/env config still managed manually.
• ▸Build and configuration scripts in VC? — Yes/No; identify any provisioning or deploy scripts kept locally.
• ▸Can you provision + build + test + deploy purely from VC? — Yes/No; list the manual steps that break full automation.
• ▸Are approved changes applied automatically from VC? — Yes/No; note where hands-on execution still occurs.
• ▸Does each commit trigger a build with unit tests? — Yes/No; record current feedback time to developers.
• ▸Max branch lifetime before integration — record actual duration vs. the under-one-day target.
• ▸Highest-priority gap to close first — pick the configuration item most likely to raise delivery performance.

1. 1Classify test automation as one of the eight continuous delivery capabilities (Chapter 4) and treat it as a driver of software delivery performance, not a separate QA phase bolted on at the end.
2. 2Have developers, not a separate QA team, create and maintain the automated tests; ownership by the people writing the code is what keeps tests reliable enough that passing runs indicate releasable code.
3. 3Run the tests continuously throughout development rather than in a late-stage gate, so failures surface at commit time and feed the commit-to-production pipeline.
4. 4Pair test automation with test data management (also Chapter 4) so tests have controlled, adequate data and their reliability isn't undermined by inconsistent inputs.
5. 5Measure the effect on the four delivery outcomes — lead time, deployment frequency, time to restore service, change fail rate (Table 2.3) — to confirm the practice is actually improving tempo and stability, not just accumulating test count.
6. 6Use passing tests as your release signal: the state you're aiming for is committed-to-mainline to running-in-production in about an hour, which requires trusting the automated suite instead of manual verification.
7. 7Fold this into a steady program of continuous improvement — what was state of the art three years ago is no longer good enough, so keep revalidating that the suite still gives fast, trustworthy signal.

Courtney Kissler's journey at Nordstrom, starting summer 2011, shows the context test automation belongs in. Nordstrom had optimized IT for cost and made a strategic decision to treat digital as the growth engine, which forced a shift to optimizing for speed. She describes hitting common traps: a top-down mandate to adopt Agile, treating it as one size fits all, and not focusing on measurement or the right things to measure. Test automation is one of the concrete capabilities that supports the speed-with-stability she was reaching for. The book's central finding — refuting bimodal IT — is that speed depends on stability, so automated tests that make passing runs mean releasable code let you deploy many times a day without a rise in failures. Fowler's benchmark makes the payoff concrete: high performers get code from committed-to-mainline to running-in-production in about an hour, and their failures are usually fixed within the hour, a level of confidence only continuous automated testing sustains.

• If tests are owned and maintained by a separate QA group rather than developers, then reclassify ownership — the passages tie the capability to developer-created, developer-maintained tests.
• If a passing test run does not give you confidence to release, then the suite is not yet functioning as a delivery capability and needs reliability work before you add more tests.
• If you're pushing tempo ("work harder!") without investing in automation, rearchitecture, and process improvement, then expect to lose ground on stability — the pattern seen in 2017 low performers.
• If someone proposes a change approval board to improve quality, then push back with evidence: change management boards are negatively correlated with both tempo and stability.
• If you cannot measure lead time, deployment frequency, time to restore, and change fail rate, then you cannot prove test automation is improving anything — build measurement first.

• Bolting automation on as a late-stage gate instead of running tests continuously; the tell is failures discovered days after commit rather than at commit time.
• Handing test creation to a separate QA team; the tell is developers who don't trust or read the suite and route around it.
• Chasing test count while reliability stays low; the tell is a green build that no one believes, so manual verification still gates releases.
• Ignoring test data management; the tell is flaky tests that fail intermittently due to data, eroding trust in the whole suite.
• Using the delivery metrics as a control mechanism in a pathological or bureaucratic culture; the tell is people hiding information that challenges the numbers instead of improving.

• ▸Test ownership: name who creates and maintains the tests — must be the developers
• ▸Continuity: state where in the pipeline tests run (commit / integration / late gate)
• ▸Release signal: does a passing run give confidence to release? yes/no + evidence
• ▸Test data management: how test data is provisioned and kept consistent
• ▸Lead time: current commit-to-production time vs. ~1 hour target
• ▸Deployment frequency: how often you deploy today
• ▸Time to restore: how long to recover from a failure vs. within-the-hour target
• ▸Change fail rate: percentage of changes that cause a failure
• ▸Improvement cadence: how you revalidate the suite still gives fast, trustworthy signal

1. 1Put application code, system configuration, application configuration, and build/configuration scripts under version control first — trunk-based development has no meaning without a single mainline to integrate into.
2. 2Set the branch-lifetime ceiling to less than one day's work. If a piece of work cannot be integrated into trunk/master within a day, decompose it into smaller batches until it can.
3. 3Wire every commit to trigger a build that runs unit tests automatically (continuous integration). Trunk-based development and CI are the same discipline observed from two angles.
4. 4Enforce the fix-immediately rule: when any part of the build/test process fails, developers stop and fix it before continuing new work, so trunk stays releasable.
5. 5Eliminate code freezes and stabilization periods. Instead of stabilizing before a release, run automated unit and acceptance tests against every commit and continuous exploratory testing against the latest CI builds so trunk is always near-shippable.
6. 6Track the number of active branches and their age as a health metric — 'few active branches, very short lifetimes, no code freeze' is the measurable definition you're steering toward.
7. 7Have developers run the full automated test suite on their own workstations to triage and fix defects before merging, keeping bad changes out of trunk.
8. 8Require collaboration across developers, testers, UX, product, and operations throughout — daily integration only works when the whole delivery chain participates, not just coders.

The 2016 research year (year three) specifically tested whether trunk-based development contributes to better software delivery, alongside security integration and test data management. The hypothesis was supported: using trunk-based development as opposed to long-lived feature branches came out as one of the capabilities with a strong positive impact on software delivery performance when taken together with version control, test automation, deployment automation, and CI. The contrast the passages draw is concrete: teams 'used to developing features on branches for days or even weeks' pay in integration time and rework, while high-performing teams 'keep branches short-lived (less than one day's work) and integrate them into trunk/master frequently.' Martin Fowler's foreword shows the payoff downstream — effective organizations get code from 'committed to mainline' to 'running in production' in about an hour and deploy many times a day, whereas lesser organizations take months. Critically, this speed does not cost stability: those same organizations fail at a fraction of the rate of peers and usually recover within the hour, refuting the bimodal notion that you choose between speed and stability. Trunk-based development is a mechanism that produces both because integration is continuous rather than a big-bang event.

• If a branch cannot be merged to trunk within one day, then split the work into smaller batches rather than letting the branch live longer.
• If you find yourself scheduling a code freeze or stabilization period before release, then you are not doing trunk-based development — replace the freeze with continuous automated testing against every commit.
• If a commit breaks the build or tests, then developers fix it immediately before taking on new work.
• If the number of active branches is climbing or their average age exceeds a day, then treat it as a delivery-performance risk and intervene before merging becomes a rework event.
• If any team declares work 'done' before all relevant automated tests are written and passing, then it is not done — block the merge to trunk.

• Long-lived feature branches disguised as trunk-based — the tell is branches living for days or weeks, producing the 'significant time and rework' at integration the passages warn about.
• Keeping a code freeze or stabilization phase while claiming CD — the tell is release being an 'enormous, big-bang event' rather than a routine, on-demand activity.
• Doing trunk-based development without CI wiring, so commits don't trigger automated builds and tests — the tell is broken code sitting in trunk undetected until a release.
• Testing only after a feature is 'dev complete' instead of continuously against every commit — the tell is defects surfacing late and trunk drifting out of a releasable state.
• Treating this as a developer-only practice — the tell is testers, UX, product, and operations not collaborating throughout, so integration succeeds technically but delivery still stalls.

• ▸Mainline location: name the single trunk/master everyone integrates into
• ▸Version control coverage: confirm app code, system config, app config, and build/config scripts are all versioned (yes/no each)
• ▸Max branch lifetime: state your ceiling (target: < 1 day of work)
• ▸Active branch count: record current number of live branches and oldest branch age
• ▸CI trigger: describe what each commit automatically runs (build + unit tests?)
• ▸Broken-build rule: state your fix-immediately policy and who owns it
• ▸Freeze status: list any remaining code freeze or stabilization periods to eliminate
• ▸Test-before-done gate: define which automated tests must pass before a merge
• ▸Cross-role participation: name the dev, test, UX, product, and ops people engaged in the delivery flow

1. 1Bring infosec personnel into design reviews and demos, not just a pre-release gate — schedule their feedback at each step of the delivery lifecycle from design through demos.
2. 2Build a set of preapproved libraries and security-tested components that developers draw from by default, so secure choices are the path of least resistance rather than a review bottleneck.
3. 3Have infosec help write and maintain test automation, so security checks run against every commit alongside unit and acceptance tests rather than in a separate downstream phase.
4. 4Fold security work into the single team backlog — treat security remediation and NFRs as features, not a parallel backlog, so they get prioritized and stabilized with everything else.
5. 5Design the security integration so it does not slow the development process: integrate concerns into daily work, keep feedback fast, and avoid handing off to a separate approval queue.
6. 6Track quality measures the research used — defects, rework, and security remediation time — to confirm the integration is helping delivery rather than adding drag.
7. 7Start narrow: apply infosec-in-process with one or two teams (limit the blast radius) before extending across the organization.

The research directly tested the question 'Does the integration of security into software development and delivery help the process or slow it down?' by measuring shift left on security as a construct in the 2016 iteration, using Likert-type questions and statistical analysis. The finding: high-performing teams were more likely to incorporate information security into the delivery process, with infosec personnel providing feedback at every step from design through demos to helping with test automation. They did this without slowing development — security concerns were integrated into the daily work of teams. Contrary to the assumption that security review is a brake, integrating these practices actually contributed to software delivery performance. The passage also notes preapproved libraries as part of the pattern: security is built in by default rather than inspected in at the end. This is why the authors treat 'shift left on security' as a continuous delivery capability, not a compliance afterthought.

• If a security review is your only infosec touchpoint and it sits at release time, then move that feedback upstream into design and demos — a downstream-only gate is the anti-pattern.
• If developers must build components from scratch and get them reviewed individually, then create preapproved libraries so secure defaults are available without a review cycle.
• If integrating security is measurably slowing delivery, then you have implemented it as a handoff/gate — redesign it as feedback in daily work, since the research shows correct integration contributes to performance.
• If security remediation lives in its own backlog separate from features, then merge it — work is work; NFRs are features and remediation improves product stability.
• If you are extending shift-left broadly at once, then stop and pilot with one or two teams first to limit blast radius before scaling.

• Treating security as a final approval phase — the tell: infosec only appears at release, remediation piles up, and deployments stall waiting on sign-off.
• Assuming security integration must slow delivery — the tell: teams resist involving infosec because they expect a brake, when correct integration actually raises delivery performance.
• Keeping a separate security/technical-debt backlog — the tell: security items never get prioritized against features and quietly accumulate as unaddressed rework.
• No preapproved libraries — the tell: every team reinvents secure components and each needs individual review, creating a bottleneck that pushes security back to the end.
• Not measuring — the tell: you can't say whether shift-left is helping because you track no security remediation time, defect, or rework data to confirm the effect.

• ▸Design-stage infosec feedback: name who reviews and at which design point
• ▸Demo-stage infosec involvement: how infosec participates in demos each iteration
• ▸Preapproved library set: list the security-vetted components developers default to
• ▸Security in test automation: which automated security checks run on every commit
• ▸Single backlog placement: confirm security/remediation items sit in the one team backlog as features/NFRs
• ▸Speed guardrail: how you verify integration is not adding handoff delay
• ▸Pilot scope: which one or two teams start before scaling
• ▸Quality metrics tracked: defects, rework, and security remediation time baselines