445: Working Iteratively

What It Covers

Stephanie Minn and Joelle Kenville examine the technical and social factors that enable or prevent teams from adopting iterative development practices, including deployment friction, code review culture, and organizational incentives that shape developer behavior.

Key Questions Answered

• •Blameless Post-Mortems: Effective incident retrospectives focus on system-level failures rather than individual mistakes, examining monitoring gaps, deployment timing decisions, and response processes to build resilient engineering cultures where teams learn from production incidents without fear.
• •Deployment Friction Costs: Shared staging environments and slow CI pipelines create per-iteration costs that incentivize bundling changes together. Teams working across time zones with mandatory QA approval face twenty-four hour turnaround times, making developers combine multiple features into single deployments.
• •PR Size and Review Speed: Code review time scales non-linearly with PR size—doubling lines of code can triple review effort. Small, frequent PRs create virtuous cycles where reviewers spend ten minutes between tasks, while large PRs require scheduled hour-long sessions that delay feedback.
• •Iterative Communication Benefits: Shipping one PR per day enables developers to provide specific progress updates about refactoring steps and technical discoveries, replacing vague status reports. Teams gain visibility into work-in-progress, reducing context-loading overhead when switching between tasks and maintaining development momentum.