What If An Agile Team Member Won’t Play Ball? | Crosstide

What do you do if someone in your agile development team is simply not playing ball? Particularly if their behaviour is counter-productive to the key principles of agile development and is affecting the team’s performance.

One comment I’ve heard (not at my organisation by the way) was to apply the self-organised nature of Scrum and allow the team to raise the issues with the person directly and use peer pressure to make them feel uncomfortable in the hope they might leave. Admittedly in this case the person’s behaviour sounded particularly bad, but in any event this is not a good approach.

I’ve managed software development teams for many years (in the UK) and am currently responsible for a web development group of about 90 people. I think I’ve experienced every HR/management procedure in the book and keep promising to write a book about some of the more extreme examples (that are entertaining stories in hindsight but certainly weren’t at the time!).

To be honest, I found the idea of the team raising the issues as a group in the hope you wouldn’t need to fire him (presumably meaning he might jump) quite alarming.

Firstly, in UK employment law he’d potentially have a case for constructive dismissal if he knows his rights or gets good advice, and that carries quite a stiff penalty. Secondly there’s the issue of it not being appropriate to bully colleagues into leaving, even if they’re a complete pain in the backside!

I recently wrote a short blog post about an amazing statistic I heard; one consultancy firm suggesting you could lose 25% of your developers when moving to Agile Development.

The reality is that not everyone in your team will agree with the philosophies of agile development and some find it practically very difficult to adopt to the very dynamic nature of the process and the lack of clarity and certainty it can bring.

In my experience there’s only one way to deal with someone behaving badly in an Agile Development team (in fact in any team):

• Any discussions must be 1:1 – air dirty laundry in private not in public
• Explain that the person appears to be finding the Agile Development approach difficult or appears not to be on board
• Outline why you think that’s the case, using constructive examples of how his behaviour is affecting his performance and the performance of the team
• Tell him what good looks like; in the above examples, how could he have responded and what might the effect have been then
• Try to understand why they’re behaving as they are; do they disagree with the principles, are they uncomfortable with the process, do they find group working difficult for some reason, or is something else bothering them? Remember bad behaviour is a symptom of something else
• Adopt a supportive and understanding stance; don’t use personal or aggressive language; use non-emotive words such as “I feel”, “it’s perceived”
• See if there is anything you or anyone else can do to help or support them better
• If it’s a case of feeling uncomfortable with the principles and process, would training help
• If not, perhaps regular 1:1 coaching sessions where you can discuss the day’s events and reflect on the situation outside of the main group
• Remember he can’t control his capability but he can control his conduct. In the latter respect, insist that he does
• It doesn’t matter how small, and however bad everything else is, catch him doing something right and praise him in public (be careful not to patronise, it must be sincere!)
• If none of this works, consider whether there’s an alternative role that might suit him better – remember agile is not for everyone and some excellent people don’t get on with it. Remember the bad behaviours are a symptom not the cause
• When you’ve exhausted all other possibilities and if the conduct issues persist, if you really are 100% committed to the agile approach, you may in the end have to resort to disciplinary action potentially leading to dismissal
• If you have to take this path, make sure you consult your HR department and follow the appropriate process for your company and location

Finally, and just to reiterate, personally I love the agile development philosophy, but it’s not for everyone and not everyone can adapt easily to the change. Your first goal must be to change people’s behaviour through education and training, followed by some open 1:1 discussions with those reacting badly to the change or finding it difficult. First and foremost, try positive support and encouragement, even when it feels like it’s going against the grain.

See also: 10 Key Principles of Agile Development