Sometimes no matter how fun you make a retrospective, the team may get comfortable, leading to complacency if things feel they can’t get any better.
How can this happen? People feel that there is no need for improvement. So retrospectives become dead air; no matter how many tricks and tools are used to get someone to s, ay something, they feel there is nothing more to say.
Looking at the title, there are probably thoughts that you need to sabotage a sprint to get people to talk purposely. That is not the case. What happened with a team was the Scrum Master was taking time off when the sprint was about to start and worked with the team to have the sprint ready before he left.
This is where the complacency took effect. Everyone took the work into the sprint without a thought of what was going in because the team reviewed the tickets a couple of weeks earlier, everything was estimated, and they all had the initial plan to deal with them. So they thought.
The sprint started, and things were just off. Like that feeling, a big storm is coming, but it is nice and sunny outside. Nothing slowed down, yet nobody spoke up or dealt with it effectively.
When the Scrum Master returned, there was some uneasiness about the lack of participation. Getting to the bottom of it one on one chats were scheduled with each member of the team. Part to get information on each member’s well-being while understanding the lack of participation.
Using clean language questions, the Scrum Master could discover why the complacency: Previous successes got to their heads. Each team member mentioned how they felt about the current sprint and were surprised that it happened during the discussion. There were bits of information about improvements among team members, yet they felt that they didn’t need to share with the team thinking that it would occur organically. Still, the sprint suffered.
That is where the Scrum Master realized that the sprint was unintentionally torpedoed. The work was getting done, and the throughput was high. Unfortunately, they could not complete everything they committed to in the sprint.
When it came time for the retro, the participation was there. The team discussed everything that happened, determined what could be changed, understood the flow more, and in the end, they were re-invigorated to be an evolving team.
At the end of the retro, the Scrum Master thanked everyone for the participation and reconfirmed that they needed to celebrate the good as well. He talked about things that came up in the one-on-one chats that implicitly benefited the team and that there needs to be that was well when we conduct retrospectives.
Getting people to talk can be difficult, and finding areas of improvement when things are going well is even more challenging. The following sprint had a different vibe; the complacency was not there. The flow of communication between everyone was there. Should a Scrum master torpedo a sprint? NO.
Find the root cause. An excellent tool to find out how the feelings of the team and get ahead of the issues is the use of one-on-one and having the right questions to get ahead of the problems. Clean Language helped in this situation. There could be other techniques; it all depends on the team and the individuals.
So when the feeling of that storm comes in while everything looks nice, it is time to jump to avoid that torpedo from hitting.