

Class Registration
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.