Lean methods employ Kaizen, or continuous improvement, to reduce waste and improve results on a regular, even daily, basis. On the leanagilescrum group, Alan asked:
[A]re there known techniques for facilitating kaizen activities within Lean/Agile software development?
Martin suggested:
To me, software Kaizen is more than looking for waste, it's looking for ways you can improve things all across the board.
I'm a hands-on developer, so I'm pretty code-quality focused. If you have a horrible untested/untestable legacy codebase, it's pretty easy to measure the improvements you can make by refactoring to testability/design patterns. I guess you can look at that as reducing the wasted time people scratch their heads and say "how's that supposed to work?"
I like to look things like number of classes under test, percentage of code coverage (although this is tricky by itself).
I strongly believe that if you don't have high quality code, you'll only be able to go so far with other Kaizen approaches.
Finally, Phillip responds with a detailed review of steps to follow before, after and during a Kaizen event, closing with:
The above described process should happen in less than a week. The spirit of Kaizen is to identify waste and eliminate it through process improvement, do so quickly involving the people actually doing the work, implement the change, support and monitor the change, then start all over again.
In a related blog post, Bruno Câmara analyzes the intersection between Scrum and Kaizen, suggesting that incremental improvements are made in the sprint retrospective, and that collecting and analyzing data is done daily with the burndown chart and project backlog. Broadening the scope somewhat, he suggests that that agile processes avoid waste through excess documentation, and that agile's small self-managed skilled teams push decision-making to the developers, as Kaizen intends.
For more information on Lean, Kaizen, Retrospectives and Continuous Improvement, read on at InfoQ.
