In my experience, there are two ways to deal with this.
- Call them on their behaviour
- Create a retrospective that attracts the behaviour you seek
Call the scrum team on their behaviour
The primary objective of a sprint retrospective is to help the team find ways to improve.
It is important to remind the team that their primary objective is to identify what needs changing or improving with the goal of making the upcoming sprint more effective. Blaming each other doesn’t achieve that, and it’s worth pointing that out.
I would go as far as to highlight that blaming one another and pointing fingers without trying to resolve the problem isn’t good behaviour and isn’t good manners. It isn’t respectful, nor is it in any way productive for the team.
We work with talented, intelligent, and competent people. Our duty is to treat one another with respect and create environments where people can thrive. It isn’t productive or acceptable for us to behave like entitled kids in a schoolyard.
It really matters that you shine a light on this.
Remind the team that they are all great people attempting difficult yet valuable work. They need to learn how to cooperate, collaborate and solve problems in a respectful and professional manner.
As a leader within the #scrumteam, an agile coach should have the degree of respect and influence necessary to make this intervention count. Calling people on their behaviour and insisting on a more professional working environment should arrest the behaviour and empower the team to explore how they might resolve their differences in a more productive and professional manner.
That’s step one.
Once you have agreement from the team that the current state of affairs does not meet the standard required, you can move on to creating a structure and format for the retrospective that actively engages the team, draws out insights, and allows the team to identify opportunities for improvement.
Create a retrospective that attracts the behaviour you seek
The only good thing about people blaming other people is that they have strong opinions on what isn’t working in the team environment. They may not be expressing that productively, but they do have a finger on the pulse of the problem, and you can transform blame into constructive criticism that allows the team to understand the problem.
Create an exercise that allows the team to highlight problem areas without assigning blame for the problem. We accept that there is a problem and our goal is to resolve that problem without assigning blame.
We can identify who is best placed to solve the problem, and we can also identify what kind of support and resources they will need to resolve the problem. It doesn’t matter if someone failed in the past; we are there to identify who can pick it up and run with it from this point onward.
Kicking off with 10 minutes of silence that allows each individual to write down their thoughts and express their concerns, insights, and recommendations is a great way to start.
People aren’t getting caught up in emotion because they aren’t hearing anything to spark them off.
They have an opportunity to get things off their chest, and the team have a productive way of gathering information, data, insights and recommendations to discuss.
Transform the feedback into a constructive conversation
Now that you have identified the problems and allowed people to express their thoughts quietly and anonymously, we can all agree that a problem exists and commit to solving that problem effectively.
Remember that developers are great problem solvers. If we look at the problem and help the team to understand why it is a problem, we can facilitate conversations that allow us to understand what action is necessary to resolve the issue and commit to taking that action.
A team of bright, creative, and collaborative individuals working together to solve an issue will likely lead to some great recommendations. As the conversation becomes constructive and positive, the tension in the team melts, and people instinctively look to contribute as effectively as they can.
Retrospective Prime Directive
Lead the retrospective by reminding the team that although there is a problem that needs to be resolved, there is no doubt that people in the team have done the best they can. Remind them that nobody truly believes that people are out to sabotage the team or their efforts.
Sometimes, things simply go wrong. At other times, they break and need to be fixed.
That is where we are. In a place where we have identified an opportunity for improvement and will collectively transform that problem into an opportunity for the team to thrive in the future.
Given the skills people had, the information at their disposal, the available knowledge, and the intention present, people did their best. Now, we have the opportunity to build on that and do better with the benefit of hindsight, data, collective knowledge and coaching support.
You should now see the attitude in the room change from blame and fear to a place where people can contribute meaningfully to resolving problems and creating an environment that fosters greater psychological safety for the team.
Facilitate difficult conversations
I can point out that something happened, but I can’t kick off by pointing out that someone is to blame. I can remind the team that we all have moments where it comes undone or when personal matters interfere with professional matters.
We don’t know why someone may have dropped the ball, but we do need to discuss the impact of that mistake or neglect, and we need to help everyone understand why it is important to correct the mistake or prevent it from happening in the future.
Sometimes, two individuals will be at each other’s throats because of frustration or misunderstandings. You need to pull them aside and facilitate a tough conversation that allows them to understand where the other person is coming from or what challenges are preventing them from delivering on their commitments.
I’ve had a situation where a product owner’s parent was incredibly ill, and as such, his mind was torn between caring for his parent and trying to be focused on the job at hand. Once the other party knew what was happening, their empathy kicked in, and they were able to understand why the product owner was consistently performing below expectations.
The team agreed that the product owner needed support during this tough period and came together to provide that support without fuss or complaint. The problem was quickly resolved, and the product owner, who felt under fire at the start of the retrospective, walked out feeling incredibly grateful for the support he was receiving.
Understand the organizational culture
If you work in an environment where the organization tend to look for someone to blame when something goes wrong, you need to respect that this trait is going to be present at the team level.
One of the goals of #agile and #scrum is to create environments where psychological safety exists. A place where people can own problems and take responsibility for addressing them without fear of losing their job or being punished.
People need to be able to speak openly about the challenges they face and request help if and where it is needed. If they traditionally get shut down or lose opportunities for promotion because of this, they simply aren’t going to talk in future, so you’ve got to work hard to create an environment where the team agree to foster and nurture psychological safety.
As an agile coach, you are not going to be able to change the organizational culture overnight, so you need to start at the team level and create an environment where people know they are safe to fail, explore, experiment, or provide honest and open feedback.
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years of experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster