Retrospectives: Which activities do you use

Question

I started doing retrospectives with my team and we are trying several different activities. What activities do you use and do they work for your team. Please give some additional information (teamsize, agile skill levels ...) as well.

Answer 1

We look at each other wide eyed and scream "What the F!@# was that!?"

Answer 2

Since I'm primarily a solo developer I'm either always doing retrospectives or never, depending on your viewpoint. From my perspective, there are two things that are key. First, you should always be looking for something new or an improvement to something existing that you can try. Give it a fair hearing, then evaluate how well it's working and whether it is worth continuing. Second, evaluate your existing practices to see if any are no longer necessary. As your organization grows in maturity, you may find that some things that were required, perhaps due to lack of experience or process maturity, are no longer needed. These things should be dropped. If you're not consistently making efforts to improve or pruning unnecessary techniques, then I don't see much point in a retrospective.

Answer 3

G'day,

I'd highly recommend the Esther Derby and Diana Larsen's excellent book "Agile Retrospectives: Making Good Teams Great" (sanitised Amazon link) which has some great points to make. Unfortunately, typically PragProg expensive, but still a great read.

You might also have a read of this associated question, "Scrum Restrospectives, who do you share the results with?" that had some great points about sharing the results of agile retrospectives.

Edit: One of the biggest helps in retrospectives is the timeline activity that is covered in the book. From the book:

Group members write cards to represent memorable, personally meaningful, or otherwise significant events during the iteration, release, or project and then post them in (roughly) chronological order. ... Divide the team into small groups, with no more than five in a group. Keep people who worked closely with each other together (affinity groups). It’s better to have two small groups representing one affinity than one big group.

HTH

cheers,

Answer 4

A retrospective has one purpose, to drive continuous improvement. The format is simple. The Iteration Manager/ Scrum Master gathers the team and follows these steps

• Identify what worked (start with the positive)
• Identify what is broken
• Prioritized and pick three broken things to fix during the next iteration

The items picked will result in story cards which are then worked during the next iteration. Follow these steps and continuous improvement will move from a slogan to a realization.

Note: a retrospective should happen at least each iteration. However, if an event dictates, you can hold an iteration immediately.

An additional activity we use is for the team to score itself. Given that the agile manifesto leads to the 12 principles, we have also defined a set of practices we employ (combination of SCRUM and XP). The team will grade themselves against the set of practices used by the team. The results of the self assessment are posted as a big visible chart. We engage in this activity monthly.

The leadership will use the self assessment to identify if and when they need to provide support for the team. Support might come in the form of coaching, training, skill supplementation, facilities improvement etc. It is not important that grading occur on an absolute scale. Instead, we are looking for trends in the self assessment not the ability to grade one team against another.

Both the retrospective and self assessment can be employed by new and experience teams alike. Both serve as a mechanism of continuous improvement.

Answer 5

people here mentioned some great ideas I've been using, and definitely Agile Retrospectives is the way to go.

I've recently ran into a book called "Change Handbook" that contains a multitude of tools that can be used as part of retrospectives as well in my oppinion. (Kudos for Hubert Smits who came with it to a PO workshop I attended)

My favorite tools, which I've used mainly for an R&D team of about 20 people using scrum, but also in the days before the Agile adoption, are:

• Timeline
• Identify issues in small groups, then consolidate on a board
• Identify issues on postit notes, then cluster using silent grouping, then prioritize using 10 dots per person, then work on issues in either groups or together, depending on the team size (until about 8 people keep everyone together).
• the +/delta by default, if no need to spice things up...
• root cause analysis using a version of a fish diagram together with "5 whys" approach.
• review team visibility charts from the sprint (TB/BDC) and discuss issues
• for mature teams - I suggested they use an ongoing "surprises"/"remember" chart that allows them to save items for discussion in retrospective. I've never seen this in actual use, but it sounds very useful if a team pays attention to this. note also that for really mature they will probably retrospect just in time as soon as the crisis caused by the surprise is over and they can take a breath in.