Hi guys, for past weeks I have been writing about anti-patterns, e.g. 20 Product Owners AntiPatterns or 8 Agile, Scrum Antipatterns - Scrum Masters.
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:
- Agile Coaching by Rachel Davies and Liz Sedley
- http://pivotallabs.com/retro-
best-practices/
WHAT HAPPENS IN RETRO, DOES NOT STAY IN RETRO
I saw this anti-pattern quite often. For example in, a company I worked for in 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 really cared, teams were busy enough with their own retrospectives. The biggest problem was the fact that nobody was open to speak about their problems if retrospectives were recorded. They knew that anyone in the organization could listen to those sessions, therefore no one really 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 within the team. If the organization is serious about knowledge sharing, they can support communities of practices. It is much better approach for knowledge sharing than forcing people to share the outcomes with the rest of the organisation.
CHANGE THE WORLD
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 root 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.
NO TIME TO IMPROVE
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 organize a workshop with the team to explain how and why retrospectives are very important. See following posts about this topic:
- “16 Simple Ways to Explain what an Agile Retrospective is“
- “7 Brilliant benefits of Agile Retrospectives“
In case you are the coach, take the time to explain 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.
NO RESPONSABILITY IS TAKEN
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 easily 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 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 in order to improve the situation. Be imaginative and help the team to find their own ways to solve the problem, but do not allow the retrospective to become a complaint session.
WISHFUL THINKING
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 really 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, Errplane, New Relic, Airbrake or other instrumentation services.
LINE MANAGERS WANT TO ATTEND
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 in order to help teams to solve them.
Unfortunately, this is not a great 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 really 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.
HISTORY LESSONS AND IDEAS FEST
This retrospective is rather an archeological 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. In addition: 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. Normally, 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.
NO REVIEW OF PAST ACTION ITEMS
A common mistake is the fact that teams do not check if what they decided to implement did actually improve their situation. Teams define topics for improvement for the next sprint, but very few teams actually stop and analyze if their actions actually 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 topic 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.
OFTEN ACTION ITEMS ARE AUTOMATICALLY ASSIGNED TO SCRUM MASTER
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 team work and that different people can tackle various problems. This situation is not different, depending on the topic that appears, different people should take responsibility to tackle the problem.
Some sources might refer a Scrum Master is the impediment removal. Honestly, if he takes an ownership of everything, the end 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 different 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.
I hope they are useful for you!
All the best
Luis
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.
Thanks Eric :)
See you in few months :P Do not forget me and Veronika :P We are counting on the big van :P
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
Thanks for your comment. I will update the article later on ;)
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.
Thanks Kamil :)
You can always download our book for free: https://leanpub.com/gettingvalueoutofagileretrospectives this book will give you plenty of exercises to spice up your retro.
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.
Thanks James, so you mean the Product Owner should be part of the Retrospective right? :)
Excellent work, Luis. I’ve seen many of these myself.
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:
“pietrotull.com/2015/02/05/should-managers-attend-retros/”