5 technical agile coaching tips to fight exhaustion from laggards
Trying to coach laggards will exhaust you. Here are 5 tips to deal with them, sustain you, and make you spend your energy where it matters.
I don’t know what to do precisely. I already sent him many times the wiki link to the coding conventions.
Is this person toxic, or am I too demanding about things I want?
For a long time, I thought I could avoid toxic behavior by spending time with these people.
I have a friend who trains managers as a living. Unfortunately, she had to visit a doctor because she was suffering from insomnia. When the doctor learned what her job was, she said that many trainers and coaches have sleep disorders!
Any activity that involves working with others and bringing change is exhausting. We can only deal with so much active listening and explaining during a single day.
Coaching any developer to XP will need a lot of energy. Yet, ‘laggards’ take 10 times as much! Laggards do not believe in what you are coaching. Nothing you will say or do will make them change their minds. Laggards will argue every minor detail, and they won’t change their behavior. They are not ‘bad’ people in any way! It’s just that they’ll be the last to switch to new ways of working. If you are not careful, they will exhaust you, though!
What if you knew how to make all your coaching work helpful, constructive and energizing?
Unfortunately, it’s not all ponies and unicorns. There are laggards in the teams we coach. Yet, we don’t want them to burn us out! Here are 5 tips to help you deal with laggards and make you continue to enjoy your work!
1# Only work with volunteer teams
Before even starting coaching, make everything you can to work with a volunteer team! There are 2 reasons for that:
- If the team does not want to be coached, you will likely face many laggards in the team! In this case, it’s better to fail fast. Every time a team refuses coaching, you avoid a difficult mission!
- Persuading the team of volunteering will set up a constructive collaboration. Working on a team’s pain points instead of general TDD or XP should do the trick. It will align everyone towards the same goal. It also de-emphasizes XP or TDD, which avoids many opinion-based arguments.
Sticking to volunteer teams decreases the risks that you will have to deal with laggards.
💡 What you can do now: Read my previous post and learn how to pitch teams about their pains.
2# A single laggard is OK
In my experience, a lonely laggard in a team will eventually leave. I now use “the rule of one”:
If there is a single laggard in the team, focus on the rest of the team.
Continue to be friendly with this person, but don’t spend your time trying to persuade them. The team’s new way of working might not suit them. They most likely will be better in another team. At some point, they’ll understand this and will move. Fortunately for us, there are currently plenty of exciting opportunities for software developers.
The best thing to do is to avoid starting coaching a team that has 2 or more laggards. If you find yourself in this situation now, I advise to try a coaching “reset”:
💡 What you can do now: avoid having to coach a team with more than 1 laggard, and spend your time with those who want
3# Avoid personal arguments
Nothing is as exhausting as repeated and never-ending arguments about the same topic. Many laggards will try to get you in a quarrel about TDD, pairing, or mobbing. Don’t let yourself get caught in this trap!
Don’t forget your goal as technical agile coaches. Use the opportunity to set up an environment where the team members can resolve their disagreements together. Here are examples of what you can do:
- Use the topic at hand to start an improvement kata. It will begin with data gathering and could move the team into more data-driven discussions.
- Gather everyone together into an Event-Storming workshop. It’s an excellent way for a group to make complex decisions. For example, you could use it to decide whether to rewrite or refactor a piece of code.
- If people are arguing over coding conventions, set up a randori kata or a mob session. Pick a problem or a piece of code to make the convention come up. Then use everyone’s presence to have an open discussion about it.
- Is there an existing model around the topic? If there is, use it to go past personal preferences and have a more objective discussion. For example, Big O() analysis is better than pure intuition to know what part of the code to optimize.
💡 What you can do now: refuse to enter any personal argument. Instead, call the team on the spot, prepare a custom retrospective, or schedule a workshop.
4# Regular coaching breaks
In her book Technical Agile Coaching with the Samman Method, Emily Bache recommends regularly taking some time away from the team. More precisely, she suggests alternating:
- 3 weeks with the team
- 3 weeks away from the team
It’s an excellent opportunity to recharge your batteries before challenging coaching sessions.
There is another subtler advantage. It will also let you observe if the team is improving while you are away. If it does not, it’s a sign that the team is lacking enthusiasm. It’s a warning sign that this coaching mission might end up exhausting you!
💡 What you can do now: own the coaching sessions invitations and schedule regular breaks.
5# Leaving is always an option
If you’ve tried all the above and work is still exhausting you, it is time to consider leaving. It turns out that there are different ways to quit!
- You can find another coach. Maybe you were just not the right person for this team.
- If you think there is still hope, try to pass a Last-Chance deal with the team. If the team does not hold up to its part of the bargain, then you can leave holding your head up.
- Finally, you can also choose to be direct. Progress is too slow, you are exhausted, and you have decided to stop.
Sometimes, we need to let go of a team to focus on others where we will be more helpful. Coaching is not an absolute science, and it does not work every time. Once your mood has improved, take some time to reflect and see what you will do differently next time.
💡 What you can do now: if the situation remains non-sustainable for you, leave.
Be nice to yourself!
We are only humans, and there are limits to what we can handle. Don’t let a few laggards exhaust you! Remember these tips:
- Pitch teams about their pains
- Spend your time with people who want it
- Use team activities to deal with disagreements
- Own the calendar invites and schedule some breaks away from the team
- Finally, if the situation is non-sustainable for you, leave
These tips will help you avoid “laggards exhaustion.” They will also let you show a better version of yourself to all your coachees, now and in the future. They will make your technical agile coaching work more energizing, constructive, and sustainable.
Oh… one last thing… they might also make you happier!
What about you? How do you deal with laggards in the teams you coach?
Here is a selection of related posts that will interest you:
- Wondering how to find volunteer teams by focussing on their pains? Read How to coach a team that has been burnt by bad TDD
- Here are 3 Good and Bad Ways to Write Team Coding Standards and Conventions
- An oldie, but still relevant: How we introduced efficient agile-retrospectives
- Are you looking for a data-driven way to continuously improve? Read How we used the improvement kata to gain 25% of productivity
- A few examples of complex decisions you can make with Event Storming:
Leave a comment