Change often leads to conflict, or that’s at least what it looks like at first glance. Change triggers resistance, an automatic – instinctive – reaction that we’ve all got built in. “Why change? The old way used to work”. While that might be true, change is needed to improve.
So why do we all naturally respond that way if we know that change brings improvement? The answer to that question is simple; insecurity – being scared of what the future brings with it. The improvement doesn’t necessarily mean that it’s a positive improvement for us as an individual.
How do you go from conflict and insecurity to positivism? While conflict (over change) is not the most ideal way of feedback, it is still feedback. If you have the ability to read the conflict well, you can use it to your advantage. The people that are part of the conflict will vent their fears and their core issues with the change that you are trying to implement – if you read between the lines.
Ideally you try to make the team that you’re working on part of the change. You make them decision makers in the change process. You don’t, however, always control that, there might be additions to the team after you’ve implemented the change – or worse, when you’re in the process of change.
A mistake I made in a recent implementation of change (going from 0 workflow to a Scrum workflow) was that I didn’t give the newest additions to the team enough room to vent their ideas. They had joined the team halfway through the implementation and couldn’t accept the way the implementation was working out for the team.
What I did to turn that negativity around as a Scrum Master:
I planned an extra meeting (aside from the retrospective, given that the feedback was vented in different ways and had to be dealt with right now) in which the team could openly discuss the problems that one of the team members had vented. I had already come up with changes I’d like to implement and had already begun discussing them with individual team members before the bomb was dropped. I wanted the team to come up with solutions under my guidance, and they did.
I’ve noticed that, while for some teams less important, it is very important to make retrospectives (and in some cases more meetings are needed during your first sprints) a core part of your scrum implementation. Make sure your team has enough room to vent frustrations and problems and make sure you’re listening as a Scrum Master.
Turn the conflict around and make it a positive change for both the team and yourself. Use the opportunity it gives you to make things work out for everyone.