Tuesday 18 June 2013

Retrospectives : the most challenging part of the scrum life cycle can be made easy with "TRUST" in the team 

In the scrum life cycle I believe retrospective is the most important and challenging part as this is the stage in the iteration, where people have to say their heart out and let the team know how do they feel about the iteration that went by ? what according to them went well? what went wrong? what is that they still would like to continue? What is that they think was a blocker and should be stopped( it may be a tool /process etc.. ) This is the stage where we know how to further improve ourselves continuously taking the feedback from the team. What is there that we have still not tried and can bring wonders to the team environment and hence further increase the quality of work and may affect the velocity as well!! This makes it critical for everyone to understand that it’s the time when all the members need to speak with no hesitations in mind, otherwise retrospective will lose its purpose, everyone in the team should take it as a sacred ground to share what they feel.

Its human that people usually don’t want to add or say things at first go thinking that someone else will add that point and why should they( WHY ME ?) , especially if there is a negative feedback to share or a point that he /she did not  find comfortable with while working during the iteration. It is obvious that people only speak in retrospectives when they feel that they are safe…
Here is where “TRUST” comes into picture, unless and until team members will have a trust on each other in the team, retrospectives can’t be successful! It is important that people understand and are sure of the fact , that even if they share something negative about a specific thing in the iteration, it will be taken in a healthy way by the other team members and the everyone will try to find out a solution for the same as ONE TEAM or maybe someone from the team would present it in a way that the misconceptions are resolved about a specific theory.

There are histories of project tumbling over in spite of the fact that they had the most technical people in their team and one of the key reasons shown up is NO TRUST amongst them.

Building trust amongst team members though is not very easy, but the most important task to be performed and the Scrum Master plays a vital role in it. He is the one who is responsible and ensures that team and its environment is healthy.
Here are some of the symptoms shown by such teams with decreasing trust amongst its team members:
Members will stop taking initiatives
Negative vibes in the team everywhere
Members are disinterested what others say during the daily scrums
Members will stop to provide their inputs during retrospectives

It is very important to sense these symptoms on time, and the corrective actions also need to be taken.
Team building exercises have proven very helpful, in such scenarios, group coffee breaks and lunches is also a good option … Involving people in trust building exercises is also a solution … It is very critical to understand here that we all are humans and feel bad of personal negative comments passed by someone , at this point scrum master needs to intervene to make the situation light …these are very sensitive issues and it’s the time when he explains to the members that lets not miss the opportunity by the means of retrospective to know each other better rather than getting into conflicts…

Since retrospective is the time to be happy as we successfully reach at the end of the iteration, it can be celebrated, team members can join for a retro supper..
“thanks to you” is another event that can be very motivating for the individuals in the team, when they receive a thank you note from someone within the team for the tasks performed during the iteration or help provided, or from higher management..

Also there are no rights and wrongs for the retrospectives. You just can’t copy the exact template of it from some other project as your team is another unique set of members and every other rule may not apply. As Agile always emphasize on the fact that you can’t force upon on team, similar is the case here... do as you think is most fruitful to you maintaining the TRUST... 

No comments:

Post a Comment