No.  However, this is going to be true of any process you might adopt – Scrum, Kanban, Extreme Programming (XP) or traditional project management.  If the your team members are not truly curious to learn more about Scrum and Agile and not eager to participate on an Agile team, then I would suggest stop forcing them to do something they have no interest in.  That is a recipe for a sad bunch of people at work.

Dan Mezick (@DanielMezick) states over-and-over again that Agile imposed from above leads to failure (or what I see a lot of, cargo cult adoption.)  In these organizations, Agile never lasts beyond the next re-org.  In my work as a consultant, I have seen a lot of organizations adopt a veneer of Agility (a few practices from this website, a couple of ideas from this author, etc.), as a way to slap an “Agile” sticker on a depressing status quo.  Putting Agile words on crappy office environment is still just crap.  I encourage ScrumMasters and leaders who support this behavior to stop contributing to workplace cynicism.

However, all is not as grim as I make it sound.  There are some ideas you can apply now that will help your team commit to Scrum and Agile and stay engaged with whatever Agile process you choose to use.

1.  Educate the Team members: most people have a lot of misconceptions about Scrum and Agile.  These misconceptions are based on bad experience, biases, rumors, misinterpretations and legitimate doubts based on personal experience.  I once had a Team member who escaped from a former Soviet bloc country tell me they would never do XP since it was “too much like socialism” (OK – I’m not going to win that battle).  The idea of education is to help people separate rumors from fact, not to indoctrinate.  It is important to discuss why Agile will help the Team succeed, what Agile practices are being considered and how they will be applied.  Also, be clear in the training if the participants have a real choice to say “yes” or “no” or if the adoption of Scrum and Agile is a demand from the business.  In my experience, schedule at least a day for any sort of meaningful dialogue about your Agile process and how it will be used.

2.     Ask the Team members: many people are compelled to do Scrum and Agile and that is sad.  In my experience, Scrum and Agile have to fulfill a need within the participants or they will never take root.  As a part of any formal education, take time to ask people if they want to participate in a Scrum and Agile team.  Even if the Scrum and Agile adoption is a demand, there is benefit to spending time asking the Team their thoughts on the timing of the Agile adoption (it might be flexible).  If there are any specific (or general) objections, use this time to listen to them.  If possible, formulate a compromise.  (One word of caution about compromises, though, in an effort to please the outliers on your Team you may undermine the effectiveness of your Agile process.)  In my experience, it is better to adopt an entire Agile process rather than to begin with a compromised process.  To reduce resistance of complete adoption, I often encourage a Team to consider the adoption of an Agile process as a timeboxed experiment.  The goal of this discussion is to help everyone say “yes” to Scrum and Agile, not acquiesce to the opinions of someone with more power, authority or influence.  One last thing about asking the Team members, there is a downside to all this dialogue – the answer might be “no.”  If what you hear from the Team is a “no”, you have to respect and support their decision.  Otherwise, their engagement and participation will be a big fat zero.

3.  Cut people loose: in my experience, people who are unhappy at work are not very productive and tend to make other people around them miserable.  If an Agile way of working is not going to make someone more happy and the rest of Team is bought in on Agile, then we need to find the outliers a new home.  Do not change your Agile process just to satisfy one or two disgruntled people since this will usually lower the engagement of the people who are excited about adopting Scrum and Agile.  In my experience, those Team members who completely against Scrum and Agile are likely never going to commit to an Agile process.  If this is the case, then the goal is to help them find a way of working that meets their needs within the existing organization.  Remember my story about the Team member from a former Soviet bloc country?  In that situation, we worked together to reassign her to a team more suited to her needs rather than force more “socialism” on her.  I have also seen some individuals who wanted nothing to do with Scrum and Agile report directly to engineering managers for assignments.  Both solutions worked just fine for a limited number of outliers.