In 30 seconds
- Improve in small steps, often, rather than in rare big reorganizations.
- Each change is an experiment: try it, measure it, keep or drop it.
- The retrospective is agile's built-in improvement loop.
The loop
Most improvement methods follow a version of Plan, Do, Check, Act (PDCA), popularized by W. Edwards Deming: plan a small change, try it, check the result, then adopt or adjust it. Agile teams run this loop every sprint in the Sprint Retrospective.
Examples of small improvements
- Adding a WIP limit to the review column
- Making the Definition of Done include automated tests
- Moving the daily stand-up to a less disruptive time
Each is cheap to try and easy to reverse.
Why it stalls
- Actions agreed but never owned or tracked
- Too many changes at once, so nobody knows what helped
- Problems outside the team's control that never get escalated
Myth vs reality
Myth · Improvement needs a dedicated project.
Reality · Small weekly changes add up faster than rare big programmes.
Myth · If it isn't broken, don't improve it.
Reality · Good teams improve what works too.
Myth · Improvement is the Scrum Master's job.
Reality · It's the whole team's job; the Scrum Master helps.
FAQ
How is continuous improvement different from kaizen?
Kaizen is the Japanese name and tradition behind the same idea.
How do we know an improvement worked?
Decide beforehand what you'll look at, such as lead time or escaped bugs.
How many changes per sprint?
One or two. More makes results hard to read.