Pairing, Competence, and Recognition

It's a common thread in agile transitions that people are not sure what pairing, teamwork, and self-organization will do to their status on the team. Will the team be so leveled that nobody will stand out? Will the weak be exposed and humiliated? I am going to write this as if there were two states, strong and weak. Before reading anything that follows, remember that everyone is good in some areas and weaker in others. I have seen javascript gurus who weren't very database-smart, and people who were great with requirements and product knowledge but had no sense of scalability or performance. Any human characteristics are spectra, not point measurements. With that in always in mind, read on:

There is good news, more good news, and some hard and potentially sad news in all of this. The first bit of good news is that nobody who works in an agile team ever asks these questions. In reality, it's not a problem. Let's get down to cases.

Rockstars

If you are the rock star of the team now, you will find that pairing will give you mentoring and teaching opportunities and respect that you've never had before. Invariably, a great programmer on any team (whether outgoing or quiet) becomes revered by the team. If you have the skills alone, you have the skills paired too. I've not seen any great programmers fall through the cracks. Sometimes a pair mismatch may be uncomfortable for a while, but you can elevate the skills of your teammate. Imagine what it is like when all the members of the team will listen and will up their game. You will find it is much cooler to be a revered member of a competent team than to be the high-and-mighty member of a mediocre team. You have nothing to lose and everything to win.

Bob Anderson named a strategy "Attack The Weak" (tongue-in-cheek), in which the strong member of a team intentionally selects a less-established or less-experienced partner on purpose, as a teaching and sharing opportunity. This is a good strategy, provided the strong member is nurturing and not dictating. The point is to raise the partner's skill level, not to expose them as weak. Not every pairing has to be of this form, but several a week is a good idea.

Growing Developers

If you are the weakest player on the team, you will find that pairing gives you an opportunity to learn from your teammates. In addition, as the partner shares the keyboard and ensures that you're doing test-first work, you will find that it's harder to make a mistake that gets through to integration (let alone release). You have a safer working/learning environment.

In a strategy I call "eat the rich", you choose a partner who knows something you want to understand better. That partner may be a tester, a UI expert, a performance expert, the local ruby guru, or someone who really deeply groks the platform. By pairing with them a few times a week, you add their skills to your own.

The Borg Collective

A common fear is that everyone will be assimilated, and the entire team becomes an amorphous mass of fungible "resources", that the strong and the weak will be indistinguishable, and that morale will collapse. Some fear that incompetent developers will be able to hide in the team and drag down efforts, or that brilliant developers will be unrecognized.

The fact is that people are different, and are drawn to different aspects of the work. We can all get better at everything, but some things will speak to us more deeply than others. As a result, we will have special strengths and weaknesses.

When you work entirely in pairs, everyone who works with you will get to know you. While it makes no sense to recognize and reward individual efforts in a team (thereby creating competition and sabotaging the team effort), there is no question in anyone's mind who the strong and weak players are. This information is best kept within the team, but there is no question. In a 360-degree review, the strong team players will be recognized. Think how great it would be if your coworkers were the ones who promoted you, because you have helped them improve and they respect the skills.

This is where the potentially sad part comes in. Some people cannot program well, but do it anyway. If an initially weak player shows potential and improvement, everybody is happy to see them grow and change. Sadly, some people don't get any better. If they don't take advantage of the team-learning and remain weak and unskilled, they will demoralize the team. Nobody wants to be hand-holding and nose-wiping and babysitting all the time. If someone is a continual drag on the team, and doesn't improve, and doesn't show any signs of potential, everybody on the team knows that too. In order to protect the team's morale and productivity, teammates may "vote him off the island" by asking their scrum master or project manager to consider counseling that person into a position more suited to their skills, even if that means another company. This is sad to the one who has to leave, but can actually improve the morale of the team. It is doubly sad if the one asked to leave has an inflated self-image and thinks himself a rock star. On an agile team, though, it should never be a surprise to be asked to leave.

School for Deserters

The other concern is that people will improve their marketability as developers. After all, they've had months of self-improvement and now can put the big A word on their resume ("agile", not what you are thinking) so now they could command a higher salary if they leave.

Okay, fair cop. You will suddenly have a team of developers that are the envy of the other companies in your area. Competitors and neighbors will start to take notice, and may extend some recruitment feelers into your team.

Think about the mixed blessing here: You have the team that everyone wishes they had. If you want to look at this as a problem, go ahead. Might you have to hand out some bonuses or raises based on the performance of the team? You might, but don't you want to have a team that is deserving of recognition and reward? Isn't that better than the alternatives?

Conclusion

Yes, when you become a true agile team, the teamwork does eliminate individual rankings in a traditional way. You can't say who completed a piece of work because the team did it (perhaps every single member had a hand in it), so old individual rewards are hard to give. Worse, individual rewards can break down a team if they create competition between the members, since competition can stymie free and open sharing of skills. On the other hand, peer respect is more to be coveted and can be measured.

Even if there were no way to reward people for being great team members and mentors, imagine how much more pleasant it would be to work with a team of capable, motivated partners instead of a mixed bag of people who don't really have the on-the-job opportunity to up their game in a meaningful way. It's an exciting thought.

All members of a team can grow and teach and develop in an agile pairing environment, and this makes the company stronger as well. It will fly in the face of some classic motivational schemes, but Agile is a little counter-intuitive that way.