This article describes some Real Life Scenarios faced by Scrum Teams during Sprint Retrospective. This article is a part of series that describes real life scenarios experienced by Scrum Teams!
Sprint Retrospective is the last Scrum Event in the Scrum Lifecycle. As the Scrum Guide says “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”
In order to increase the Quality and effectiveness, the team inspects how the Sprint went. Then the Scrum Team goes on to discuss and how to improve the way of working further. You can read more about Sprint Retrospective in this article.
Sprint Retrospective Scenario I – People are not Open and Honest During The Sprint Retrospectives
One of the most common complaints about Sprint Retrospective is that people are not honest in the Sprint Retrospectives. Because of this, they fail to bring up real issues. People also do usually do not admit that they may be contributing to some problems faced by Scrum Teams.
Snehamayee’s Perspective
Often People are not honest and open in their discussions during Sprint Retrospective. This reduces the effectiveness of this Scrum Event. In my experience some things that can help in such scenario are
- Create a safe environment – Teams will speak only when they don’t worry about being punished for having an opinion. For this to happen, please discuss before hand that what happens in Vegas stays in Vegas . In other words, encourage people to keep discussions in Sprint Retrospective strictly within the team. Help the team members to realize that they should NOT repeat these discussions verbatim to outsiders. If any scrum Team member is not following this directive, a private word before the next
- Consider allowing anonymous feedbacks for a short while . Personally I do not like the idea of anonymous feedback since it violates Transparency. However I have seen that sometimes the Scrum Team environment is so fraught with emotional issues that it is nearly impossible to get a open discussion. In such a case, it may help to allow anonymous feedback for a very short while. It is important to keep this anonymous feedback about recommendations and not accusations 😊. Also, efforts should be made to encourage open face to face discussions as soon as possible. Encouraging some team bonding activities may help with breaking the ice.
- Coach the team members to enable constructive feedback The Sprint retrospective is indeed about criticism however the Scrum Event is not about individual accusations but about positive possibilities. Encourage the Scrum Team members to give the criticisms along with positive suggestions . This will help to focus on the action plan rather than a blame game.
Sprint Retrospective Scenario II – Scrum Team wants to skip the Sprint Retrospective
Often Scrum Team complains that the time spent in Sprint Retrospective is wasted. Then,they do not want to continue conducting the Sprint Retrospective.
Snehamayee’s Perspective
Sprint Retrospective is designed to explore interaction between people. Since Sprint Retrospective does not add direct quantifiable value to increment, often people undervalue this Scrum Event. Also Scrum Teams sometimes find the Sprint Retrospective a little uncomfortable .
With these factors, Scrum Teams sometimes do not find direct measurable value from the time spent during Sprint Retrospectives and often want to skip this Scrum Event. Of course, when Scrum Teams skip any essential element of the framework you are really not doing Scrum. This is because, when we skip any element we are often hiding a bigger problem. Same holds true with Sprint Retrospective. When we skip the event we lose the opportunity to look within ourselves and identify some wrong patterns or practices that we may be supporting without meaning to
If the Scrum Teams are not finding value within Sprint Retrospective, some possible things to try can be
- Educate why – If your teams are new to Scrum way of working, educating them on how Sprint Retrospective helps and why you should not implement partial Scrum will help.
- Track the improvement items – Sometimes Scrum Team sees that they discuss the same improvement items Sprint after Sprint without any real progress shown on the ground. As a result, the Scrum Team loses interest in conducting the Sprint Retrospective. Identifying actionable items and tracking them to closure will make people more interested in conducting Sprint Retrospectives
- Conduct Focus Retrospective – A focus retrospective is a Sprint Retrospective Event dedicated to discussing why the team feels there is a no value in Sprint Retrospective. what can be adverse effects of skipping the Sprint Retrospective and how to ensure effective Sprint Retrospective. Such a session can often result in vary interesting and informative insights.
Sprint Retrospective Scenario III – Scrum Team does not Product Owner to attend the Sprint Retrospective
Especially in a customer supplier environment, often the product owner is from the customer side. Whereas, the Developers and the Scrum Master are usually from the supplier side. Even though technically all 3 parties the Developers, the Scrum Master and the Product Owner are part of the same “Scrum Team”, the internal lines of division are quite prominent in such a case. This can make the rest of Scrum Team a little bit uncomfortable with the Product Owner. Because of this discomfort they then prefer to leave Product Owner out of Sprint Retrospective so that they may discuss the issues openly
Snehamayee’s Perspective
I have seen this discomfort between “customer” and “supplier” teams quite often in my career. This discomfort for the people from two different organizations impacts their ability to work together effectively. Some ways I try to help such teams are
- Educate the Scrum Team – Sometimes it helps to educate the team and help them to see that true improvement cannot be brought in unless all the parties who are contributing to the problem are present in sprint retrospective
- Encourage the Scrum Team to be a single unit – In a vendor supplier environment specifically, I have often found it helpful to coach the scrum team on the points of transparency as well as respective each other – often the developers may not be completely transparent with the product owner. At the same time in many cases, product owner is quite pushy with the developers. Working with the scrum team and investigating why this is happening is often helpful. The reasons may lie in the cultural differences between organizations, contracts that are harsh and punitive etc.
- Coach the Product Owner to be more available during the day to day work – Open the product owner is a stranger to the developers and does not spend much time in day to day activities as the sprint progresses. The Developers then think of the Product Owner as an outsider. In order to avoid this, I usually encourage the product owner to spend enough time with the developer during the day to day activities when the pressure of finding ways to improve is not there. These interactions help to integrate the product owner as a part of the scrum team and both the parties that is the product owner as well as the developers see each other as just somebody who wants to do what is ultimately in the best interest of the product
- Encourage the Scrum Team members to get to know each Other – Sometimes even the small things like the ice breakers or after works team get togethers help the scrum team members become more comfortable with each other. This reflects well into their day to day work as well as the sprinter prospective