Over the past two weeks, my department has been working on our first iteration using agile practices. Yesterday, we wrapped up with a retrospective to go over our progress. We used a fish bowl to keep the conversation centered and focused – a method that once again proved to be useful for controlling a discussion without controlling the discussion.

We setup a whiteboard with columns for the following topics:


Things that we should start doing on the next iteration.


Things that we should continue to do every iteration.


Things that we should stop doing.


Things that we did (or didn’t) do that will contribute to our technical debt.

We started with an introduction to the retrospective, a declaration of our goals, and a quick recap of how the fish bowl works. We also identified a remote advocate – a single person who is responsible for coordinating communication with our remote team members. Our company uses Live Meeting for conferencing, so we explained how to use the seating chart and how to use the Raise Hand feature. The advocate also had their IM client up for any out-of-band questions or issues with the meeting client. Once that was up and running, we opened the discussion.

Some of the topics discussed:

  • Start making sure the acceptance criteria are well defined before starting the story.

  • Start pairing throughout the development of the engineering tasks and not just at the end for review

  • Start keeping an audit trail of initials of people who worked on a story or an engineering task

  • Stop putting incomplete stories into the backlog

  • Continue the daily stand up meeting format

There were many more, but you can see how the structure worked. In all, we identified around 20 items that we need to either start, stop, or continue.

Once that segment of the meeting was over, we went over some of the methods being used to track things like burn down. Our project manager (whom we have yet to designate with a more appropriate agile title) went over the spreadsheet she uses to track story points, engineering task estimates, and actual hours worked on each task. She then showed some web sites from other groups in the company doing Scrum and how they had organized their Wiki, how they posted pictures of their planning board and burn down chart, and their honorary stuffed ScrumMaster.

We did have a few bumps towards the end of the iteration with our test environment and the number of defects coming back from testing (which is why we want to start pairing earlier). We hope to improve with each iteration (of course) but for our first lap around the track I think we did pretty well!