How the Agile Retrospective activity can benefit all professionals, not just delivery teams

So what is an ‘Agile Retrospective?

Agile is a Culture that was originally created to transform software delivery. Agile is guided by The Agile Manifesto and it’s accompanying 12 Agile Principles. The Retrospective is an iterative ritual originally created as part of the Scrum Delivery process in 1993 by Jeff Sutherland. Since its original structure, the retrospective hasn’t evolved in intention or purpose, but it’s content does change regularly to maintain fresh engagement on self learning. Agile teams utilise the Scrum Retrospective practice to act out and improve on abiding by the afore mentioned principles.

Consider changing from an annual performance review to a shorter and more frequent cycle, at least once a month is a good rhythm to keep. 

Corporations often exercise a performance review once a year as part of a standard HR endorsed meeting or financial incentive program. The premise is that they are designed as a meeting for the manager to communicate to their employee how they are performing, in accordance with the conversation they had last year. While formal submissions must be done – at a minimum – once every year; there are benefits to having retrospective conversations more frequently with your team, your managers or even yourself;

  • mistakes or poor performance can be discussed and resolved close to when the actual event occurred rather than left, forgotten about or not corrected
  • the actions within a review become more comfortable because the frequency gives you more practice
  • the duration becomes shorter as it only needs to focus on the last few weeks
  • the conversation moves from ‘a what have you done and scored assessment’ to a more mentoring/ perform better focus because you have visibility of the score building every month
A performance review can be transformed from drudgery to good value.

went wellHow many performance reviews have you enjoyably benefited from? Not just in the sense of passing the minimum checks to get a bonus but actually gained value that you took away and then put into your job? The majority of satisfaction ratings I’ve gathered are actually determined by the ‘managers communication and socialisation skills’ (as perceived by the recipient) rather than the benefit gained to “perform better”. Interestingly enough the same lack of value occurs for managers who deem the performance reviews a logistical report. Even when they try to inject counsel or suggestion it seems pointless to the reciepient because it’s so far from when the events occurred. If you start observing, discussing and acting on at least one improvement a month you find that the logistical difficulty or poor communication skills aren’t the focus, the work is.

Frequent retrospectives between ranks can soften difficult conversations.

I find it interesting that people can be quite egotistical or power driven when it comes to performance reviews; that is regardless of whether they are the giver or the receiver. In many cases it’s because it’s someone feels they must exert rank to be respected, or because people are actually so afraid of failing they overproject confidence which really presents as arrogance. The heighten responses to incidental and informative feedback are  because of the infrequency at which they occur and the weight of reward based on that infrequent event. When difficult conversations are addressed more frequently a level of comfortably builds up that allows emotions to recede and with training the conversations is simply focusing on the work.

You gain real time visibility of how you are trending over the year, giving you ample opportunity to correct early if do go a bit off track.

needs attentionProfessional athletic teams capture statistics and perform data analysis to identify opportunities to improve – continuously! Without fail the teams will use the information to change their training, their strategy and channel as much improvement into their performance as possible. In fact even amateur and little league teams honour the value of speedy informed data trends. Imagine if they only looked at their statistics once a year? Do you think they would be a winning team? All professionals can use a regular cycle of retrospectives to glean the data they need to analysis opportunity improve, to eliminate mistakes and to continuously learn.


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

Great Agile Scrum Delivery Management Tools

The right tool for the right job? Like scrum make it agnostic fluid and save me time, time, time.

Normally I don’t gush over products but I love anything that reduces the time it takes me to do anything – so below are the best in their special areas.


Pivotal Tracker is brilliant. We used it with internationally distributed teams. Your ability to do sprints, be agile needs to be quite slim – however; trust the product to manage your cycles for you, don’t sweat the old school fat that you may have previously known. The Pivotal guys are really quite clever, they have great experience and understanding in the scrum, xp arenas. So working with a Ruby/Rails TDD team that is truly self organising means you don’t need the below large suite.


For shared services departments with multi-channel product distribution we’re using the atlassian suite – seamless and continuous communication from confluence to jira to greenhopper to fisheye/crucible to bamboo (with SOAPUI integration) to dare i say it – HPQC – for the old school testers, and back again to do it all over again.


The differences are obvious in the pricing models. I do frown a bit at Atlassians training prices for their products.