Get best of the week

Antipatterns of retrospective in the Agile team. Part 1

I recently calculated that over the course of several years as a Scrum Master, I spent more than 100 retrospectives in Agile teams. I want to talk about the importance of retrospective and how it reflects the situation in the team and affects its development, in this article.



A few words about me. Since 2015, I have been focusing on building happy and effective Agile teams in international companies. In addition, I enjoy doing internal training. In addition to the main work with the team, I teach Scrum Masters at the school and conduct trainings in the areas of Agile / Scrum / Agile testing. 

Since the beginning of my career as a Scrum Master, I was lucky to work directly with 10 very different and interesting teams. Each of them developed at its own unique pace and yet they had something in common - the quality of the retrospectives greatly influenced the overall effectiveness of the team. At the same time, I noticed that, in any team, a retrospective stops working sooner or later. Something happens and this most popular Inspection and Adaptation tool breaks down, i.e. ceases to help the team adapt and improve.

I systematized my observations and would like to share the 5 main antipatterns that I met in my teams. 

Within each antipattern, I want to discuss:

  • signs and causes of a certain behavior;
  • what to do Scrum to the Master and the team to correct the situation.

In the first part of the article I will talk about three antipatterns. In the second part, I will share observations about two other antipatterns, as well as my recommendations: what Scrum Masters and teams can do proactively, i.e. in advance, even before the behavior described in the article appears, so that the retrospective continues to work and be an effective tool for improvements in the team.
 

Antipattern No. 1 “Everything is fine with us”




The team holds a retrospective, but considers it a formality. The antipattern is manifested in the fact that the team, in principle, decides not to conduct a retrospective (no problems, everything is fine - why get together?). But in my practice, this case was extremely rare and the rejection of retrospective was dictated rather by other reasons. I will write a separate article about them later. In the meantime, back to how to recognize this antipattern.

Signs and reasons:

The team gathers, opens the standard activity template in retrospect (mad / sad / glad or start / stop / continue), writes down the main positive moments of the iteration and after 20-30 minutes diverges without discussing problems and the plan for improvement in the team. The team either avoids talking about problems, or convinces the Scrum of the Master and each other that there is simply nowhere to improve.
What could be the reason for this behavior?

  • The guys can sincerely believe that everything is fine with them: they deliver the product, the owner of the product is satisfied, what else is needed?
  • This is a super-cohesive team that has been working together for a long time and cannot imagine how you can become even better, because everyone in the company is equal to them.
  • I met teams whose members believed that all existing problems that were in the control or influence zone of the team had already been fixed, and the team still had nothing to do with other problems, what was the point of wasting time and discussing them again. For such problems, I even got a term - "corporate given".

What to do:

In this story, for me a lot depends on how much I, as Scrum Master, believe that everything is good in the team, or I have doubts about it.

If you have a feeling that everything is going really well in the team, you can proceed as follows:

- To offer the team in retrospect a complex question that leads out of the comfort zone. For example, "what we, as a team, can come up with to deliver 10 times more functionality than now, at the same time." Or "how can you completely get away from the manual run of the regression." For some of my teams, the second question sounded even more inadequate than the first.

The first reaction to this question is likely to be stupor and surprise, but the next step can be an interesting brainstorming, a look at the system as a whole and interesting ideas for optimizing the entire value delivery process.

- Take advantage of the opportunity for team members to get to know each other even better and pump teamwork through games. I will not dwell on the topic of games, I can only say that there are wonderful activities to work with Scrum's values, to build focus on a common goal, to build trust in a team. There are many described game formats in open sources. About those that I conducted, I share in my professional blog Scrum Masters.

Of course, games should not be completely replaced by retrospectives, but they can become a “respite” for the team, an opportunity to change the working context and look at the effectiveness of team work on the other hand.

And yet, what to do Scrum to the Master, if there is no this inner confidence that everything is fine? For this case, I have two ideas.

The first is to expand the retrospective context for the team, i.e. expand the angle of view on the situation in the team. For example, this can be achieved by adding new participants to the retrospective. I saw a lot of teams that conducted retrospectives without the participation of the owner of the product due to various circumstances (he did not want, so historically, a language barrier). For such teams, a retrospective with the participation of the product owner will take place in a completely new way. The same idea can be realized by inviting members of other related teams that are ahead or after the team in the value supply chain. One important detail - all this must be done with the consent of the team, the invited guest as a surprise will likely bring pain and distrust to the Scrum Master, than help to establish a retrospective.

The second idea is to offer Scrum to the Master or to one of the team members to collect data that they had never collected before. I have a wonderful example in my experience when analyzing the collected statistics on the number of defects found inside the sprint (namely, the trend of this metric over the last 4 sprints) led the team to very productive discussions on how to improve the quality of testing among developers and how to organize close interaction of testing and development inside the sprint. It often happens that in general the team copes well both in their feelings and in the feedback from the outside, but there are still many points for improvement, you just need to draw the attention of the team to them.

Antipattern No. 2 “Noah, we complain, there is no plan”




The story that the team readily comes to the retrospective to complain, resent, grieve, whine, but there is no plan for working with problems, like an improvement plan, as a result of the retrospective. More precisely, the team has a plan, a set of actions has been drawn up, there are responsible ones, but this plan does not help the team really improve, does not help to set up experiments and test hypotheses in order to increase work efficiency or improve product quality. This plan is rather a formality, a plan for the sake of the plan.

Signs:

  • The team vigorously discusses what is happening in the team, but there isn’t enough time to plan it, and it diverges until the next time, at best, with a list of what they plan to work with sometime later. The question of exactly who, when and how will work remains open.
  • , , , , : , - , .
  • , , 80-90% – , , , . , , . , ( , , ) , .

Let's look at how you can work with these situations.

What to do:

Let's start in order. In order for the improvement plan to appear in the team, first of all, it is necessary that the retrospective agenda (namely, all its phases - registration, collection of ideas, analysis of ideas, development of an improvement plan, completion and feedback) be transparent to the team and there is time for drawing up a plan for further action. I had cases when we did not have time to work out a plan of action deeply and then I appointed a separate session to complete the retrospective and formulate a plan. I believe that it’s better to expand the time allotted for the retrospective than to finish it on time, but exit without results.

If there are problems in the team in order to fit into the scheduled time of the meeting, there is an approach for setting several timers, for example, for 15, 8 and 5 minutes. From the very beginning, the team knows that the discussion should end by the end of the third timer and is more focused on negotiating. In general, facilitation techniques, the organization of work in small groups and a fixed time for discussions and individual phases of retrospective work wonders and help to lead to the development of solutions even for groups with complex dynamics.

So what should Scrum do to the Master if the team brings back organizational issues in retrospect and avoids real problems? There are several tools that in my experience have helped:

  • – – , , , , « , ».
  • , (, ). , . , , .
  • , , , , , . . , , - .
  • , , , , . , !

№3 « , »




The name speaks for itself - a plan was drawn up for the team, but invented actions or experiments are not performed.

Signs: The

signs of antipattern are quite obvious - in the next retrospective, the team has nothing to share as the results of the implementation of previously thought up actions or agreements. Everyone, of course, has good reasons - he didn’t have time, his hands didn’t reach, he was engaged in more important matters, he forgot. But as a result of progress in terms of improvements and experiments, no.

Speaking about this antipattern, I want to dwell on “disturbing calls” at the stage of compiling the plan, which in my practice were most often signals that actions from the plan will not be performed:

  • action items (.. ) «, , ». , , .
  • , , . , , « unit ». , , , « », « », , . «, , » .
  • , : «, , , wiki , », « / , , », «, 3 , , , », « , , , »

What am I doing in a situation where plans appear on my team that are written but not done? I recall that if people do not do something, there may be the following reasons:

1. I do not understand
2. I can not
3. I can not
4. I do not want

This thought helps me a lot to stop and think whether it is possible to exclude options “I don’t understand, I can’t, I don’t know how”, before starting to work in the field “I don’t want to” and deal with the person’s motivation, why is he on the team and what are his goals.

What to do?

Let's see what exactly can be done, depending on what is the reason for the inaction.

Reason 1: a member of the team who agreed to take on some action item really did not understand what was expected of him.

  • , .
  • , , , , .
  • , , , - . 

Reason 2: a member of the team and would be glad to fulfill the action item that he took upon himself, but physically cannot do this, because busy with other tasks and he does not have time for this in the sprint.
 
Scrum Master can add the most important activity from the plan from the retrospective to the sprint backlog (after agreeing this with the product owner on the retro or after), evaluate it, note who will do it, make it transparent to everyone that the team will spend time on this. 

Reason 3: the team member would again be glad to fulfill what he signed up for because it is really interesting and important for him (for example, to choose the most suitable framework for stress testing), but he has never dealt with this before and has never can figure out where to start. This is where he ends, as it can be unpleasant to explain to the team why he took this activity if he does not know how.

Scrum Master can check with someone who is ready to take on the activity under the retro plan, if he had to do something like this before. If not, for sure there is someone in the team more experienced in this matter who could help. And if the whole team does not have expertise in the field, the Scrum Master can take on the task of looking for experts in other teams or the community.

I have one more bonus practice, which really helps the team to fulfill the plan - hang activities from the plan in a prominent place for the team. Ideally, each team member who took some kind of activity took away a sticker with this TO DO to hang it in a prominent place on the desktop and not forget about it. They say that if the goal is in front of the eyes, a person consciously and unconsciously goes to it. I like this approach much more than regularly reminding the team that retro is approaching and worth refreshing in memory of what the plan was last time.

So, I shared my thoughts about the first three antipatterns of retrospective in Agile teams that I met in my practice, and there are two more, no less interesting and no less common antipatterns.

I will be glad to hear your stories and observations about retrospectives that work and which don't. Tell us what techniques and techniques you have for building effective retrospectives. You guess what two antipatterns I plan to tell about in the sequel?
 

More articles:


All Articles