If it is true that Scum Masters must know how to be heard, sometimes high and loud, in order to protect their teams, then they must also learn to be quiet and above all to listen. In many teams and organizations, individuals talk, but they don’t listen to one another. Each one tries to be heard, to express his/her point of view, to show that he/she exists.As Scrum Masters, when the team begins a project, we tend to be at the forefront, to talk in order to explain Scrum, to conduct meetings, to guide the team through the ceremonies, to keep track of what is going on during the Daily Scrums. In brief, we tend to be quite present and directive. However, after a few iterations, the team should know enough about the mechanics to have gained certain reflexes. Then, you should be able to withdraw yourself symbolically in order to let the team self-organize.
This token withdrawal is, for my part, the moment to go from noise to silence, from speech to listening, to prefer questions to instructions.
Everybody will tell you; I love to talk, to help teams, to explain, to share my ideas, values, and knowledge. However, I realized something that is very important. Watch out, it’s a scoop… Silence is golden!
During the team’s Daily Scrum, as the Scrum Master, I like to stand in a corner, stay in the background, and listen. I don’t sleep; I actually make sure that the allocated time is being respected. And I may step in if there are questions. I also take notes, for instance, on any points on which I would like to question the team (e.g. a task that seems to have appeared, but has not been created; a task that is blocked; a behaviour that I notice). Of course, I still take part in the team’s synchronization as well as in the transmission of relevant information. Sometimes I use my notes at the end of the Daily Scrum, once every team member has talked, to ask questions, to have the team become aware of certain facts or behaviours… Some other times I keep my notes to myself for a few days to take the time to verify if the fact or behaviour is recurring or to let the team experiment with the difficulty related to their behaviour, etc.
Of course, it’s all a matter of striking the right balance. I do not let the team get tangled up in difficulties that are too serious. Over time, I noticed that, when I adopt this quiet behaviour with an experienced team followed by relevant questions, they tend to wait for the question, to seek for feedback from which they are learning things, and they adapt their behaviour to improve themselves in small steps.
When I’m working in a team that is beginning with Scrum, I must be more directive. However, with a well-functioning team (after a few sprints), this way of doing becomes counterproductive and it slows down their work. In fact, the team adopts an attitude in which they expect to be directed, to be corrected whenever there is any little glitch. Thus, they do not take the time to observe and think about their attitude. Neither do they have the “opportunity” to make simple mistakes allowing them to learn from them when brought back as feedback.
I am not inventing anything. I am simply sharing my actual experience, which is ultimately illustrating what the literature says.
I’m interested in your experience. Are you a talkative Scrum Master or a rather quiet and responsive one? What changes of behaviour are you observing in your team when you change your own behaviour?
Note: To listen, one must accept silence. Here are two simple tricks not to break silence: count in your head or keep a pen in your mouth (if you open it, the pen falls).
No Comment