Process retrospective in a nutshell

While teaching a CSM class last week I was asked to spend some time on the current software development process in the company I visited. Since I had the retrospective as the next topic on my training agenda I decided to do an ad-hoc exercise with the team. After explaining the principles of a retrospective (setting the scene, collecting data, prioritizing and deciding on actions) with created a timeline of the current process. Four flipcharts on the wall represented the stages in a waterfall: analysis - design - programming - testing. All the people in the room wrote post-its with their positives and negatives in this process and posted them on the timeline. The pattern didn't show much of a clustering, the experiences were normally distributed along the timeline. So we decided to prioritize the experiences: each team member got a sheet with garage sale stickers (the pre-printed ones with values from 25ct to $10). They put money on the practices which they either wanted to keep or wanted to change. High values on the keepers indicated practices which they valued and wanted to keep using after their move to Scrum. High values on the negatives indicated practices which would be of a lot more benefit to the team and organization if they were changed. The exercise took app. 45 minutes, including a few discussions (not completion) of the solution design. I loved the clear display of the value of a retrospective, and the team was excited about the amount of work they could complete in just 45 minutes. The force of silent grouping!