What to do with an Agile non-believer

Question

One of the people on my team has no interest in Agile, does not want to work as a team and doesn’t believe Agile will provide any benefit to them.

I am struggling for find research which will help me deal with them.

Does anyone have a suggestion of how to tackle this. I am at a loss.

A couple of things I was thinking of doing:

1. Building their trust just through open 1 on 1 catchups and just hearing them
2. Inviting them to team working agreement but accept that they won’t agree with rest of the team

Any other ideas?

Answer 1

TL;DR: Maybe a bit harsh, but get rid of him/her.

---

Most companies have a defined culture or core values. Suggested is to use your core values in the hiring process. I think the same goes for the firing process, fire to protect your core values.

Introducing Agile is a team culture shift according to the Agile Fluency Model. People blocking this culture shift should eventually be removed. I would discuss this with the person for a max period of 4-6 months. Discuss this aswell with upper-management and announce that not changing the culture is not an option. Make sure that it is clear what is expected from this person. Keeping people around with the wrong attitude is not worthwhile for both parties. This person will be happier in another company probably.

If it is a larger company, maybe some more traditional teams exists. I would suggest to move this person there.

Culture is important:

Value your culture and values highly. Showing that the company makes exceptions is the same as saying: "We do not take our values seriously". Now everyone will just do whatever they want. This is not the path a company wants to walk.

Continuing to tolerate this behavior will demonstrate to the rest of your company that core values are optional, and not truly core to building your company. This would be analogous to a cancer in your body that you have chosen to not remove.

http://www.rhythmsystems.com/blog/bid/87071/fire-to-protect-your-core-values

Waste of time:

Some people are open to change, some would rather just see how it works out, but some just push back. My experience with the last group is that is just a waste of time to convince them. They will keep making stupid remarks about the process and Agile principles or ideas. Agile has proven itself over time now. I have no need for people pushing back in my teams.

Answer 2

The team must address the issue. If discussions do not affect the individual, that is okay; not all are willing or able to work as a collaborative team member. Then that person needs to be removed from the team. This is the function of management in an agile organization. Perhaps there is a classic, head down project where that person can be valuable; perhaps that individual is released from employment.

Answer 3

There really isn't much context to work with. But given what's available, let's break down the problem into two parts:

[1] Does not want to work in a team

[2] Does not believe in Agile's benefits

Given that the one of the Agile Manifesto's focuses is on individual and interactions over processes and tools, I think you only need to tackle the first problem.

Without a deeper understanding of the context here, I see a few options:

a) Communication & Negotiation: Continue with the one on ones and find the middle ground

b) Escalation: This can be a whole essay on its own, but it assumes that all negotiation options have been exhausted (I'm not in favour of this)

c) Acceptance. By this I mean that you can still retain this person as part of your team, but their role will be that of the specialist++ (i.e. provides technical expertise).

++ Research. Refer to Meredith Belbin's 9 roles: http://www.belbin.com/about/belbin-team-roles/

Answer 4

I’ll throw a log on this fire, but it won’t be about them per se, it will be more about you.

What is Agile to you? What is Agile to him/her? What is Agile to the team?

One cannot be a non-believer in something unless everyone agrees to what they’re assessing.

I worked with a non-believer, so to speak. After talking with them, they were actually a firm believer in what I consider to be Agile. Not because of anything I did beyond dispelling what I consider to be misconceptions the person was introduced to by others.

“We don’t have to do documentation,” they said. “Not true I responded. It’s just that, at the end of the day a user can’t live in a blueprint the way they can a house.”

“It’s just a marketing scam, we’ve been doing iterative development forever,” they said. “There’s some truth to that. But, it gives us a common vernacular to differentiate the mindset from others. Even Pragmatic Dave Thomas, one of the drafters of the Manifesto has a talk decrying this part of things. That’s other people and not us though.”

After a while they stopped talking about how terrible Agile is and started talking about the way development should be. At the end I said, “You do realize you almost quoted the Manifesto verbatim and outlined the Kanban framework?”

Having said that, if the person honestly doesn’t want to work with other humans and the product or team demand that you do...they might not be right for that product or team.

Answer 5

There may be more to this than meets the eye.

If they don't want to work as a team, is something or someone else a problem? Is there stress, bullying, mental health or a home issue that makes them want to work as an individual? What is the history? Have they worked well in a team before? Maybe they suffer from Imposter Symdrome where they feel they are a fraud and being part of a team will highlight this (it is common among technical people).

As a manager we need to be aware of these issues. Where you are located may have specific laws that protect people from workplace issues. Be tactful and have empathy when you speak to them. Try to discover the real problem. If it is "non-work" related then do you have a company health policy or HR team that could help deal with the underlying issue.

With regards to not liking Agile. There is loads and loads of evidence on the wbe about how projects fail using older methologies such as waterfall. Maybe buy them the Audiobook "Scrum" by JJ Sutherland. It has loads of case studies that prove short iterative development. The bonus with this book is that it is short (about 5 hours) so can be listened to on a handful of commutes to and from work.

Answer 6

I believe that management and driving change can often want to label rather than understand their people-impediments.

It's interesting that we promote case studies on "red" and "blue" workers but do not step into the weeds of subgroups enough. In the end, they are there because they either want to contribute or not. If they want to contribute and have skills, it's in the interest of the whole project to take the time to understand what road blocks those folks have. Or you can simply label in the name of "the ends justify the means".

In short, my vote is to communicate with them; if you are failing to do so, ask someone else to take a turn on it. You are maybe not selling it properly in finding the objections that need to be overcome. Don't get me wrong, some folks will have objections that are not logic-based and thus can't be overcome.