InfoQ picked up my post, Team Trap #1: Messing with the Membership, and contrasted it with Mike Cohn’s advice that a PO, manager or scrum master who observes that the team is too homogeneous might stick a couple of new team members to increase diversity on the team.
I would advise a different approach.
First, talk to the team about what you observe. Describe the impact on results.
Engage the team in problem-solving.
If the most reasonable and feasible solution is adding team members with some important difference involve the team in the process (see Hiring for a Collaborative Team).
Adding new people on a team presents an integration problem. The new team has to figure out how to work together. When the new team members are quite different, it’s an even bigger challenge. Better that the people who have to figure out how to work together have an investment in making the new arrangement work. The investment will be much greater if the team had part in selecting the new members.
And where did the practice of voting someone off the team come from? That may be a good formula for reality TV shows, but not so good for psychological safety on a team.
I have seen teams help a person off the team. But that was a mature team and they didn’t vote.
There are times a manager HAS to be a manager and get involved. We had a team member who was a drag on the team for literally years and years. He was a nice person, and had some good qualities such as a lot of domain knowledge, but for whatever reason refused to improve his coding skills or to comply with guidelines we set for ourselves, such as using TDD. This was discussed repeatedly in retrospectives over the years, other programmers tried to pair with him, the manager finally ‘counseled’ him. Finally the manager decided to let the person go, which was a tough decision, but in hindsight, the right one. We ourselves could not ‘vote’ this person off the team. Self-organizing works for some things, but not everything. We needed the manager to take action.
We never filled that open position, and were all the more productive even with fewer people. If the manager would have taken action years earlier, given that the problems were always obvious, think how much better the situation might have been!
Hi, Lisa –
I agree. I’ve similar situations, and it’s just painful. The most painful is when some well-meaning manager tells the team “you deal with it, you are self-organizing now.”
I wrote about one such case here: https://estherderby.com/2010/10/too-hands-off-manager.html
What I’m cautioning against is turning the team into a revolving door, or re-forming teams before they have a chance to learn to work together.
Sticking people onto a team with out involving the team though, is usually not helpful.
e
Sounds painful.
I wonder how about the connection between voting people of the team and in-fighting. Seems like the former could lower trust, which would lead to more or the later.
e
Esther I agree completely. I observed this at a company I worked for where teams decided they could just “vote people off” and it had devastating affects. They were even allowed to decide if people got to stay with the company or not, they had THAT much influence. It was way out of hand and poorly implemented with an all-powerful lead Project Manager who would actually go to HR. The managers had no input.. it was by far the most painful implementation of “agile” – if you could call it that I had ever observed… and it became a popularity game.
Needless to say, no gains were realized working this way and things went back to waterfall; heroics and working extreme hours..
Teams need to learn how to work together, but they have to learn how to do that with education, teaching and coaching.. It doesn’t just magically happen!
Thanks for sharing this!
That does sound painful!
In many organizations, managers have wielded too much power. And I’ve seen many “agile” adoptions where managers and teams struggle to navigate a more balanced relationship. Often the pendulum swings too far in the other direction.
In reality, it’s a relationship to navigate, respecting needs and responsibilities of the manager and the team, always with the context (creating valuable products or services, meeting organizational goals) in view.
e
I am in that situation of being moved into a homogeneous team. I don’t recommend it from the perspective of that new person.
For instance I am practicing TDD like 5 years ago. Not because the team is new to the practice but because they evolved in a different direction according to what they value most. They value security more than anything, so their style of TDD is driven more to achieve safety that to allow discovery.
That means write test before, after, during regression, whenever, just make sure we got 100% coverage at Unit and Integration level so we can sleep at night. Instead of trying to figure out as a team what this BDD/ATDD fuss is all about.
I’ve been in this team for a year and still there are several practices that I just cannot agree with an have to do them regardless. Eg: group tests mirroring assembly/class structure of code, achieve 100% coverage, abide by all preset rules of StyleCop and FxCop, adding doc to all public classes/methods, validate every arg of every public method, etc, etc.
I really love programming so I can work under any constrains and keep fighting to push the boundaries. But personally I’d rather be with a couple of more colleagues that are trying to figure out the same kind of things.
Cheers
mike
Hi, Mike –
Your story reminded me of an ugly situation I ran into earlier this year.
The manager had decided that the team needed to improve their engineering practices. So he hired a person who was accustomed to XP. The new guy was told that part of his job was to introduce XP to the team.
But the manager didn’t tell the team that he wanted them to learn TDD and start pairing.
The new guy set about trying to instill TDD and pairing. In the mean while, the other people on the team were wondering why this guy though he could waltz in and tell them how to do their jobs. Recipe for resentment, both ways.
Honestly, I don’t know why managers don’t just talk to the people on the team if they have concerns.
Thanks for sharing your story.
e
I read Mike Cohn’s post and I don’t believe he meant: Forcefully impose new team members on your team ASAP.
In Project Management, there’s the Management word. Any good Manager will go to such a process as you describe in order to get team buyin especially in Self-organizing teams.
I’ve seen just that happen many, many times. A manager decides to “fix” the team by adding a new person (or removing a person) without any consultation with the team. This is an act of control.
As you say, effective managers don’t do this–but it does happen a lot.