|
Agile development is not right for every software
professional. If you are bringing Agile into a siloed
company accustomed to plan-driven methods, expect
that 10-15% of the people would not fit.
In my experience, individuals might not fit with their
newly-Agile team for these reasons:
- They strongly prefer to work alone, not as team members.
- They would much 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 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 approach,
but feel that their particular team is not up 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 techniques and
criteria. Others resist openly, promoting a reversal to
the trusted old ways (some might even act up, like the
senior developer I once heard exclaim, “You mean I should
work longer because my team is stupid?!”) Some attempt to
influence their managers to modify the team's process. A
small percentage quits the company.
If you were leading a siloed team in a plan-driven
environment, members who didn't fit wouldn't necessarily
pose a huge problem. You could assign special work to
them, have them sit separately, or have them communicate
mostly with you. However, in an empowered, collaborative
team environment, the fit problems affect them and the
team a lot more. The team struggles to self-organize, to
make commitments, and to hold each other accountable. 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, have integrity, and
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 experiencing change). But be
watchful, and don't let it drag out:
Brenda, a project manager, has told me: “Let's say that
we have somebody who has a performance issue and is
unable to carry their own weight. The team carries their
weight; everybody assumes that they have to carry their
weight because they work as a team. That can go on for
months before anything takes place. Maybe Agile does not
work for everybody, yet those for whom it doesn't work
still stay, and the team is supposed to still self-
organize. Then we have morale issues. What ends up
happening is that team members stay around 8-9 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.”
As Brenda's story shows, toughing it out may not only
fail to work, it can hurt a lot people in the process.
Apart from reducing the team's performance, unresolved
fit problems demoralize the team. 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 might 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,
the teams I've known, who had had such a member depart,
quickly regrouped and made up for the loss. The
combination of relief, improved interpersonal dynamics,
and rapid cross-training helped them improve performance
beyond expectations.
You might 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.
Copyright © 2012, 3P Vantage, Inc. All rights reserved.
|