Improving Software Quality with Retrospectives
summary
Uses four concrete practices and when to pick them: do a five whys root cause analysis for major defects, outages or recurring bugs, tie causes to measured loss and estimate fix cost, involve a facilitator plus a technical SME and publish the agreed actions; run a future-spective by imagining a zero‑defect product, extract first practical steps (example: swap ego for paired work); run an Agile self‑assessment radar (1–5) to spot mismatched views; introduce a stop the line bell or rope so anyone can halt work for critical quality issues.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 0:37About Ben Linders
- 1:19Retrospectives
- 3:26Techniques
- 4:37Root Cause Analysis
- 8:06Effect Chart
- 9:05CostBenefit Analysis
- 16:23Future Spective
- 21:49How do they work
- 24:13Self assessments
- 26:16Stop to line retrospective
- 28:01Stop the line culture
- 29:39Two facilitators
- 30:35Bonus
- 32:27Questions
- 33:20What if the manager is present
- 34:59Selfmanaging
- 36:21Motivation
- 38:12Roles
- 39:46Safety
related talks
30mImproving Software Quality with Retrospectives
20mOptimizing Agile Practices: The Retrospective
01h 43mProject Retrospectives (Why, How, When)
30mNoRetrospectives
45mAgile Retrospectives and the Agile Teams of Today and Tomorrow
40mAmplifying Agile Quality Practices
32mRetrospectives
36mHow Good Is Your Software Product? (Evolving "Quality"Throughout The SDLC)