Want More Sad People At Work?

If the Team is not committed\bought in on using Scrum, will it work?

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.