Retrospectives, one of the most popular ceremonies in Scrum, is also the most abused. As per the Scrum Guide, the purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process,and tools;
- Identify and order the major items that went well and potential improvements; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work
As we know, the retrospective is all about the Inspect and adapt cycle, which is also the foundation for the empirical process control.
However, my observation of a typical retrospective of many teams looks like the one in the diagram shown below:
Apart from the overall broken process, team members write a very twitterish description on the post-it something like the one shown in the screenshot below:
Even if you show the above post-it to the authors after a sprint, they won’t be able to recollect what the hell was this about !! have you come across this in your teams ?
I understand that the description is supposed to be short/sweet, mostly for discussion. However, it shouldn’t be too short that, you can’t discuss it in the future!
Keeping the inspect-adapt cycle in mind, I have come up with a draft model(shown below) that could be experimented to improve the effectiveness of the retrospective.
Key changes in the proposed-model are:
- Doing safety-check ins. . Check this article to learn more about Check-ins. I know most of you might be doing it already.
- Additionally, I like people sharing their stories and narratives rather than just dumping twitterish words on the post-its. So, let everyone tell their stories, listen to each other and take notes. If I am telling the story, I would recommend someone else to take notes, write it on a post-it with points connecting the stories.
- Look at the patterns of challenges arising out of previous retrospectives and do a root cause analysis.
- Of course, as part of the adaptation, the improvement should not do quick fixes. The actions should look from the systemic perspective.
- Large-Scale Scrum(LeSS) recommends teams to do Causal Loop Modelling to understand the impact of their actions on overall system.
- It is very important not to forget ask “Are we improving ?”
Feel free to share your thoughts and what did you like about the draft model ?
You can use the above model in addition to the info in these highly recommend books:
Before I end this post, here are my upcoming Certified LeSS Practitioner trainings in Sydney, Melbourne and Brisbane. You can register for these courses using the links below:
- March 26th-28th ’18: Sydney: Certified LeSS Practitioner From Principles to Practices
- April 23rd-25th ’18: Melbourne: Certified LeSS Practitioner From Principles to Practices
- May 21st-23rd ’18: Brisbane: Certified LeSS Practitioner From Principles to Practices