Here’s how it all happened and how to avoid it.
The original article was published for GoRetro
One heck of an experience. Being a Scrum Master, I feel vulnerable when managing a chaotic situation or when the conversation becomes difficult. Many of you might have faced this situation where there are two teammates who are individually amazing, but they cannot work together. Rather than handling conflicts and identifying the actions or behaviour that might be the root cause of the dispute, they tend to focus on blaming the other person.
Inspired by Tuckman’s stages of group development, I always had the notion that storming was good, where the team could openly speak about their concerns and challenge each other but I never anticipated that, the storming phase would end up with a departing stage where one of the team members would end up resigning, and then gradually the team will proceed towards norming.
A team is always a mix of different personalities and there are few who can work together with less friction and then there are a few combinations where you can see friction even over trivial things. One of my team had one such difficult combination and it felt as if I am stuck in the storm. The cold war was gradually taking shape and in one of the retrospectives, it finally erupted.
Learning1— Open communication is a wonderful thing, but ranting while the other person is in the same room with you won’t help to diffuse the conflict. The venting actually feeds the fire with more oil. But not everybody takes it in a negative sense, I also encountered a very balanced team member who introspected and said: “Oh, I didn’t know that my behaviour was bothering you, thanks for letting me know and I will make it point to change that”. Whereas the difficult combination took the dialog exchange personally and we could see some temper issues.
I know many of you who might have been in the same place would judge this situation and recommend having team norms that help identify actions or behaviour which the team finds unacceptable and defines common norms or form team agreements around it. Believe me, this was the first thing that we did during theteam canvas activity— Define team agreements that spoke about transparency and open communication. Easier said than done. In my experience people always promise to be transparent. In reality, before team members trust each other it wont happen no matter the promises.
I observed that, though we defined the team agreements they were very generic — For example, Transparency and open communication. Every individual had their own understanding of these terms. Team agreements need to be very specific and not generic. Trust has to be built and share experiences where someone dares to share with proof they won’t be hurt.
Learning2— Rather than just mentioning being transparent, the team should define what an individual is expected to do to remain transparent. Below are some of the specific rules that the team has defined.
Keep the team informed about vacations in advance, and send calendar invites to be sure no one misses it
Update the support schedule and find a replacement during vacation
Always communicate on the team slack channel
Add enough information to tickets — stating the progress, challenges, or blockers
Although team agreements are not the magic bullet and there are still many unspoken anticipated behavioural characteristics that people must exhibit. They might help to define the expected behaviour of individual team members and what action they need to take only in certain situations. The team agreements document is a living document that needs to be updated and the team needs to be reminded about it at different intervals.
When should the team revisit the team agreements?
If individuals are not behaving as per the defined team agreements which are causing friction within the team
When a new team member is onboarded or when the team dynamics change such as promotions or off-boarding of team member
If a new action or behaviour is identified which is either causing some kind of friction and the team members should try to explore options to handle it, control it or change it.
How did the retrospective result in the resignation of one of the team members?
The storming and the cold war were going on for a couple of weeks and tension was observed during different team events. So as a Scrum Master I decided to bring these questions to the surface and let the team decide what to do next.
I chose the template — What? So What? Now What? The activity focuses on the problem (What), identifying the impact (So What), and then helps the team to come up with a conclusion about how to handle this problem to minimise the impact and resolve the issue (Now What). I customised the template and added all the questions the team found difficult to address directly but they discussed these questions in smaller groups. I also gave an opportunity to the team to add questions that I might have missed at the start of the activity.
Learning3— If a platform is provided to share feelings, some might express less, a few might do it right and the remaining might overshare or over-express. These variations can impact the conversation. Before beginning such activities the team should agree on some meeting agreements or discussion agreements.For example, The focus should remain on the action or behaviour that is causing the issues and not on the individual. Identifying expected behaviour rather than blame games. Individuals should be made aware to differentiate between observation and assumptions/interpretations.As a facilitator or moderator of such conversations, a Scrum Master should have the courage to stop the conversation if it goes beyond the agreement, asking the powerful questions to uncover the root cause. Take cooling breaks to reduce the hyperactive verbal exchanges. Make sure that everyone feels heard and valued. Do not let a single person take the stage and voice his/her opinion as teams opinion.
During the Retrospective, first few conversations went well but the temperature in the virtual call was gradually rising and it hit a high point during a discussion. The team observed some venting, big pauses, stern faces, and awkward situation. Though we came up with a list of very specific team agreements, there is a thin line between being frank and being rude. Most of us in the call experiences that the expression was rude, and blamed certain individuals. The retrospective ended with a set of action items, specific team agreements, and a bang. The next day one of the team members sent the resignation email.
I immediately went into self-doubting mode. Was the retrospective responsible for this resignation, did I choose the wrong activity, wasn’t I brave enough to interrupt the steaming conversation and wasn’t it a good idea to bring these issues to the surface. Soon to realise that the retrospective might have been the last straw that broke the camel's back but wasn’t the reason for everything that happened. If not this time it might have surfaced during some other conversation or another event but it would have strained the team further.
When I face difficult situations I make it point to introspect and retrospect after the event. List down things I could have handled differently, things I could have said or not said, collect feedback that helps me improvise. I make it point to write down these suggestion and incorporate them in my future events or meeting that I facilitate.
What I learned from the three examples
Evidently nothing, with the situation at hand and the experience, I tried my best to handle it. But the right question to be asked is, how will I handle a similar situation in future?
Based on the learning from this episode, I will be more vigilant and will try to have an open discussion with the team when I observe some rough conversations or intentional silence without delaying it. Be bold enough to interrupt when the team gets into heated conversation or when conversation becomes more of a blame game. Remind the team about meeting or team agreements when the team members do not meet them. Most importantly, I need to be mindful of not controlling the situation beyond an extend since that might hamper the the natural cycle of storming and norming within the team. Not making them relay too much on a controlled environment but making them realise their own boundaries and how to honour them in difficult situations.
Tough situations like these make it difficult for individuals to work together. As a Scrum master or leader it is important to make sure to help team members realise that situations can change and we can together make a better work environment. I would request my readers to share their experiences if they have encountered something similar.
What kind of situation did you encounter that made you feel stuck, anxious, restless or angry?
How did you handle the tough situation?
What could have been done to improve the outcome?
What was your take away?
How does it feel to be the person stuck in the storm?
Comments