Hi guys, this blog is part of our book: "Getting Value out of Agile Retrospectives", a book written by Ben Linders and me with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it within your colleagues.
Like Rachel Davies and Liz Sedley refers in their book: "Agile Coaching", retrospectives provide a way to engage with team members in improving their processes in direct response to problems they face. Unfortunately, it is not uncommon to meet teams that have already tried retrospectives and have given up. So where is the problem? To run successful retrospectives, there are several items that need to be present, and this is the topic we want to tackle.
Norman L. Kerth refers in his book: "Project Retrospectives" five important ideas to have a successful retrospective: "The need for the ritual", "Naming the process", "Prime directive for a retrospective", "The darker side of the retrospectives" and the "Retrospective Facilitator."
Usually, humans do not stop to reflect on any project; this is not a natural activity, that's why it´s so important to formalise a behaviour and make it a ritual. Rituals are important because they serve to bring people together, allowing them to focus on what is important and to acknowledge on significant events or accomplishments. It is extremely important to not use a retrospective to identify only negative parts of a project. In each project there are positive outcomes and these should be celebrated like any other small victory.
Everyone that is involved in a project should be involved in a retrospective: a retrospective has a huge potential for learning, and it should not be limited to any of a team member. Another reason why everyone should attend is the fact that everyone sees issues in different ways. This contribution is extremely important to come up with a better approach for the future.
In our industry, retrospectives are named differently. Some of the names are: "postmortem", "post partum", "post engagement redress", etc. In Agile software development this process is called "Retrospective", nowadays this is a popular name. In my opinion, it is important to name the process in a clear way to have everyone's understanding. Usually, a team knows what it means but is not uncommon to have top management that doesn´t understand what the meaning of it is. I guess "Retrospective" is a simple and self-explanatory word.
One of the basic ingredients for a retrospective to be successful is a factor "safeness". People must feel comfortable to share their problems, opinions or concerns. It is common to realise that things were not performed in the best possible way when this happens people must feel comfortable to say things out loud and suggest different ways approach the same problem. Norman explains some techniques to create a "safe" environment within teams in his book. Additionally, Norman tells us that before starting a retrospective, we should communicate a prime directive:
"Regardless of what we discover, we must understand and truly
believe that everyone does the best job he or she could,
given what was known at the time, his or her skills and abilities,
the resources available, and the situation at hand."
I used this idea several times, and I can guarantee it works.
During my life, I had opportunities to see several retrospectives to be transformed in complain sessions. It is quite common when a retrospective is not well facilitated. It is important to understand reasons that people complain about, and this can reveal a lot of problems, but if a complain session goes out of control, it can ruin the full retrospective.
People do not do it with a bad intention. They simply exteriorise what is affecting them, they have some needs that are not being fulfilled, and they need to symbolise their emotions. The problem is the fact that a receiver is put off by the complain and immediately enters in defensive mode attacking back, this can end up in a not- productive retrospective. If all retrospectives end this way, people start to see retrospectives as useless, and they will stop attending them.
One technique that I use is to request people to express themselves in the form of "wishes" instead of accusations. This changes the tone of voice creating a "safe" environment, as it was explained above, having a safe environment is one of the most important things for a successful retrospective.
All previous topics are extremely important, yet if we do not have a good facilitator, a retrospective most likely will be a disaster. To become a good facilitator, an experience, training and a lot of self-study is required. Before starting a retrospective, the facilitator should have a clear idea of what he/she wants to get out of that session. For an experienced facilitator, this is more or less easy, but junior facilitators require help from experienced leaders. Each retrospective has different problems to be tackled; a trick is to get right exercises to attempt right problems.
My advice is to start with small projects where people know each other for some time and have already worked together. Another good option is to pair with a more experienced facilitator; this gives an opportunity to learn with a mature leader in real time. With time, people can consider larger problems and larger teams. Becoming a good facilitator takes time and effort, do not rush. Otherwise, an outcome might not be what you want.
[shortcake_call2action title="ORGANISATIONAL MASTERY SCORECARD" description="We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery." button_text="Take The Test" button_link="https://www.organisationalmastery.com/scorecard?utm_source=web&utm_medium=Blog - From Luis Goncalves&utm_campaign=scrummaster" /]
If you liked this article, feel free to visit my company Products and Services pages.
We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.
With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.