We recently conducted our twice a year release planning, and while reviewing our process improvement items from the last planning session, I began to question some old practices.
Due to feedback from a recent retrospective, we decided to conduct these reviews every 4 weeks instead of every 2 weeks. Most of the team has been following a Scrum-based Agile process for nearly 2 years; consequently, a healthy flow has resulted, which decreased our need to meet as often. In addition to periodic retrospectives, we used to conduct a release retrospective that covered what happened during the release. At the end of this last release, we made a change to the process and did not conduct a release retrospective. (I say “we”, but in reality, it just never got scheduled.) In hindsight, this seems like a good approach because we shouldn’t wait for the end of a release to make changes.
It seems that others have been questioning the timing and format of these retrospective meetings as well. We currently use a modified version of De Bono's 6 Thinking Hats; however, some of these other methods are a good way to changeup the flow of the meeting. One additional idea I’ve recently had was to set a non-iteration based topic to discuss and brainstorm on improvements. An example of this might be taking an issue from the last retrospective, like code reviews or upgrading 3rd party libraries, and conducting a deeper discussion on that particular top. In any case, we are quickly approaching the need for Retrospective Surgery.
