Good Question!, Meeting Facilitation

How to Deal with Results from an Agile Retrospective?

Have you ever heard a team complaining about results of a retrospective not being realized? I have. And it’s important to change something immediately after hearing it.
Realizing the agreed improvments from the retrospective is one of the agile principles of the Agile Manifesto:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (http://agilemanifesto.org/principles.html)
So if you are earnestly doing an agile “Inspect & Adapt” and do not realize the agreed improvements of a retrospective, you are missing the whole point and are doing a simple “Inspect”.

The answers to the following questions could help to make sure improvements are realized:

  • Who is responsible to realize the improvement?
  • How can you be sure that the improvements are not forgotten?
  • How are your improvements logged?

Who is responsible to realize the improvement?
Always agree in the retrospective who will be responsible for putting the improvement into effect. This can one or two persons. Write their names next to the agreed improvement. Do not assign the responsibility to the whole team as nobody will feel responsible then.
Problems that the team can’t solve themselves are impediment and  it’s then the Scrum Master’s job to push it up to the management: fast and direct. And it’s the Scrum Master’s job to get on the management’s nerves until the impediment is solved.


visualize improvements from retrospective
How can you be sure that the improvements are not forgotten?
Visualize the results of the retrospective. What seems to be working very well with us is to put a copy of the agreed improvements on the team’s board: Everyone sees it everyday at the Daily Stand-Up. Alternatively: Improvements turn to User Stories that are done within the next (!) sprint. Here it’s the Scum Master’s job to make sure this happens.

How are your improvements logged?
With “logged” I mean the structure of your agreed improvement in the retrospective:
1) Write whole sentences and not bullet points. This may take a little longer, but you (and everyone else) will understand them also after a few days.

2) As mentioned: Assign one or two responsible persons for the improvement.

3) Agree on a deadline when the improvement should be put into effect (or at least agree on a date when the team gets feedback on the status of the improvement)

Related post:
3 Retrospectives in 2 Days

Agile Coaching, Meeting Facilitation

Agile Team Retrospective Activities: Starfish & Team Radar

Variety in retrospective activities are definitely necessary. The more retrospectives I do, the more I’m getting tired of using the same method over and over again. And hey, this will most probably bore the teams I work with as well. Therefore it’s good to challenge the team AND you with new retrospective techniques. In the last weeks I tried out Starfish and Team Radar in retrospectives.

Starfish
Starfish is a fantastic activity to get your team to re-think the basic questions:
What went well in the last iteration? How can we do better?

starfish retrospective

Starfish refines those two questions and gets more detailed information from the participant instead of just a binary view. If you know retrospectives the different categories of the Starfish are self-explanatory, for everyone else I recommend the post from Pat Kua from 2006.

You can either let the team write post-its for every category one after the other or let the team handle all categories at once.
After the team has gathered the data you can start right away with some clustering or go straight to agreed, detailed improvements for the next wees by exploiting categories: stop, start or less.

Team Radar
Team Radar is powerful if you have a communicative team. It’s not so good if team members prefer writing post-its to talking (if you know hwat I mean… 😉 ).
You can pick 4 to 5 subjects that either you or the team think are worth discussing in detail. Those subjects can be team values like Respect, Feedback or Communication. Alternatively you can also choose reoccuring subjects from former retrospectives like quality of code skills, effectivity of the team etc. If you are not 100% sure what subjects to choose, only suggest subjects and then let the team decide.

team radar retrospective
This is how you can work with Team Radar:

  1. Explain to the team what you think that every subject means and then let the team discuss/agree on that
  2. For every subject let everyone dot/rate on a scale from 0 to 10 where she/he thinks the team stands concerning this subject
  3. Discuss each subject in detail and agree on concrete improvements:
    • Be aware if dots are far away from each other on one subject. This is most probably because of misunderstandings within the team.
    • As I mentioned before: This activity is for communicative teams. Take care that everyone gets the same time limit for their opinion.

Team Radar is described in detail in still the best book on Agile Retrospective Activities: Esther Derby and Diana Larsen “Agile Retrospectives: Making Good Teams Great”.

Nevertheless, with a new team, it is important to start and train the basic chain of a retrospective before starting with alternative activities and risking to overburden the team:
1) Warm-Up: What happened in the last iteration?
2) Prime Directive and basic group rules: Explain why those are important.
3) What went well in the last iteration?
4) How can we do better, how can we improve our process?
5) Is there anything we CAN’T change by ourselves?
6) What in detail will we change until the next retrospective?

Related Post:
3 retrospectives in 2 Days

Books, Kanban, Scrum, Scrumban

3 Retrospectives in 2 Days

Last week I had retrospectives with three different agile teams within 2 days. I love retrospectives and a retrospective meeting is one of the first agile things I try to establish when I start working with a team. Every team needs to get used to the advantages of retrospectives though…

The agenda for retrospectives always includes the following 4 questions:

  • What went well since our last retrospective?
  • How can we do better, how can we improve our process?
  • Is there anything we CAN’T change by ourselves?
  • What in detail will we change until the next retrospective?

Besides those questions I experienced that a warm-up at the beginning is more than helpful: Draw a timeline of the past sprint (or period of time concerned in the retrospective) on a flipchart. Ask the team “What has happened in the last weeks?” and then let the team put sticky notes with their answers on that timeline.

The warm-up helps everyone to get their minds focused and it shows that everyone in the team can have a different view of the past couple of weeks.
In addition:
For teams that work with a Kanban system it is sometimes difficult to see what has been accomplished in the last weeks. This warm-up shows them that a lot of work has been finished.

Maybe you like to try out 2 things I experienced as useful:

  1. Have a short break after you have answered the first question (“What went well since our last retrospective?”): It could be a smoking break or as simple as just opening the windows to let in some fresh air for some minutes. The team (normally) has just mentioned a lot of positive things, so try to keep the good vibes for some moments! 😉
  2. Feel comfortable with the silence while the team is writing their sticky notes. Don’t hustle the team when the team seemingly is not writing anything more. Sometimes it only takes a couple of seconds and someone starts writing again.

Read “Agile Retrospectives: Making Good Teams Great” from Esther Derby and Diana Larsen for different tools and recipes in retrospective meetings.

In the next weeks I will try to write a post about how to get the results of retrospectives done.
[Update Sept. 07, 2011: Done. 😉 Please read How to Deal with Results from an Agile Retrospective?]