Tag: change

The pain of introducing Scrum

The pain of introducing Scrum – or any new workflow for that matter. Obviously we all love the end result: self sustaining teams, better results, faster results and so forth. Introducing (or actually fully adapting and eventually adopting) a new methodology, whether it’s Agile, Lean, Kanban, Scrum or any other, is a painstakingly slow process.

The team that is to adopt a new workflow, but also the whole company, are stuck in their way of handling things as they are. While they might love the promises that adopting a new methodology brings forth, they are not ready for the changes and process that are involved with the change in many of the cases.

Inform your team and your organisation that changing to a new methodology will take a lot of time and a lot of effort. Make them understand that things will not be running smoothly from the get go.

“A team reflects on how to become more effective”

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

Sources: Agile Manifesto & Twelfth Agile Principle

Scrum, and also other agile methodologies, are built on constant feedback loops. That feedback eventually, time after time, leads to (minor) changes in the way the new workflow is adopted and used.

It is the team that makes Scrum work in the end. It is the team that has to identify and eventually tackle problems and bottlenecks in the current setup. Facilitate and guide the team in the identification and solving of those issues, whether you’re a Scrum Master, a stakeholder or a company as a whole.

Make sure that everyone involved knows that only time and transparency make your implementation work. Make sure that everyone involved realizes that a new workflow takes time to settle in, and mostly that it is a progress, not a straight forward implementation. Any good adoption of a new workflow is one where the team, and the workflow itself, have the space and time to evolve.

Change often leads to conflict

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.