Thursday 21 November 2013

"Well Run Retrospectives for Scrum and Agile Teams" - Article by Mitch Lacey

I came across with a Mitch Lacey's article about how to run useful retrospectives.

In my experience, retrospectives can become rather painful, either due to the extensive length of the meeting, or to endless debates, or any other not-so-agreable reason.

However, much can be made to improve the quality of these meeting, and consequently to allow the team to benefit more of them. You just have to want to improve :)

Here's a brief description of the article.

In general, the article leaves the following notes:
- Retrospectives are a key part of a Scrum team’s inspect-and-adapt cycle. (keeping track of the continuous improvement approach)
- The retrospective is the sole opportunity for team members to examine how they work and how they are working together.
- Retrospectives in Scrum […] give teams the opportunity to change behavior and team culture.
- They are a safe place for team members to share, constructively, feedback with others on how their actions (or inactions) impact the quality, morale, and attitude of the team.

Author sugestions on how to improve Retrospectives:
- Choose a facilitator, which should plan ahead the meeting
- Physical Setup: sugests standing-up in the meeting (don't find it very practical when you have lengthy meetings...), display a timer to control each time box
- Define Ground Rules - suggested ones:
   Be respectful.
    Do not interrupt.
            Put away laptops and phones.
            Park long discussions in the designated lot.
            Recap what you hear to ensure understanding.
            What is said here stays here.
- Run the retrospective with 'only' the team: the author suggests not inviting recursively the PO in some scenarios
- Collect Data in the first 15 minutes or so: we use this time to write the tipical post-its
- Prioritize Data: choose the more relevant items to discuss - the author suggests the use of virtual currency - People spend their currency on the items they want to discuss.
Make a Plan & Choose a Driver: after prioritizing the items, define timeboxes of discussion based on the time left. After the discussion of each item, ask “Is this something we are going to mitigate/fix or not?”. Register the agreed mitigating action o why the item will not be addressed
- End the Retrospective - do the wrap-up with rapid question punctuated from 1(-) to 5(+), like: “how was this sprint?” and “what do you think next sprint will be?” – more important than the answer, the author suggests to be attentive to the non verbal language. When he notes a team members disconfort of any sort, he addresses it in particular. If the person says everything is ok, the author lets it go, and observes the team during the sprint.

In general, I should say that the goal is to get the most out of retrospective meetings, understanding what we can do better in the next sprint. That should motivates us either to continue doing better, and ultimately, giving a sense of involvement in the team goals, making each team member feel it's importance at the team.


Enjoy! J

2 comments:

  1. Well written article and it does have that content which can work regarding the ways that are important to have knowledge about, agile and scrum methodologies helps a lot in terms of doing better with the projects.

    ReplyDelete
  2. Hi Bartholomew. Thank you for your comment. Yes, very interesting article that helps us to keep focus on what is important when evaluating the sprint.
    All the best!

    ReplyDelete