Agile development is not right for all software professionals. If you are bringing Agile into a siloed company accustomed to plan-driven methods, expect that 10% to 15% of the people will not fit.
In my experience, individuals might not fit with their newly Agile team for one or more of these reasons:
- They strongly prefer to work alone, not as team members.
- They would rather develop their specialties than shoulder miscellaneous team activities.
- They prefer to implement other people’s plans and designs and don’t want to make any high-impact decisions.
- They feel that the Agile methodology sets them up for failure because it doesn’t mandate the detailed planning and up-front design they associate with responsible development practice.
- They are willing to go along with the Agile methodology but feel that their particular team is not up to the job, which will reflect badly on them.
Some of these folks express their displeasure quietly, doing their best to mitigate the risks they perceive. They work hard, intent on demonstrating their own performance according to pre-Agile criteria. Others resist openly, advocating a return to the trusted old ways. (Some might even act up, like the senior developer in section 7.4 who exclaimed that his team was stupid.) Some attempt to influence their managers to modify the team’s process. A small percentage — sensing the company’s new direction — may even quit.
If someone doesn’t fit in a siloed team, you could assign special work to her, have her sit separately, or have her communicate mostly with you. However, in an empowered, collaborative team environment, the fit problems affect her and the team a lot more. The team struggles to self-organize, to make commitments, and to hold each other accountable. As the Agile team leader, you have to be involved a lot more. It doesn’t take much for team members to become rancorous about the “problem child” getting special treatment while they are expected to do whatever it takes to succeed.
You might have some success educating, encouraging, or cajoling these folks to make the effort and play on their team. If they are good performers and have integrity, and if you do not want to lose them, you should give them a chance. Their resistance might be temporary, an artifact of the chaos period of the change curve. Still, be watchful, and don’t let it drag out.
“Let’s say that we have somebody who has a performance issue and is unable to carry his own weight. The team carries his weight; everybody assumes that they have to carry his weight because they work as a team. That can go on for months before anything is done about it. Maybe Agile does not work for everybody, yet those for whom it doesn’t work still remain on the team, and the team is supposed to still self-organize. Then we have morale issues. What ends up happening is that team members stay around eight to nine months longer than they ever should have. All the input others and I have for management appears to fall on deaf ears, because people strongly believe that since they are in an Agile team, they should stay in that team.”
— Brenda, a project manager
As Brenda’s story shows, toughing it out may not only fail to work, it can even hurt a lot of people. Apart from reducing the team’s performance, unresolved fit problems demoralize them. Sometimes, redeploying people can be a win for all involved, which means management must be part of any response.
All too often the person in question has highly valued skills, domain knowledge, or technical expertise. You and the team may feel that removing the person would hurt the team’s ability to produce required deliverables. In the short term, that might actually be the case. However, when the teams that I’ve known had such a member depart, they quickly regrouped and made up for the loss. The combination of relief, improved interactions, and rapid cross-training helped them improve performance beyond expectations.
You may be tempted to give people a second chance, and a third chance, and even a fourth. If you are like most of the managers I’ve met, you don’t want to hurt the person or lose their contribution. You must clearly realize the detrimental effect on the team of having that person there, or that the status quo may not be good for the unhappy person, either. For your own peace of mind and a level-headed decision, seek someone to coach you or discuss possible courses of action with you.
About the book and the author
The book The Human Side of Agile: How to Help Your Team Deliver, from which this article is excerpted, was released today and is available online at www.TheHumanSideOfAgile.com. With this book, Gil Broza has created a practical, universal guide to navigating the least manageable, understood, and appreciated asset in an Agile environment: its human side. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:
- Establish yourself as a confident and capable leader who adds value
- Build and lead an engaged team that can handle almost any challenge
- Cultivate collaboration and a continuous improvement mind-set
- Reap the full benefits of Agile in the real world with real people
Click on www.TheHumanSideOfAgile.com to discover the “virtual loot bag” you’ll receive from Gil’s network of collaborators and experts for ordering your copy today.
Don’t forget to leave your comments below.