Stephanie BySouth | Good Retro Guide
1515
post-template-default,single,single-post,postid-1515,single-format-standard,qode-quick-links-1.0,ajax_fade,page_not_loaded,,qode-title-hidden,qode-theme-ver-11.2,qode-theme-bridge,wpb-js-composer js-comp-ver-5.2.1,vc_responsive

Good Retro Guide

Continuous Improvement is only a retrospective away

Retrospectives are the art of the inspect and adapt cycles in iterative agile development. They can be done well or poorly just like any workshop but there is a simple approach checklist that will assist you to facilitate for greater team retrospection. Diana Larsen and Esther Darby have outlined a succinct and great top 5 methods for ensuring teams inspect well and adapt appropriately.




1. Set the stage   (social agreement the agreed purpose)

2. Gather some data   (before we decide what to change)

3. Generate Insights   (what does that mean for us?)

4. Decide what to do   (experiment to try…)

5. Close the perspective    (recap decision, review retro quickly)


 

Setting the stage is an important book end for the start of your session. It’s made up of two essential elements. The social frame & the focal point for this retrospective. Firstly the social frame is similar in purpose to creating a social agreement or team agreement but in this instance it is to help establish the context and recommended behaviour for creating a great retro. The Focus On / Focus Off exercise they talk about in the video is a great summary to establish expected behaviour.

 

 

The second component of setting the stage is agreeing on the focal point of the retrospective. Often teams become improvement bored, or reach a stage of ‘whatever’; particularly, if the same format for a retrospective is used each and every time. Setting a goal and focal helps to look at different areas at one time and to decrease the size of the improvement ‘wishlog’. Improvements need to be feasible, doable, and not stress full for teams.

 

 

Gather some data on the focal point to get the facts and sense from the teams perspective so as not to have the session dominated by anyone persons perspective. For example if your looking at coding practices have the team write up stats for # of failed tests, # of failed builds, # of successful recoveries PLUS underneath have them chart their energy for coding levels over the iteration.

 

This will give you a number of facts around what is happening and debunk any assumptions i.e. Geoff is always breaking the build and stuffing us up. The data shows (or not) that Geoff has low energy for coding focus because he’s also on incident management which constantly interrupts his work.

 

Generate insights from the data, the conversations,  and the anomalies in the data. This is where most coaches use the learning matrix of what went well, what didn’t go well etc have the team think, discuss, and write down. Ask the team if there are any emerging patterns? What’s the causes, is their a convergence point that’s leading to this. Play the what if game to help expand their thinking to get to the cause – what if you had skills, what would our day to day look like if we never had a failed build? (probably weird as it’s a normal part of TDD but it’s a nice simple example to use here) Ask what path from the past lead us to this point?

 

 

Decide what to do and be clear about how to achieve it as well. Often in a retro it seems obvious what needs to be done, and people ask why has this never been fixed before? Even though that person may be thinking it’s so obvious it often isn’t AND do answer why has this never been fixed before? It’s a quick way to know if blockers will pop up. What to do should never be so huge the team gets into a helpless rutt and preferably not just ownership of always one person. Teams get used one person always fixing so avoid this mentality as much as possible.

Close the retrospective quickly and decisively. It’s important that the team has final agreement what, how, when they will be doing the improvement action. have the team agree on when they’ll follow up to ensure ongoing support for achieving the improvement is in place. Lastly do a Return on Investment poll to understand how to improve the retrospective. Break even is great, and it’s very interesting after a number of iterations if teams start to see benefit from their iterations.

 

 

1. Google Tech Talks: 25th January 2007 Diane Larsen and Esther Darby Authors of Agile Retrospectives: Making Good Teams Great





♥♥♥♥♥♥♥ Every dog lover deserves a designer dog collar or designer dog lead this  Christmas from the Leroy Madison Online Pet Shop ♥♥♥♥♥♥♥

 

 
Good Retro Guide