“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”
– 12th Principle, Agile Manifesto
It doesn’t need any explanation why Retrospectives are important in any scrum team. Question is, how can we make Retrospective Sessions more effective.
I was in conversation with a friend recently and one of the things he said he is running into trouble with is that the team members attempt to blame each other rather than getting to root of issues during retrospective.
To start with, key lies in making it more transparent. That doesn’t mean you need to document and publish it to anyone outside the team to view it. That is effectively an anti-pattern that plagues the success of retrospective. Unless the team members believes that what happens during the retrospective lies within the team, they wouldn’t be open with their opinions. This is the same reason why Line-Managers should be kept away from such meetings.
Care should also be taken to ensure the meeting doesn’t end up as a blame game, which is why the role of Scrum Master becomes critical, in the way he facilitates the meeting. The idea should be generate positive energy and responsibility, rather than a blame game that ends up depressing and energy draining.
Sprint Retrospective’s are usually revolved around 3 key questions
- What went well ?
- What did not go well ?
- What can be improved ?
If the Scrum Master feels the questions are too broader for team to answer, he could employ exercises like the StarFish in the retrospective. The Starfish focuses on 5 Questions, instead of 3.
- Stop Doing : Focus on things which are not doing any benefits for the team, and rather is getting on the way
- Start Doing : Focus on new things which can add value to team
- Continue Doing : Recognize things which is working well, and team should continue doing.
- Do more often : Recognize things which is working well for team and could do team more good if done more frequently
- Reduce Doing : Recognize things which is working well, but could reduce the frequency a bit.
The key however lies on finding the root cause, for example for things that you have chosen to stop doing completely. The team need to understand why it is not working. For this the Scrum Master could employ methods like the 5 Whys.
5 Why’s is a root cause analysis technique that focuses on getting to the root of any problem by repeatedly asking “Why”. Each answer would form the basis of next question. You could read more on the 5 Whys in Wikipedia.