Retrospective

We just had our sprint retrospective (aka post-mortem) and some things didn't go so well. I forgot the basic tenent of running a retrospective (or any critique, for that matter): don't just focus on the negative.

There are always three questions to ask:

• What went well/what works?
• What went poorly/what doesn't work?
• What (if anything) should we change?
  

It got off on a sour note when one developer started talking about his tasks. He mistakenly had not integrated them with the main source tree because the work story was not a clearly defined feature. Normally this would invalidate the code written and the feature could not be considered part of the sprint. Some draconian teams might even make him delete the code and start over. I let it slide and he demoed since we're still getting our bearings, but it put him on the defensive (he easily gets defensive). The irony is that his task was only to gather the requirements, so writing functional code went well beyond what was expected.

My feelings about the longer cycle length cast a negative pall over things as well. We agreed to shorten to a three-week cycle. That seems to be a better sweet spot once you consider two to three days of the sprint involve the demo and kickoff meetings.

Another thing I did wrong was to dictate some new processes. As the scribe for the team I've been feeling the pain of poor data tracking more than others, so I just told everyone what they'll be doing. It's the correct stuff, but it was incorrectly sold. Our new practices will be:

• Each developer is responsible for knowing/discovering their requirements
• Each developer is responsible for having at least one acceptance test written for each work story
• Each developer will start entering their own data in our current tool (ExtremePlanner)

The only really bad thing is that we all left the meeting not on a positive note.