This turned out to be a topic that is taking more than a single post. The initial post (Team does not want to do a retrospective) talked about a team where the team members stated that they felt that they felt that there was no need for them do a retrospective at the end of every Sprint session since the Sprint cycles were short, and the team had come to a decision about stopping the retrospectives. As a result of this discussion, I got some feedback which caused me to put out another post (Team does not want to do a restrospective). In this post, I talked about some queries that the Scrum Master could have for the members of the Scrum team in terms of determining how they will make improvements, about their measurements of velocity and so on. I got some more feedback from people and hence here is another post with more information on this topic.
One of the biggest problems with retrospectives is that it is primarily seen as a way of determining the problems that are happening in the project and in the Sprint, as an issue resolution forum. This is the feedback from many of the team members of different Scrum teams, and I was reminded in a separate email about some of the other items that a retrospective should discuss in order to improve the functioning of the team at all levels. However, I have seen cases where some of these items do not happen in a retrospective; this could be primarily that the team has not thought about this or does not have a good way to figure out the solutions or improvements for such solutions.
– The most important way for the team to consider is that a retrospective is meant to showcase a process of continuous improvement; for this, it is required that a team comes to the retrospective every time with a thought about what can be done to improve the situation. One cannot say that there has been improvement and now everything is done, since the continuous improvement means that the team members need to keep on thinking about what else can be done.
– Need to figure out whether the team is constantly reviewing their technical practices to see where improvements can be made and whether specific people in the team take on the responsibility of driving the team in this regard.
– Their relationship with the Product Owner. One of the issues that causes the most problems with regard to productivity is the relationship with the Product Owner. Do they have a good working relationship with the Product Owner, do they find problems during the estimation session which could be improved or ways to improve the relationship. There can be numerous such ways to improve the relationship and the team should be thinking of all such ways.
– Looking at their accuracy in achieving the Sprint goals when they reach the end. The team needs to be constantly reviewing where they are with respect to their goals for the Sprint, were there problems in achieving such goals, how do they figure out whether the goals they achieved were actually an under-achievement and they could do better.
There are numerous such items that the team should be looking for in terms of the retrospective, and it is the responsibility of the Scrum Master and also the Scrum team to ensure that the team is also thinking of all these points.
Read more about this in the next post (Scrum team does not want to do a retrospective)