Practical Retrospective on Agile Retrospectives...

If you read my previous posts on Agile, you'll know that I'm not claiming to be an Agile expert, nor a pukka Agile practitioner that abhors classic project management principles, evangelising the merits of Agile/Scrum to everyone, etc - but I do believe in the core principles of the method and am applying as many of these principles in my day-to-day activities in my current company, where I'm a part-time Scrum Master.

I'd like to share my experience with running Retrospectives. Reading about the topic is one thing, going on a training course or seminar is definitely enlightening, but practising the thing in real world scenario is another experience all together. It is especially challenging when the team are used to doing it a certain way, have certain misconceptions or are not familiar with the goal of the process.

Take my current team for example - we're a team of 20 developers & testers, with a handful of business analysts, graphics artists that make up the product team. We're working on an advanced user interface for STB EPGs. It's no typical project because 18 months down the line the requirements for the UI completely changed [maybe it is your typical S/W project :-)] and we're dealing with a lot of uncertainty.  I'll discuss the nature of this challenge in a future post, and how different streams of Agile can be applied to remedy the situation.

Focussing on the retrospectives for now, you need to understand the nature of the team. A Scrum Master is not just a buffer, is not just someone who can facilitate and remove impediments, is not just someone who knows and applies Scrum processes properly. A Scrum Master must also be in-tune with detecting the make-up of the team, understanding the nature of each individual, and apply different tactics for different people. Whatever management courses teaches you about knowing the characteristics of your people, their temperaments, strength deployment index & motivational values -- all of this must be noted and applied in the daily management of Scrum teams.

It is especially relevant when it comes to running a retrospective.  In my team for example, we've got two development units. One unit comprises a team of contractors from India, being led by an Indian who's been living in South Africa for the last seven years. Most of the guys are from the same region Kerala, and gel quite well as a unit.  The second unit is dominated by white South Africans, mostly Afrikaners & a native SA Indian. The former unit, is quite reserved and look for direction from the team leader. Generally the team leader speaks on behalf of the team - this is typical culture of the Indian way of working.  The latter unit however, is a very loud, outspoken team - people are not afraid of talking (mostly out of turn), and venting their issues.  In the midst of each team, are representatives from the Product team, consisting of very experienced analysts (who've never used Agile before, as well as some really new people who've not worked with STBs before). The product team supply the work to the development units, and thus are part of both teams retrospectives. So we two separate retrospectives (we also do two, now going on three, separate stand-ups, planning meetings & planning reviews).

We run two week sprints, we've just finishing Sprint 23. Up until Sprint 21, the retrospectives was all about - "What are the issues, How can we fix them...". In Sprint 22, we introduced the "What's worked well, What's not worked so well & should stop,  What can we do better/You like to add".  I kept the format of the previous retrospective, but introduced a the retrospective as a game. Essentially my message to the team was that Sprints are personal experiences for each member, it's an individual experience - so we want to hear from each team member on his/her take of the Sprint...

The rules of the game:

• Each member in the team must express an opinion - must voice something.  (The Indian team are normally reserved, and leave the talking to the team leader). Enforcing this rule, then compels people to participate
• Don't be afraid to say anything - we will not judge you, interrupt you or challenge your response (Some members are really loud, physically imposing, sometimes intimidating and rash when speaking that can be misunderstood by most people as being directed personal jabs, people are shy or insecure about saying something that makes them look stupid) - So remove all of that out, and create an atmosphere of safety
• No speaking out-of-turn - Wait for your turn to speak please. Stop loud people in their tracks, they must observe the rules
• Give everyone a chance to have his/her say. You can only comment on what topic at a time - e.g. first round looks at "What is working well" - repeat as required until you run out of suggestions, then start the next topic
• Do not try to solve problems in detail in the retrospective - we identify the top 10 burning issues that must be resolved in the next sprint, assign owners to actions
• Keep-to-time: Strong time-keeping, do not stray off-topic. Force people to stick to the topics
• Allow a few minutes of silence time for people to collect their thoughts and write their suggestions/concerns on a post-it (We usually provide food during the retrospective as we run this over lunch period - so it's a good ice breaker, eat and think about what you're going to say)

The result??

It was amazing - the Indian team participated fully. We heard each member speak, some for the first time. People observed the rules as best as they could, and enjoyed contributing. So quite positive for this team. The second unit shared similar response, although it was much easier to get this team to speak (it's usually hard to get them to shut-up!) - but with the rules in place, even the loud-mouths had to hold their tongue, wait for their turn, etc. We also didn't end up trashing other people's ideas - and we tried to stick to the time limit. 

A lot of good stuff came out of the retrospective - I hope we can carry this forward.  To conclude, Retrospectives can be fun, but some work is required upfront to ensure that not only you as the Scrum Master gets the results you need, but also the team should leave the session having felt they've made valuable contributions, listened and paid cognisance to other people's problems and most importantly, trust the outputs of the session will create value going forward....