Positive retro: what happens if you look forwards, rather than back?

@ZoeFCunningham did a talk on an alternative approach to how to do Retrospectives in agile development at the last GeekGirl Meetup breakfast. Below is a write up from her covering what she talked about.  Very interesting talk! 


In Agile software development, a retrospective is a meeting held at the end of a regular period (e.g. every fortnight or month) where you look back on work done in the last work period and assess what went well, what went badly and what you want to change for the next work iteration. Retrospectives are a great tool, as they help the team to think about how things are going at a high level and to spot and fix common issues that can help them to work more productively.
However when teams are used to running lots of retrospectives they can slow down and become less useful. Sometimes the team treats them as a box ticking exercise and new insights are rare, or the meeting can get derailed by repetitive discussion of the same old problems that the team don’t know how to fix.
In my role as Managing Director at Softwire, I spend a lot of time thinking about our culture and how to make it totally awesome. One area that I am really interested in is positive psychology, for example in ways of feeding back to people. Did you know that you should give five pieces of positive feedback for every single piece of constructive feedback?
Having been impressed when I saw Paul Z. Jackson speak at TEDxRussellSquare I took a look at his book applying positive psychology to business, The Solutions Focus. This book highlights that when dealing with people it is more productive to discuss solutions, rather than problems. Often a problem can be solved by applying ideas that are working elsewhere in the business, or have been working at a different time.
The Solutions Focus contains a four step coaching format that works really well for retros.
1. Describe the Future Perfect. This is such an amazing way to start a retro. Rather than looking at what is broken now, ask the team to describe what the situation would be like if everything were working perfectly. The aim is to describe what it is like, rather than to work out how to get there. A great question to get people to start thinking in the right way is “Imagine that you woke up tomorrow and everything were magically changed overnight. How would you be able to tell the difference when you came into work?”
2. Scale where you are right now. Once you’ve agreed on the future perfect as a group, ask everyone to indicate where they think you currently are on a scale from 0 to 10, where 0 is that none of the future perfect happens and 10 is the future perfect. It is not important that everyone agrees, or that this is an accurate number.
3. Look at what makes you that high (e.g. a 4, rather than a 0). This next step is about finding out what parts of solutions are in place already. Does one team have a working build server? Is there some new code that is a joy to work with? Try to tease out here what people have actively done to make these things come about – these are steps that they can use again in the future.
4. Find the next small step. The final step in the coaching session is to take a small step towards the future positive. For example, if you are currently at a 4, what would you need to do to progress to a 5? In a group session I ask every individual to take a small action that they can implement themselves. This is important. If your retros are anything like mine, you will hear a lot of “we should”s and “someone should”s – these do not help us. What can each individual take away to do themselves? This choice does not have to be the “most efficient” or “best” action in anyway. Why not pick the easiest or most fun action? Or, best of all, why not use this session as a way to give yourself an excuse to make the changes that you really want to make but can never find time for?
If you are running a series of sessions, add another step in at the start of the next session to discuss what has improved. There is no need to link this to actions that people took (or to “check up” on people) but do try to find out what people did that caused the changes.
I love using this retro technique. I find it to be engaging and inclusive, since the first job is to describe when things are perfect, not to find a new way of undertaking a difficult challenge. By thinking about everything working, our minds are freed up from trying to find implementations and we uncover more options.

What do you think? If you like the idea, why not help me on my quest to help all software developers work in a positive manner! I’ve spoken about this technique at the GDS Agile Tea meetup and Girl Geek Meetup – do you know anyone else who would like it explained in person? I’ve run sessions for most of our teams at Softwire and for the tech team at Just Eat. If you’d like to have a chat about how to implement this in your company, or you’d like me to come and run one for you, let me know. 

(You can reach Zoe on Twitter.)