7 tricks to influence a team resisting to change its technical habits
There are many ways to manage team resistance. Here are some of the technical agile coach’s tricks that influence: testimonies, experiments, and more!
Such initial resistance is typical, but maybe the worst I’d encountered in that class. People don’t learn new habits overnight. [Jeff Langr on extremprogramming@groups.io]
They liked developing big chunks of code on their own private branches, and there was no talking them out of it because they weren’t feeling any pain. [Phil Goodwin on extremeprogramming@groups.io]
Honestly, this is stupid! [A coachee when I presented the very first TDD kata]
I don’t want this change!
As technical agile coaches, it’s our daily job to bring change. Whenever we want to introduce a team to a new practice or habit, we are bringing change. Unfortunately for us, people have many good reasons for resisting a change! They might:
- Be tired of repeated change programs that did not live up to their promises.
- Be very happy with the current situation, and fear getting a bad deal if anything changes.
- Have too much work and don’t want the extra workload of learning new habits and practices.
Some people will offer mild resistance. Others, though, will make the confrontation pretty tough. Trying to push harder when a team is already resisting will only make work painful for everyone.
Here are different strategies to deal with resistance more sustainably.
Try some of these
Walk in their shoes!
This will not work here!
This quote is a sure sign that they don’t see how to apply what you are coaching in their day to day work. The technical environment might be too far from what you have presented. Are they crawling under legacy code? Do the company processes prevent them from changing how they work?
It means you need to understand their context better. You will usually learn a lot by sitting and working with them.
Avoid BUZZWORDS. What if we try this? Sitting and work with team. TALKING ISN’T EFFECTIVE. If they see and don’t want it, OK. Learn from them. [Dave Nicolette on extremeprogramming@groups.io]
Lean practitioners will call this Gemba. By pairing and mobbing, you’ll understand the team members’ situation and constraints. You’ll see and even feel their problems first hand. This will help you to find the angle to use to introduce new practices.
Explain to the team that you will mostly observe and that you will not slow them down. Be attentive to what is going on, and remember to be constructive. A bonus is that you might also be helpful! If ever you recognize a situation where you can help, by all means, do it! This is where your legacy-code testing skills will pay off! This will earn you extra credits that will make change easier down the road.
I used this technique with the first team I coached after I became an official technical agile coach. I spent 2 days per week pairing with the developers. I also attended their daily meetings and other sprint ceremonies. After a few weeks, I had understood and experienced their problems. I then suggested much more time-efficient coaching sessions using mobs and katas.
Be patient
We don’t really have this problem.
Sometimes, people don’t feel a problem. They might be used to it, assume it’s a fact of life, and live with it. On other occasions, it might be because they have more pressing issues to deal with first. Whatever the cause, the change you suggest will not stick if it is fixing an invisible problem. It’s useless to try to change something that people believe is working.
If you still think it’s important, keep your eyes open. The key is to be patient: work with them and leverage on any opportunity you encounter.
Sitting with them as they work through real stuff, and showing how things play out is critical. IT CAN BE MONTHS BEFORE HABITS STICK [Jeff Langr on extremeprogramming@groups.io]
Showing people tiny steps they can take that make them feel better about what they do, over a good long while [Mike Hill on extremeprogramming@groups.io]
For greater effectiveness, make every success as visible as you can. It’s even better to get the people you were working with share it with the team.
For a long time, this is the only type of coaching I actually did. I was not an official technical agile coach, but more of a developer who was coaching his team.
I remember a time when unit testing was still a controversial practice! We would publicize any regression caught by a unit test as an argument to convince the skeptics.
Run an experiment
We are humans… as a result, we don’t always agree! Introducing new practices can lead to many kinds of disagreements:
- between you and the team
- or among team members themselves
This can be the perfect moment to suggest an experiment. It’s often a lot easier to get people to try something than to commit to it.
I would ask them to try to submit a pull request about one half the size that they do now, then measure how long those remain open. I would measure quietly to avoid influencing their actions. Maybe this would help.
— ☕ J. B. Rainsberger (@jbrains) November 4, 2019
Short, 1, or 2 weeks, experiments are usually enough. Involve the team in the design of your experiment so that the results are better accepted. Also, try to make it as measurable as possible. Fuzzy results might lead to even more debate.
A few months ago, a colleague introduced a team to approvals tests during a kata. The team needed a bit more confidence to add the practice to their official toolbox. A team member ran an experiment on a particular piece of their production code. It went on pretty well, and approvals.cpp has now been promoted to an official company third-party.
Put them in a training mindset
TDD looks fine, but our immediate problem is dealing with Legacy Code!
I have seen that developers who master TDD deal with Legacy Code a lot better from my past experience. Unfortunately, it’s not apparent to people who don’t yet master TDD. Many things seem useless until you understand them!
Instead of trying to convince them, find a way to put them in a training mindset for a while.
I […] Stopped and reminded them that they were here to learn how to build things incrementally, that they should continue to work through the exercises with that in mind, that seemed to calm they down a bit [Jeff Langr on extremeprogramming@groups.io]
When people are in a training mindset, they are more open to
- Trying new things
- Learning for the sake of learning
- And putting their BAU constraints aside
Has the company got some form of slack time, learning, or innovation day? (Even SAFe can be hacked in this way!) This is the perfect occasion to set up a friendly low-ceremony training kata. Look for company processes you can piggyback on. For example, you might prepare a more official training and have all the team attend for a few days.
The refactoring coaching plan I built when working at Murex turns around this idea. The team was struggling with legacy code and refactoring. I prepared a kata plan that consisted of 2 parts:
- the first half was a set of katas around TDD
- the second half contained only katas around refactoring techniques (Golden Master, Strangler…)
I pitched the full plan as a single unit. I mandate TDD to create the short feedback loop required for efficient learning. This allowed me to shortcut many arguments about TDD: it was only a training tool. By the time the team had reached the end of the kata plan, they knew enough TDD skills to apply it in the BAU work.
Bring a testimonial
It looks interesting, but we are not sure it’s a good investment of our time…
Starting to work with a technical agile coach is a serious time investment. Some teams might feel uneasy about spending all this time with a coach. Does the team need a bit of social proof!
This is the perfect occasion to make them meet a former coachee. The closer to their situation, the better. Good news if you are coaching in a multi-team organization: it should be easy to find someone facing similar day to day issues!
The story of a peer overcoming similar problems is worth a thousand words from the coach.
One developer from the first team I coached as a technical agile coach at Murex later told me:
Unit testing and working in baby steps had changed her life!
Job was not easy for her when I joined the team. 2 years later, she is now happy to come to work and more productive than ever. Keeping contact with someone with such a powerful testimonial is a great asset!
Kick off creative collaboration
All people are different, and we don’t all connect as easily. Sometimes, contact with a team might not be as natural as usual. For whatever reason, it might not have started on good tracks.
A collaborative workshop is a perfect tool to kick-off an effective partnership.
The typical plan would be:
- Identify their problems
- Present the options you can provide
- Brainstorm what to do next
This fits nicely in a 2 phase workshop.
Run the first session for problem identification. For example:
- It could start with a problem brainstorming
- And continue with an activity like the 5-Whys, to understand their situation in depth.
Starting from their context will prove your interest in them. It will help to improve the relationship.
You can then use the time between the sessions to do a bit of homework. Check what you have in your coaching toolbox that could help them. You might also ask them to collect any ideas they might have on their side.
Finally, meet them again. Start by sharing the ideas you all had to fix their problems. Finish by picking what you want to start with. The solution focus format works like a charm here.
Ask another coach
If you still cannot build a relationship with the team after such a workshop, ask another coach to give it a try. You might just not be the right person for this team. Someone else might have more luck!
We all have different coaching styles, and some fit some teams better than others.
That’s one of a tech-coach team’s forces: you are more likely to find the right coach for each situation. At work, I know that some teams work better with some of us than with others. That’s fine, and it’s also a great way to share the workload!
In last resort: Quit
You might have noticed that this is the 8th trick! It’s not a way to influence, but it’s still something we have to resort to from time to time.
If nothing seems to work, it’s better to stop now and move on to another team. Many circumstances are out of your control and can make your coaching fail:
- Has the team got too much work?
- Are some key team members having personal issues?
- It might just not be the right time, and it would work better in 1 year!
Whatever the reason, you will create more value by helping a volunteer team. It’s actually the first principle of our coaching team at Murex: we only work with teams that volunteer.
It’s especially true if you are coaching in a multi-team organization. You don’t want to spend all your energy fighting laggards. There might be plenty of other teams that will welcome your coaching. Working with them brings more value to the business. Don’t forget that you have a whole organization to refactor! Setbacks are inevitable. Sometimes, it just won’t work. We want our coaching work to remain sustainable. The best thing to do is to accept and move on.
From my experience, it’s when you have to quit that you learn the most. Keep some time to think about it. Ask fellow coach co-workers for help. Get more clarity about what did not work and what you will do better next time!
Experiment and learn
Coaching is not a science. Team and organization dynamics is a very complex topic. If your typical coaching recipe does not work with one team, give one of these tricks a chance.
- If it works: I’m delighted that I could help you!
- If it did not: I’m sure you learned a lot more about the team, and you’ll be in a better place to pick another trick to try. I’m also glad I helped you.
Part of the joy of coaching is discovering a way to bring some improvement in unknown situations! I’d love to read your comments and own stories about teams resisting coaching!
Leave a comment