Collaboration, Agile Practices, and DevOps Culture
This domain tests the human system around delivery: how decisions are made, how teams are structured, and which measures actually predict performance. Questions are scenario-based - choose the practice that shortens feedback loops and pushes decision authority to the people doing the work.
Core rules
- DORA research: delivery performance (deployment frequency, change lead time) and stability (change failure rate, failed deployment recovery time) improve together. Speed and stability are not a trade-off when architecture and culture support small batches.
- Westrum culture types: pathological (power-oriented, blame, information hoarded), bureaucratic (rule-oriented, departments protect turf), generative (performance-oriented, information shared, failure analysed). Generative cultures predict higher delivery performance.
- Blameless postmortems assume people acted reasonably given the information available; fix systems, not individuals. Psychological safety is a precondition for fast incident response and honest reporting.
- Team Topologies: stream-aligned teams own a value stream end to end; platform teams offer self-service golden paths as a product; enabling teams coach temporarily; complicated-subsystem teams own genuinely specialist components. Cognitive load is the design constraint.
- Change management: peer review plus automated evidence replaces most change advisory boards. Approval should sit with the team accountable for the change, not a distant committee.
- Flow: lead time (request → delivery) versus cycle time (start → finish); limit WIP; map the value stream; keep ADRs and runbooks as versioned documentation.
Worked example
Over a quarter a team ships 60 production deploys, 12 of which need a hotfix or rollback, with median commit-to-production time of four days. Reasoning: deployment frequency ≈ 60 ÷ 13 weeks ≈ 4.6 per week; change failure rate = 12 ÷ 60 = 20%; recovery time must be read from incident records. A 20% failure rate with a four-day lead time points at large batches and weak pre-merge verification, not at "deploying too often". The intervention is smaller pull requests, a merge queue and faster automated tests - batching less, not releasing less. The historical CAB answer, fewer releases, increases batch size and makes the failure rate worse.
Traps
- Treating utilisation as productivity; fully busy queues have the worst lead times.
- Copying another organisation's team structure verbatim instead of designing for your own cognitive load and Conway's law.
- Applying DORA metrics to individuals - they are system measures and get gamed when used for performance review.
- Running retrospectives with no owned, dated actions, so the same failures recur each quarter.