Accelerate — Flashcards
Q: What are the four DORA metrics for software delivery performance?
A: 1. Deployment Frequency — how often code is deployed to production
2. Lead Time for Changes — time from code commit to running in production
3. Mean Time to Restore (MTTR) — how long to restore service after an incident
4. Change Failure Rate — % of changes that cause degraded service or require remediation
Q: What did 2017 research find about high performers vs. low performers?
A: High performers had:
- 46x more frequent code deployments
- 440x faster lead time (commit to deploy)
- 170x faster MTTR
- 5x lower change failure rate
Q: Why are maturity models inferior to capability models?
A: Maturity models: (1) imply an endpoint (“arrived”), (2) are linear/lock-step for all teams, (3) aren’t outcome-based, (4) are static and don’t adapt to the changing landscape. Capability models: continuous improvement, multidimensional/customizable, tied to business outcomes, dynamically adaptive.
Q: What three factors make previous software performance metrics flawed?
A: Lines of code (rewards bloat), velocity (relative, easily gamed, not comparable across teams), utilization (at 100%, lead time approaches infinity per queue theory — no slack for unplanned work).
Q: What are the three Westrum organizational culture types?
A: 1. Pathological (power-oriented) — low cooperation, messengers shot, failure → scapegoating, novelty crushed
2. Bureaucratic (rule-oriented) — modest cooperation, messengers neglected, failure → justice, novelty problematic
3. Generative (performance-oriented) — high cooperation, messengers trained, failure → inquiry, novelty implemented
Q: What does Westrum’s typology predict in technology organizations?
A: The culture type predicts how information flows, which predicts: software delivery performance, organizational performance, and job satisfaction. Generative culture = better performance on all measures.
Q: How do you change organizational culture according to Forsgren et al.?
A: By changing behavior first, not mindset. Implement Lean management and continuous delivery practices — culture improves as a consequence. (John Shook: “The way to change culture is not to first change how people think, but instead to start by changing how people behave.”)
Q: What are the five key principles of Continuous Delivery?
A: 1. Build quality in (detect issues early)
2. Work in small batches (measurable outcomes quickly)
3. Computers perform repetitive tasks; people solve problems (automate rote work)
4. Relentlessly pursue continuous improvement (everyone, daily)
5. Everyone is responsible (system-level outcomes, not departmental silos)
Q: What are the three foundations needed to implement Continuous Delivery?
A: 1. Comprehensive configuration management — everything needed to build/test/deploy in VCS, fully automated provisioning
2. Continuous integration (CI) — short-lived branches (<1 day), integrated frequently, failures fixed immediately
3. Continuous testing — automated tests on every commit, developers run all tests locally, exploratory testing continuously
Q: What does trunk-based development look like for high performers?
A: Fewer than 3 active branches at any time, branches live less than one day before merging to trunk, no “code freeze” or stabilization periods. Works across team size, org size, and industry.
Q: What makes test automation effective per the research?
A: Tests are reliable (passing means releasable; failures mean real defects), developer-maintained (not outsourced QA — makes code more testable and developers care more), and run frequently (every commit triggers a build + fast tests; daily comprehensive suite).
Q: What are the two critical architectural characteristics for high performance?
A: 1. Testability — can do most testing without an integrated environment
2. Deployability — can deploy/release independently of other services
Q: What is the Inverse Conway Maneuver?
A: Organizations should evolve their team and organizational structure to achieve the desired architecture. Conway’s Law: organizations produce designs that mirror their communication structures. The inverse: design teams to mirror the architecture you want.
Q: How does architecture affect scaling? What did the deploys-per-developer metric show?
A: As developer count increases: low performers deploy with decreasing frequency per developer, medium performers maintain constant frequency, high performers deploy at increasing frequency. A loosely coupled architecture enables linear or better scaling.
Q: What did research find about Change Advisory Boards (CABs)?
A: External approval processes are negatively correlated with lead time, deployment frequency, and MTTR — and have no correlation with change fail rate or stability. CABs are worse than having no change approval process. Peer review (pair programming or code review) + deployment pipeline is the recommendation.
Q: How can regulated industries achieve segregation of duties without CABs?
A: 1. Someone not involved in authoring reviews and approves changes (recorded in VCS/pipeline)
2. Changes only applied to production via fully automated deployment pipeline (complete audit trail in VCS)
Q: What are the four Lean product development capabilities?
A: 1. Small batches — features completable in < 1 week, MVPs for products
2. Flow visibility — understand work flow from business to customer
3. Customer feedback — actively seek and incorporate feedback
4. Team experimentation — authority to update specs without outside approval
Q: What is the virtuous cycle between software delivery performance and Lean product management?
A: Better delivery performance → enables working in small batches and user research → leads to better products. Better Lean product management → improves delivery performance. The two reinforce each other in a self-reinforcing loop.
Q: What are the three root causes of deployment pain?
A: 1. Software not written with deployability in mind (rigid environment expectations)
2. Manual changes to production (errors, configuration drift)
3. Multiple handoffs between siloed teams (DBAs, network admins, sysadmins, QA, etc.)
Q: What are Maslach’s six organizational risk factors for burnout?
A: 1. Work overload (demands exceed limits)
2. Lack of control (can’t influence decisions affecting your job)
3. Insufficient rewards (financial, institutional, or social)
4. Breakdown of community (unsupportive environment)
5. Absence of fairness (unfair decision-making)
6. Value conflicts (mismatch between org and individual values)
Q: What five organizational factors are most correlated with burnout in the research?
A: 1. Pathological organizational culture
2. Deployment pain
3. Ineffective leaders (not limiting WIP, not removing roadblocks)
4. Lack of organizational investment in DevOps (training, resources, time)
5. Poor organizational performance (no space for creative work)
Q: What did the eNPS research find about high performers?
A: Employees in high-performing organizations were 2.2x more likely to recommend their organization as a great place to work, and 1.8x more likely to recommend their team.
Q: What are the five dimensions of Transformational Leadership?
A: 1. Vision — clear understanding of where the organization is going
2. Inspirational communication — communicates in a way that inspires and motivates
3. Intellectual stimulation — challenges followers to think about problems in new ways
4. Supportive leadership — demonstrates care and consideration of personal needs
5. Personal recognition — praises and acknowledges achievement and improvements
Q: What is the limitation of transformational leadership alone?
A: Teams with the top 10% of transformational leadership were equally or even less likely to be high performers. Leaders cannot achieve goals alone — they need their teams executing on a suitable architecture with good technical practices, Lean principles, etc. Leadership is necessary but not sufficient.
Q: What is the difference between descriptive, exploratory, and inferential predictive analysis?
A: Descriptive — summarizes data (census reports); no causation claims. Exploratory — identifies correlations between variables; shows co-movement but not causation. Inferential predictive — theory-driven hypothesis testing; establishes that one construct “drives” or “impacts” another; uses regression methods.
Q: Why do the researchers use surveys instead of system-generated data?
A: 1. System data is impractical to collect from 2,000+ organizations with different technology stacks
2. Culture, satisfaction, burnout, and leadership can ONLY be measured through human perception
3. Survey responses are comparable across wildly different contexts
4. With proper psychometric validation, survey data is as rigorous as system data
Q: What are the three statistical tests required to validate a construct?
A: 1. Discriminant validity — items not supposed to be related are unrelated
2. Convergent validity — items supposed to be related are actually related
3. Reliability (internal consistency) — items are read and interpreted similarly by all respondents (Cronbach’s alpha)
Q: Why does the software delivery performance construct use only 3 of the 4 DORA metrics?
A: Lead time, deployment frequency, and MTTR together form a valid and reliable latent construct (passing all three statistical tests). Change failure rate does NOT pass all tests when combined with the other three. It’s measured separately but is strongly correlated with the three-metric construct.
Q: What does “shifting left on security” mean in practice?
A: Integrating security into the software delivery process instead of making it a downstream phase. Includes: security reviews for all major features without slowing dev, infosec team contributing to design and attending demos, security testing in automated test suites, and easy-to-consume preapproved security libraries/toolchains for developers.
Q: What does research show about building security into software delivery?
A: It improves delivery performance (positively impacts CD) AND improves security quality. High performers spend 50% less time remediating security issues than low performers. Building security into daily work is faster and safer than retrofitting it at the end.
Q: What three things are highly correlated with software delivery performance and team culture (from Ch. 11)?
A: 1. Cross-functional collaboration
2. Climate for learning
3. Tools (teams can choose their own tools)
Q: What 6 diversity statistics were found in the 2017 survey?
A: 91% male, 6% female, 3% non-binary. 33% on teams with no women. 56% on teams < 10% female. 81% on teams < 25% female. 77% did not identify as underrepresented minority. 12% did identify as underrepresented minority.