Last updated on | Agile Retrospectives

9 Deadly Agile Retrospectives AntiPatterns Every ScrumMaster Must Avoid

by Luís Gonçalves
Agile Retrospectives AntiPatterns

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.


We have developed an online Agile Retrospectives Certification to help you to take your Agile Retrospectives to the next level.


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.

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.

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.

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.

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.

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.

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.

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.

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.

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.


We have developed an online Agile Retrospectives Certification to help you to take your Agile Retrospectives to the next level.




Rate this post:
Luís Gonçalves

About Luís Gonçalves

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker that works exclusively with Senior Executives of 7 to 8 figure businesses on the deployment of his game changing ‘Organisational Mastery’ Methodology.


Share your point of view

  1. The worst anti-pattern is when they see them as a waste of time and stop having them. Likely as a result of one or more of the patterns you list. Nice post, Luis.

  2. Awesome collection and I fully agree with all listed anti patterns. Imho it’s on of the major topics for an Agile Coach/ScrumMaster to always improve the retrospective. This list will help for sure.

    Some anti patterns to add from my side:
    * No idea how to execute the change in the next iteration.

    Beside adding responsibility there should also be a rough size overview and an understanding what the change really is about. At the end its about using changes that matter and a focussed negotiation with the PO should be possible, having a clear team commitment and the picture how it fits to a common goal.

    * Flaw in moderation techniques – the ScrumMaster as facilitator of this meeting must have skills in moderating, as you guide a team through a tough meeting and you can really waste a lot of time and energy using boring and just plain wrong methods. Suggestion: Read your book to get to new exercises, attend moderation trainings, learn visual facilitation, invent your own retro games and share it

    * BORING retros – always the same? To foster creative thinking you need to challenge, change perspectives and enable hunch connections. Suggestion: Inject something not predictable, some fun – but the same time do not overload the team always with new games … balance 😉

    Well done Luis – THANKS for sharing

  3. Nice post, read it with pleasure! I will second what Sebastian wrote, especially about BORING retros. Since stagnation can grow (potentially) undiscovered over time it can also easy prevail for a long time, until someone brigs it up into the light.

  4. No Product Owner in the retros. The retrospective is about improving our process and the Product Owner plays a key part on the team. We opted out of story grooming sessions and have a post-standup (15 minutes after standup) for any extra items to discuss but mainly for grooming.

    This benefited everyone on the Scrum team.

  5. Hey

    Nice list, but I must say I disagree about line-managers attending retrospectives. If the team does not feel safe with the managers present then the solution of leaving the managers out seems like just treating the symptoms instead of tacking the real underlying problem: lack of trust.

    Building that trust may take x amount of retrospectives and I would not recommend having them present every time and a retro with trust issues is definitely much harder to facilitate, but firmly believe it pays in the end. If you face such a situation, then it really pays of the get a neutral facilitator whose impartial to the team and manager.

    Also I don’t think manager’s can take proper action if they are only treated to a list of topics the retro was about, but they also need to understand the reasons behind these topics/solutions and taking part in the retro is by far the best way to do it.

    The retros are place place for improvement and improving the communication between the team and management is as important as anything.

    This answer was getting mighty long so I decided to blog the full answer here:

  6. Hi Luis,
    Will you please share few examples on testing specific discussion (from your practical experience)? I am in the process of creating a training program and need some practical examples in terms of how a person playing Agile Tester role can make effective contributions in the Retrospective meetings. Appreciate if you will send your response to my email address ([email protected]).

    Thanks for sharing your post. A good one.

  7. What if the blaming game has already began? I have been in such retros, where the team is asked to list their problems and what went not so good, so everything they put on the table is: “The PO does not write good stories”, “The business owners are changing priorities too fast”, “We have started something in one sprint, but continued with other in the next” and so on. I don’t say they are not right and some of these problems really exist, the thing here is they list only “external” issues and think their job as dev team is perfect and does not need improvement… So, after listening all of these, I as a coach try to ask some questions like: “What are you going to do about this?” or “Do you think we can improve the code quality”, “Do you think we can reduce the number of bugs/regressions which are opened every sprint?” But the result is still the same, either they say there is no problem or they say that they can not do anything about this, because the problem cause is somewhere external. It would be very interesting to me to see your point of view about such situation.

  8. I think this point is a bit to wide “LINE MANAGERS WANT TO ATTEND”. If line managers attend to solve problems the team and the team wants you can invite them. But if the team is not sharing their what they think in the retrospective you lack of transparency and courage.

    If you don’t invite them because the team is afraid of them, then you’re just covering a more important problem between your team and the line manager. I think that in that case is good to clean up the problem if the line manager is open to get feedback.

    For some teams would be a good idea for other not… but not an antipatern

    1. Thanks for your input…

      I still believe that 99% of organisations are not prepared to have managers there…

      Of course, if there is no trust is a much deeper problem, but I am focusing in Agile Retrospectives in this article and invite them might have a very destructive effect.

      So before you have a mature team and organisation, keep the managers out.


  9. Good article. Toughest nut of all is the “Line Managers” antipattern. From my experience, this can also be mitigated once the team is mature enough to be less emotionally attached to the problems of a sprint.

  10. Sometimes I get aggravated with the all the “rules” imposed for the sake of perceived beneficial Agile rituals… I’m a manager… I attend the retros. To think that it’s “not safe” to have a manager attend and participate in the process improvement discussions is pretty messed up if you think about it… what kind of hostile work environment is this? Wouldn’t the ideal be that the manager is part of the team? Is a manager’s perspective not valuable? Not having them there just reinforces an us vs. them mentality with management – and perpetuates fear. I would not want to work somewhere that I couldn’t talk “safely” in front of my manager. I get the reality to why this is suggested – but my advice would be to INVITE the manager there and after a potentially awkward retro or two, people will start speaking out and ultimately have a better relationship with their managers and possibly get some insight that they might not have heard otherwise….