Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Agile Retrospectives: how to improve the meetings and the results

Saturday, July 24, 2010 Luix , 4 Comments

I'll discuss in a couple of blogposts that I read recently in the book that I reference below, regarding how to improve the retrospective meetings.

What is a retrospective meeting?

In everyone's life, a retrospection is when someone stops and thinks about his/her life, evaluating good experiences, bad experiences and checking if he or she has learnt from those experiences in order to be a better person in society.

This, which most people do, in the agile methodologies of software development is called 'retrospective' and it is very useful in iterative development methods, to evaluate the progress made in every iteration. In this case we'll focus on SCRUM most of the time, but a retrospective can be applied to other Agile Methodologies.

Steps of a retrospective

A well-designed retrospective meeting should have the following steps:
  1. Set the stage.
  2. Gather data.
  3. Generate insights.
  4. Decide what to do.
  5. Close the retrospective meeting.
These phases don't seem special or mystical things and lots of teams try to commit to them, more or less. So, the question is, why don't they get good results anyway? Well, maybe the problem is how and not what.

Who leads a retrospective

A retrospective meeting can be led by the manager or by any member of the team, or even this role can be assumed by a different person each time the meeting takes place. The person who leads the meeting mustn't participate in the discussions that will arise during the meeting, because his/her position biases the rest of the people's opinion.

In addition to this, it is very important to analize which parameters must be taken into account in a retrospective meeting. Some examples are:
  • · Find ways to improve the practices.
  • · Discover what we were doing well.
  • · Understand reasons behind missed targets.
  • · Find ways to improve our responsiveness to customers.
  • · Rebuild damaged relationships.
To finish this section, let me mention two important statements that should be observed in every retrospective meeting.
  1. Avoid blaming someone for an objective that wasn't achieved.
  2. Try to make everyone participate in the meeting.

How long should it take

It depends.

It depends on the length of the iteration, on the complexity of the technology used in it, on the team's size, and the level of conflict that arise during the meeting. As a footprint: one week of iteration equals one hour of retrospective meeting. Anyway, there is no point in shortening or extending the meeting more than necessary.

On the other hand, the retrospective meeting must be prepared previously. The team must enter the meeting room with something prepared, at least some draft notes, and must be well informed about the issues to discuss.

How to prepare the retrospectives

The person responsible for the meeting must answer the following questions:
  • · What is the goal?
  • · Who will attend?
  • · How long will it take?
  • · Where will it take place?
  • · How will the room be set up?

How to convince the people to prepare the meeting

The leader can send a short quiz by mail to every person that will assist to the retrospective meeting. Thus everyone will have to take a couple of minutes to think about the last iteration. After receiving everyone's answers, which will be kept anonymous, the results may be read aloud during the meeting, so that they may be interpreted as a summary of the team's insights.

What to do after the meeting

Try to make someone responsible for every action that has been decided during the meeting. Lots of retrospectives fail because, despite giving good insights and making good decisions, everything is missed because nobody takes care of those decisions. So, assign responsibilites and make commitments about those actions to be carried out.

And in the next article...

... I opportunely made a workaround to avoid explaining in detail the steps of a retrospective meeting. I wanted to set the ideas and give some advice. In the next article I'll explain each phase.

Furthermore, I'll explain a list of activities that can be done in a retrospective meeting to promote the participation of every member of the team. This is the first objective of a retrospective meeting and the most important one.



Bibliography:

Agile Retrospectives: making good teams great

Esther Derby & Diana Larsen

4 comments:

  1. Hello,

    Thanks for sharing this post.

    I have been the Scrum Master for more than a year and I have done lots of reading and shared experiences with other Scrum Masters.

    My comments:

    * Scrum enforces time-boxing the meetings. I think that this is a really good practice. When, 'how long should take' depends on several factors as you point out, but I think, like other meetings, that should be time-boxed.

    * You talk about 'manager', 'leader'. For me one of they points of Scrum is empowering the team moving away from managers or leaders (as much as you can), that is, from a central authority (project manager) to the team. Obviously this is not easy in some business environments. However, in my opinion, this should be handled by the ScrumMaster that is a facilitator (more than manage).

    * For me the three key questions to answer in a retrospective meeting for my team are: what we did well? what be enhanced? what are the impediments that you found? These are key to convert Scrum in a continuous improvement system.

    BTW, very good about making sure that next steps happen.

    Let me recommend one book:
    Agile Project Management with Scrum (Microsoft Professional)
    http://www.amazon.com/Agile-Project-Management-Microsoft-Professional/dp/073561993X

    This is for a must read for anybody interested in Scrum.

    Best Regards,

    Jordi Mas
    jmas at softcatala.org

    ReplyDelete
  2. Jordi,

    Thanks for the comments!

    In fact retrospectives are one of our weak points right now, so we're trying to do our homework to improve, and Luis is leading the effort.

    The book you mention is the one that almost started all down here, which doesn't mean we're perfect, of course :)

    We're on our 84 sprint (5 years) now, and one of the goals is trying to do much better retrospectives, because we ended up almost saying nothing and having 5 minutes retros. meetings...

    Thanks!

    ReplyDelete
  3. Hi, Luis -

    You've made a nice summary of the framework for retrospectives here!

    I do have one caution: in my experience, people are often reluctant to talk about the real problems with their manager in the room. They fear they'll look bad, or the manager will remember their short comings for the annual review. Just something to be aware of and watch out for.

    I have seen a few managers who go through the motions of listening to the team, and then tell them what to do. That's very demotivating.

    BTW, I recently collected a bunch of articles I've written about retros on my blog. http://www.estherderby.com/tag/retrospectives

    Let me know how it goes!

    Best,

    Esther

    ReplyDelete
  4. Thanks all for your comments, I am really astonished for all the feedback received, especially Esther; it's great that someone who I admire have read this article.

    Many thanks!

    ReplyDelete