Please login or join to subscribe to this thread
I am definitely not an expert. I took over a high profile complex scrum effort and found it best to separate team building from retrospective. I used games in my team building meetings which I held monthly and utilized our retrospective meetings at the end of each sprint for coming up with improvements in our approach. The main reason was just the balance of time. We had 4-7 team members that also had assignments outside our scrum development effort as well as the need to conduct meetings for user story refinement for the sprint that usually took an hour and half as well. I am interested in hearing what others do.
I tend to agree with Sally's point of view - I'd rather follow a certain agenda to at least address the main things and then probably can do one or two games to see how team work and collaboration works.
The retrospective is the main meeting for the team themselves to inspect and adapt.
Retrospectives ideally would be a dynamic process through trial & error and adapting as the team grows. Starting from a generic format, then modifying as needed. It's a natural process.
Inspect & adapt should be the mantra for all agile teams.
What this means is that while you might start with a very standard approach to your retrospectives (while at the "Shu" level of agile maturity), after a few sprints, the team should consider doing a retrospective on their retrospectives to find out if there are better ways to gain value from the ceremony (moving to the "Ha" level).
This is where some teams might alter the approach taken to elicit high value outcomes. I've seen games used, creative materials (e.g. Playdoh, Lego) and other approaches to help teams shake off the rust of using the same approach sprint after sprint.
Please login or join to reply