Sprint Retrospective – A real story
Sprint Retrospective – “Oh there’s nothing cool in this”, “it’s a waste of time” if that’s your opinion then I believe this post might be an interesting read for you.
I am going to share a real life story of conducting a sprint retrospective for a new team in a non-scrum environment. The story has challenges, tense situations and an outcome which was interesting and unanimous within the team.
Before we start, for those who are thinking, what is a sprint retrospective, here’s a short explanation
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning Meeting. This is a three-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints.
This was a 7 member team with experience range of 4 to 15 years. The team on one hand was a good mixture of youth and experienced members while on the other it had members ranging from very aggressive to shy.
The team was new to scrum and was clearly struggling to implement it in entirety. However they had started conducting daily scrum meetings regularly for more than 3 months. The max duration for a daily scrum meeting is 15 minutes, instead this team was carrying out their daily scrum meetings for more than 45 mins regularly and sometimes 60-90 minutes. This is insane isn’t it? What are they debating/arguing/discussing on for so long ? Does it have a outcome ? If not, then why are other team members silent ? Why is the scrum master not intervening ?
Looking at the organogram I got my answers(I believe by now, you too would have guessed it). Well, Lets get back to our story…
The Scrum master had to act quickly as his attempts to contain the problem look to have failed. In addition, it was a perfect opportunity to start teams first ever “Sprint Retrospective Meeting” thereby aligning more to scrum and in turn resolve the issue which is plagued the team for long.
Now the question for the scrum master was “How to conduct the retrospective without creating a bizarre situation like that of daily scrum”? There are quite a lot of techniques and one of them is Mute Mapping where everyone is on mute as the team members write their feedback on index papers/sticky notes, these are then posted on board for further grouping and voting which then evolve into an outcome of the retrospective thereby giving a direction for improvement in next sprint.
The scrum master of this team conducted the sprint retrospective and used Mute mapping technique, the advantage of this technique is that it has power to silence the most aggressive and prevent the meeting from being polarized in one direction, while at the same time, the most shy person gets the opportunity to raise his/her concerns.
Now, following was the outcome of the sprint retrospective
Improvement Area : Human Behavior during daily scrum” (majority votes)
Action Point :
- The team agreed that if any topic of discussion is going to consume the entire daily scrum meeting time then he/she should announce a separate meeting for such topics in the daily scrum.
- Any team member having problems with anything within the project should also make efforts to find the solution around the problems, the best solution can then be chosen through discussion.
- Every individual should understand and respect time of others and act accordingly.
The above action points gave the following advantages
- Although “Human Behavior during daily scrum” is a bit vague and difficult to chalk a plan of improvement around it but through this the “difficult” team members got to know that most are not interested in the topics being discussed in daily scrum.
- Since the agreement was to announce a meeting, the team members have to set the agenda for the meeting, this means that the team member needs to be constructive to derive an outcome from the meeting and eliminates futile/pointless topic from teams perspective(may be important from 1 – 1 perspective but not from teams perspective). The announcement of a meeting also allows the interested team members to join.
The team is now consistently closing the daily scrum meeting in about 15 mins and occasionally shooting to 20-25 mins (better than earlier, isn’t it).
This experience to me suggests that conducting sprint retrospective is just one aspect, even more difficult and important is to choose a technique for conducting a retrospective.
In my opinion rather than experimenting with some randomly selected technique, understand the situation at hand and then choose a technique as it helps in running the retrospective meeting effectively.
Additionally we can try to retrospect ourself as we head into 2014, a new year with a plan of improvement to be better, to be more successful in 2014.
Finally, I would like to say that conducting effective Sprint Retrospective in an art, with practice and participations we can look to learn it.
References :
Agile Retrospectives: Making Good Teams Great
DISCLAIMER : The views, opinions and information compiled in this blog are completely mine and has nothing to do with any of my previous, current or future employers
[…] Sprint Retrospective – A real story (softwarecookie.wordpress.com) […]
Thank you for sharing this with me!, Great job addressing the issue head-on and getting the desired outcome.