Hi guys, this week I will talk about Agile Retrospectives AntiPatterns. As you know for the past weeks I have been writing about anti-patterns, e.g. 20 Product Owners AntiPatterns or 8 Agile, Scrum Antipatterns - Scrum Masters, now it's time to talk about Retrospectives.
[shortcake_call2action title="AGILE RETROSPECTIVE ONLINE COURSE" description="We have developed an online Agile Retrospectives Certification to help you to take your Agile Retrospectives to the next level." button_text="TAKE THE COURSE" button_link="https://www.scrummastergrowth.com/agile-retrospectives-certification-program-closed"/]
This post will be about: "Agile Retrospectives AntiPatterns". I will mention several things that you should pay attention to; it also might happen to you. These are signs that your retrospectives are ineffective.
I want to highlight that many of these ideas came up from following sources:
I saw this anti-pattern quite often. For example, in a company I worked for in the past, management requested to record Agile Retrospectives. The management expected that if people recorded the retrospectives, other teams would be able to learn with the problems of their peers.
As you can imagine the outcome was catastrophic, nobody cared, teams were busy enough with their retrospectives. The biggest problem was the fact that nobody was open to speaking about their problems if retrospectives were recorded. They knew that anyone in the organisation could listen to those sessions. Therefore no one touched on"difficult" problems.
Solution
The Agile Retrospective should be a safe place. Only team members should participate the meeting; To tackle the previous issue, action items can be displayed in public place. However, I would keep notes on the team. If the organisation is serious about knowledge sharing, they can support communities of practices. It is the much better approach for knowledge sharing than forcing people to share the outcomes with the rest of the organisation.
The team commits to an ambitious list of actions without considering whether it has time to get them done in the next iteration. This leads to disappointment because the actions do not get done and the team adds more actions to the list in every retrospective.
Solution
This anti-pattern is quite common. The solution is not difficult at all. Check another of my posts where I refer that teams should "Do small changes, and change one thing at a time".
I believe the right thing to do is simply take one topic out of your retrospectives at a time. Select a topic, but make a proper analysis of it. Thoroughly understand what the cause of the problem at hand is (you can use techniques such as the “5 Whys”) and implement the change during the next iteration.
If you follow this approach, you will allow the team to focus on one thing at a time.
The team takes five to ten minutes after their iteration demo to have a quick chat about how things have been going and calls that a retrospective. This is a sign that the team sees no benefit in retrospectives. If individuals do have ideas for improvement, they face a struggle to implement them without a forum to get support from the team.
Solution
Here the role of the Scrum Master/Agile Coach is very important. If the team does not see the value of Agile Retrospectives, maybe the coach should organise a workshop with the team to explain how and why retrospectives are very important.
In case you are the coach, take the time to tell the team how important is the Agile Retrospective, but remember, stick to what I mentioned in the previous anti-pattern: change one thing at a time. Coach the team to chose one single topic, understand the problem and implement it. Let the team see the improvement and use the momentum to reinforce the idea of how important the Agile Retrospectives are.
The team spends the retrospective grumbling about how bad things are without taking responsibility to improve the situation. This may be cathartic and release tension in the team but can quickly turn into a blame game. Retrospectives are about making changes for the better, and that cannot happen without a discussion of what the team can do.
Solution
In this situation, I like to transfer the responsibility to the team. Let them speak, but at some point ask a simple question:
"What are you going to do about the situation?"
This is usually a very powerful question. It sends a clear message to the team: if they do not do anything nothing will change. They will be trapped in their daily frustration and the crappy environment.
Usually, they wake up and try to define some actions to correct the problem, but many teams end up saying: "we cannot do anything, it´s out of our control". Do not fall into this trap! There is always something the team can do to improve the situation. Be imaginative and help the team to find their ways to solve the problem, but do not allow the retrospective to become a complaint session.
Actions discussed are rather vague with no owners such as "improve communication" or "do more refactoring". These are not actions; they are problems to work on. Without more discussion, the team does not know what to do to implement these pseudo actions.
Solution
Arrange action items in a way that they can be determined as "done" or not done. "Refactor more" is not helpful task because one cannot simply tell whether it´s done. “Improve the User model’s Code Climate grade from an F to a D” is actionable and therefore the team should take small steps that are achievable and help towards improvement. To put objective measures for instance on code quality and performance, use Code Climate, Airplane, New Relic, Airbrake or other instrumentation services.
Sometimes line managers want to attend retrospectives to understand what´s going on. They do it with the best intentions; they just want to know what the problems are to help teams to solve them.
Unfortunately, this is not a very good idea. As mentioned earlier, Agile Retrospectives are a place where team members must feel safe. This is a pre-requirement for productive retrospectives. If line managers attend the meeting, people will be afraid of speaking out.
Solution
The solution here is quite easy. All Scrum Masters can get together and create a rule that no one else than team members can attend the retrospectives. If management wants to know what´s going on in retrospectives, the Scrum Master can mention topics that will be tackled during the next sprint, but that´s it. All confidential information should remain inside the team.
This retrospective is rather an archaeological dig that results only in lists of "what went well" and "what needs improvement" but no actions. This can improve communication as the team gradually understands what's happening. But because there is no discussion about how to improve, change is left to individuals rather than planned into the next iteration.
The team members are asked to call out ideas without discussing what happened in the last iteration. This does not work because problems are glassed over. Actions may not be connected to resolving problems and tend to be about trying out cool stuff rather than fixing what is not working.
Solution
One person, not more people or a team, only one person. When the whole team is involved in an action item, find a volunteer who would enforce compliance and be the cop. If one person is not accountable, then nobody is. Also: review Action Items. Print them and place them on the team board. When they´re completed, cross them off. Review the list at next retrospective.
Unclear Action Items are useless. The trick is to make sure a verb is the first word of an Action Item. Generally, every action includes a verb. However, this verb might be insufficient in the retrospective. Everyone can understand its meaning, but afterwards might not be the case. When Action Items are viewed later, make sure that they remain actionable.
A common mistake is the fact that teams do not check if what they decided to implement did improve their situation. Teams define topics for improvement for the next sprint, but very few teams stop and analyse if their actions resulted in some improvement.
Solution
Each retrospective should start with the team reviewing the past action items. The Scrum Master should guide the team and check if the previous items are done.
Some time ago I wrote a post: "Success Criteria for Retrospectives Topics" I explain a simple concept. Each team should come up with a Success Criteria to attach to each improvement issue that comes up from each retrospective. If teams use something like this, it is very easy to check in next Agile Retrospective if the item was able to solve the problem.
It is quite common that most of the teams see the Scrum Master as the person to assign all the topics. But in reality, the Scrum Master might not be the best person to solve the problem.
Solution
Usually, the topics that result from the retrospectives are very different. I do not believe that one single person can solve all problems. I believe in teamwork, and that different people can tackle various challenges. This situation is not different, depending on the topic that appears, different people should take responsibility to address the problem.
Some sources might refer to a Scrum Master is the impediment removal. Honestly, if he takes ownership of everything, the result is a team that fully depends on the Scrum Master to solve all issues. The best approach could be to chose different people within the team to tackle various topics that come up in the retrospectives.
If you have more ideas about Agile Retrospectives Anti-Patterns, please share them with me. I would love to add them into this blog post.
[shortcake_call2action title="AGILE RETROSPECTIVE ONLINE COURSE" description="We have developed an online Agile Retrospectives Certification to help you to take your Agile Retrospectives to the next level." button_text="TAKE THE COURSE" button_link="https://www.scrummastergrowth.com/agile-retrospectives-certification-program-closed"/]