Blog

Retrospectives help teams to reflect, learn, and improve, if they are done in a good way. In this guest blog post Soumyajit Chakraborty, CEO at SoftProdigy, discusses agile retrospectives antipatterns to avoid.

For the businesses involved in the Agile Software Development patterns, the Agile Retrospectives held at the end of an iteration are one of the most useful meetings that can add a lot to your working patterns, skill, and organization of work.

Thus, the Agile Retrospectives must go well, leading to better results and a productive conclusion.

There is a lot that needs to be discussed and brought to the attention of all the team members after the end of an iteration. Thus, if things don’t go smooth, a lot of important matters can be subsided or ignored. To avoid ignoring such important factors or points of your Agile Software Development work, you need to make sure that you avoid certain anti-patterns of the Agile Retrospectives that are most often noticed.

Here is a list of such anti-patterns and why you must avoid them:

Recording The Retro For Other Teams

Generally, companies keep the retrospectives on recording for a future reference or for the other teams to learn from the discussions. This method has more of negative points than positive.

Now, the other teams that you want the retrospectives to be recorded for, might be stuck with their own work and with their own agile retrospectives. Thus, they rarely get a chance to go through the results of the retrospective that you’ve recorded. So, recording it goes all in vain.

The negative impact that this method leaves on the ongoing agile retrospective is that when the members learn that they’re being recorded, they’re not able to come out as clear and direct as they want to. So, somewhere, it forbids them to talk about the real and serious matters.

It is advised not to record an agile retrospective. What goes inside a retro must stay inside. You can note the important points manually and can share them with the other teams, if there is a dire need to. Else, keep it concealed within the meeting room.

A Continuous Complaining Session

The frustration and work stress might built up during the iteration of certain projects. The reasons can be – miscommunication during the project, lack of coordination among the team members, high level of difficulty of a project, unclarified business goals of the client, and so on.

All this frustration might pop its ugly face during the retrospectives. And with this, the retro might turn out to be all about just the complaining. Thus, as soon as the agile retrospective starts, people might start complaining, and blaming each other for the snags faced during the project iteration. If continuous complaining and blaming prevails in the session, the retrospective might not prove out to be productive. It would rather forbid new and productive ideas from being discussed.

This not only wastes a lot of your time but also builds a negative vibe among the team members. The team work might hamper in the future if the negativity grows, thus this anti-pattern for the agile retrospectives must be avoided.

To avoid it, the leaders of the retrospectives must stay quite aware. You can start the session in a way so that more focus is given on the important aspects of the iteration and the complaints and finger-pointing can be avoided.

In case the team members are facing external issues, you can either conclude that the issues are natural and nothing much can be done about them (if that’s the case) or can discuss about the solutions for the same.

If the team mates are facing troubles working with each other, you can pair them up in more friendly groups of two or three to work on a project together. Doing this might actually help take your team’s focus away from the complaints to the project’s performance and success.

The Repetitive Discussions

There can be a possibility that you’re discussing the same topics in your agile retrospectives over and over again. This can be a problem as you’re probably wasting your time and getting nothing productive out of it.

The reason behind this is that your team is still facing the same issues that it was in the last iteration. If that is the case, you must look into the matter and find a permanent solution to the problem. If the problem is external and not in the hands of any of the officials, the same must be discussed and the topic must be put out of sight.

You can also keep a clear track of all the recent retrospectives to keep a note of the discussions done in the meetings. This will help you avoid having repetitive discussions. In case a new employee joins you in the retro, you can discuss the repetitive thing with them after the retro is over so that the time of others is saved.

This way, you can avoid the topics that have already been discussed and touch the more important and fresh ones. So, your retro can be productive and beneficial.

To sum up, an agile retrospective is quite an important time for the team members to come together and discuss the whole ASD patterns and iteration. This not only helps them discuss their problems and get rid of them but also brings the issues to notice and the team can frame a better work pattern for the next iteration.

So, if you think your agile retrospectives follow some of the anti-patterns, you must start looking for them and avoid them in your next retro.

Author Bio

Soumyajit Chakraborty is the CEO at SoftProdigy. With his competent skills, he has been excelling in the IT sector for more than a decade now. He is a focused and goal-driven person who loves to share his expertise through blogging.

Avoiding Retrospective AntiPatterns

When agile retrospectives aren’t facilitated in a good way, they can do more harm than good as Soumyajit explains in this guest blog post. A good facilitator is aware of this and constantly keeps an eye open during the retrospective meeting to avoid antipatterns like the ones mentioned above.

You can use warm-up exercises to get teams ready to explore and learn. They set the stage for agile retrospectives by creating an atmosphere where team members can be open and honest about what has happened and reduce the chance that your retrospective turns into a complaining session. I also recommend to use the prime directive to remind people that the retrospective is about learning, not blaming.

Sometimes it can help to have an independent facilitator for the retrospective, someone who’s not a member of the team. Such a facilitator doesn’t not have an own agenda of improvements, but is focused on helping teams decide on those actions that are best for the team.

To prevent the same problems popping up in every retrospective, make sure that actions are defined and done. Focus on the vital few actions to keep your retrospectives effective.