Dealing with baddies on agile projects

[Editors note – this is a long an obscure article that made sense to me and some people I explained it to. If it is not making sense half way through abort rather than continuing … it either makes sense early on or does not make sense at all]

I was running an agile course on how to facilitate good work in agile teams.  We had some great discussions about conflict being good and people being unleashed to create value rather than being held back by managers who try to control them to force them to add value.

But then we had a less comfortable conversation. Someone asked what you do with someone who is being a [bad person] in an agile team.

I said you should let the team sort it out so they learn to be empowered. But my student persisted – but what if their behaviour will interrupt the ability of the team to feel empowered?  I said agile teams usually end up being happy and successful just like in the movies.

But someone mentioned that agile teams with a manifesto can be like animals on a farm with a manifesto, who are empowered to create a new self-organising team without the evil farmer overlords.

That might be obscure but several people mentioned that the team facilitator (agile coach, scrum master, iteration manager or whatever their title) is there to assist teams with exactly that kind of issue. If the team facilitator will not confront bad behaviour then why are they there?

As a result we had to tackle the thorny issue of dealing with baddies in agile teams.

Someone is mean

So here is a semi-real summary of our conversation:

Someone very senior and powerful comes the team meeting (retro; showcase; hangout). They launch into some “robust feedback” that is actually inappropriate.  They say “Your developers are really bad.”

We could start to work through this by agreeing to discuss how we can make our developers better. But in fact you don’t believe that developers are bad – you think the stakeholder is more of a problem here, or that there are other factors that need to be dealt with.  In this case you think we need to better execute testing and defect resolution across the board – business people, testers, developers and anyone else involved in planning and executing the project.

So you point out that the developers are not so bad after all.  The powerful and scary stakeholder starts to list times when developers have been bad.  You start trying to counter their points. This will probably not end well.

So let’s try an approach with two basic choices, agree (to what is true) or probe (for meaning).

Step 1 – pick a strategy

Rather than trying to convince the baddie that they are wrong, let’s pursue another course.  Choose one of the following strategies and see how you go:

• Agree with the things that you accept are true. But don’t just say “yep, I agree.”  Instead state clearly, in your own terms, the component of their comment that is factual or accepted; or
• Probe to see what they really think.

Here are the two options in a lot more detail bases on our pretend example of “your developers are bad people.”

Step 2a – Agree with them

Agreeing sounds wrong – especially when they have said something unfair or incorrect. But rather than trying to convince them, try to re-frame part of what they said by stating the accepted “facts” inherent in their comments, without accepting the wrong or unhelpful part of their comment.

For example you hear:

Your developers are terrible. They totally screwed the last release up.  They don’t care about quality and my clients are [vocal and rather upset]

You respond:

(I agree) the last release was bug ridden and unstable. We can’t accept outcomes like that.

With this release we need to ensure we deliver something we can be proud of. Let’s talk about how we can improve our approach …

The trick here is to be honest while focusing only on what suits you.

Don’t use the word but and don’t try to justify your position. Just say what you agree with, pause of 1 second and then move onto the conversation you want to have.

 

Fighting fire with fire means things still get burned

Some people have told me the AGREE-MOVE approach sounds manipulative.

I agree that we are trying to manage the conversation.  By doing so we create a situation where the stakeholder has been heard AND the team can deal with something positive, which allows for more robust and useful conversations.

I find this better than shutting someone down with things like:

• “Let’s take that off-line. We are talking about testing”
• “Give the guys a break – nobody wanted this”
• “They worked hard – you yourself saw how hard Geoff and Mary worked last week. You were also there when we made the decision to go live even though the team were saying the release was out of control.”

The first response here suggests you disagree and that the stakeholder is therefore wrong.  This can shut down the valid debate or (worse) leave them wanting to continue venting in 2 minutes when you thought you had moved on.

The second response is actually giving oxygen to the stakeholder’s already heated argument.  You are trying to move on but you are actually moving into their argument. Anything you say now will be an extension of “are the guys bad” rather than “Let’s focus on fixing things.” No matter how well you handle the debate, people are, at some level, still focusing on the question of “Are the developers bad.”

The third example is tempting, fair and probably the worst possible option. The stakeholder can sit back while you list many good things and then pick the weakest and zoom in on that one.

So each piece of evidence you provide seems like it is adding to your argument, but really it is just another potential weak point. The more points you make, the more likely it is that you have ignited the fuse again and you are back where you started.

Your mean stakeholder will listen for a bit and then zero in on the one area they can attack. You have merely extended the time and energy that is being focused on the topic you felt was inappropriate.  I sound cynical here but only because I am cynical.

Finding some kind of common ground gives you the traction to move forward

By agreeing to some facts, you are able to re-frame the conversation to continue moving forward while changing direction away from the energy consuming distraction.

There is a lot of good material on re-framing, but in the heat of the moment all you might have time for is a two-step process … AGREE – MOVE.

But the detail is important … it is AGREE (only to acceptable facts or common ground) – MOVE (deliberately in the direction you want to take the conversation).

This is hard to do on your feet but you might be surprised how easy it is if you can practice it a little. It might seem dodgy, but only because it can be.  It may seem hard to come back with the right wording but the hard bit is really listening to what is being said rather than preparing your respond before you heard them finish what they were saying.

I claim this is powerful because it forces you to listen and to honestly understand what common ground might exist and then making the argument you want to present. This is an extension of the “Bozo hypothesis” my father taught me when I was younger.

I also claim this is powerful because it is hard to both listen to hear what they say and to respond with some area of common ground that is both reasonable and honest. It will fail if you do not honestly believe what you say here (and say what you believe). You cannot claim to agree with something you do not agree with AND you have to know what you want to say next. This hardness makes you better at getting to the bottom of things, better at demonstrating your empathy and better at difficult conversations.

Option 2a failure modes

Sometimes our agile conversation approach of AGREE-MOVE does not work well the first time. We AGREE-MOVE only to find people are not moving with us.  This is OK.

Basically the stakeholder continues with what you might see as their negativity – and it might be because they are just being negative, or it might be because they are trying to clarify their thinking – it can be hard to tell.

Either way we have to respond. You joined the conversation so with this option we need to keep moving forward.

For example they respond:

“that is well and good but let’s not lose sight of the fact that the developers are really bad.”; or

“That is not what I meant. I know we want to fix the next release and not dwell on the past.  But I do mean we have an issue with trust and we need to deal with that. If we can’t trust the developers then how can we move forward?”

Now you can try a couple of approaches:

1. Switch to “Probe” as described below;
2. Attempt to repeat the AGREE-MOVE approach. Try to now confirm what they are saying in a constructive way and forget your previous attempt.
   • “OK, you see a problem with trust.  Trust is critical to our success.  What about the rest of the crew here – do we need to look at improving the level of trust we have between the development and business teams involved in the release?”
   • Notice again I evaded the idea that the team are the untrustworthy ones but accepted the idea that trust may be lacking.
3. Adopt the broken record approach. This simply means repeating your boring mantra until people shut up or leave.

A broken record

A broken record might sound something like this:

• “I meant we can’t trust the developers,” states our stakeholder
• “There could be many issues we need to tackle, you respond, “this session is to look at how we plan the next release. Can we move to discussing how we manage the testing and defect resolution?”
• Stakeholder talks for a bit
• “So there are many issues which we should focus on. We made time here to focus on the resolution of defects, which has to happen regardless.  Maybe we need a different meeting to explore other areas. Should we stick with the testing and defect prioritisation here or should we stop this meeting and discuss other issues?”
• Stakeholder talks a bit, claiming we need to sort this out but not have a separate meeting. They present some more concerns.
• “That is another issue that needs to be dealt with. We can stop this meeting and make sure we have the right stakeholders to tackle these issues.  My preference is that we use this meeting to focus on defect resolution and testing since that has to happen regardless of other issues
• Stakeholder talks a bit if they have energy
• “Yep there were a lot of issues with the last release. But my focus here is testing and defect resolution for this release. Now let’s talk about the current defect list.”
• Stakeholder asks if people need a coffee
• “Coffee is great but my focus here is …”

This is confronting but requires little energy.  That means you can outlast the stakeholder’s aggression and that others might see you as helpful rather than as one of two opponents battling away.

Step 2b – Probe to find out more

If agreeing with someone seems weak, or AGREE-MOVE seems aggressive, then see what you think of probing for more information.

Asking someone for more information may be a disaster if you do it the wrong way.

“Tell me more about how bad the developers are.”

But probing here does not mean letting them add to what they are saying. It means asking them to stop and both clarify and confirm what they said.  You can do this with closed questions:

“Do you really think our developers are bad people?”

Still not really probing again though.  Our stakeholder can only really back down or reaffirm their position.

A better question might be

“Why do you say that?”

This lets them explain what they mean AND leaves them accountable for what they said.  They can’t take a cheap shot and then get off the hook. Either:

• They need to make a conscious effort to back down, which they will soon get sick of doing; or
• Hopefully they can better explain their views and you can sit back and listen, rather than leaving you with the burden of refuting their views.

There you have it

So there you have it.  I think these approaches are workable and ethical. They do not allow you to shy away from confrontation and they do involve you deliberately trying to influence the flow of the conversation to align with the conversation you want to have.

Happy to hear your thoughts.