The Sprint Retrospective is the part of Scrum we use to inspect and adapt the way we work together. We do it every single Sprint, instead of a traditional “post-mortem” or “lessons learned” at the end of a project. The emphasis on doing this continuously has roots in the work of W. Edwards Deming and others who helped create a culture of Kaizen (continuous improvement) in Japan. Remember, there is nothing new under the sun.

We do this whether or not anything is seriously broken. Incremental progress is less stressful, and less risky — that’s why refactoring is the way to get the highest quality code in a world of changing requirements.

Getting together for lunch or beer after work is a nice way to do this. The disadvantage can be a disproportionate focus on the perspectives of the people who speak first, or the most loudly. One way to capture everyone’s insights is the “silent writing” technique:

  • Put two columns on the wall: “What went well?” and “What could be improved?”
  • Distribute Post-It notes.
  • Have everyone spend a few minutes writing one point per Post-It note for either column, as many notes as they like.
  • When the writing slows down, have people come up one at a time and read their notes as they stick them under the appropriate columns.
  • After everyone has spoken, discuss how to convert the “What could be improved?” items in to actions (possibly new backlog items or resolutions).

Who should attend the retrospective? It depends, but I’d usually recommend an informal conversation amongst the actual team members (without bosses or other observers) so the usual impulse to look good for the boss isn’t there. If I’m dissatisfied with one of my team members, I have a better chance of building trust by talking about it without the boss dynamic. I’ve seen team members be more inhibited with each other even with ideal bosses in the room. Bosses who are just trying to help forget that they’re still wearing invisible guns on their hips.

I’m writing about Sprint Retrospectives because I can personally attest to how well they work when applied consistently. Get a ScrumMaster like Kelley Louie who won’t let you slack off on this.

Esther Derby (who adopted my flying/screaming monkey) and Diana Larsen wrote a great book with other retrospective techniques.

Download the PDF version: Kaizen blog

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
One comment on “Kaizen
  1. Just to say that I’m half way through Esther Derby and Diana Larsen’s book and I highly recommend it. Note: this is my first book on the topic.

Leave a Reply

Your email address will not be published. Required fields are marked *