Retrospectives and Continuous Improvement


We have just finished our 31st sprint at Zemanta and, since we do a retrospective after every sprint, we consequently did also 31st retrospective. As our cook Klemen can testify, retrospectives at Zemanta are always very interesting events. My coworkers are quite outspoken for geeks and definitely not shy in expressing their opinion, so we always get to hear very interesting commentaries on the past sprint, work of team members, and quite many suggestions for the improvement of our process. We follow the traditional form of the retrospective where we go in a circle and each team member is supposed to answer the two questions:

  1. What did you like in the last sprint (i.e. what to keep), and
  2. What could be improved in the next sprint (i.e. what to change).

After doing something the same way for 31 times it is definitely time to juice it up a bit. But making a bunch of guys (and only a single gal) expressing their honest opinions is never an easy endeavor. Therefore I'd like to encourage you to share in comments your experience with process improvements techniques in general and retrospectives in particular. I'm especially interested in techniques that go beyond standard agile retrospective format. Maybe some of your practices are applicable for us, too.

Why Retrospectives Should Get Personal

What do you get when you cross a bunch of passionate, self-directed engineers with an agile, iterative approach to both software and personal development? Predictably, you get continuous delivery of customer value and solutions to really hard problems.

We need this to understand how you use our service - you can take it out if you like. Cheers, your Blogspire team.