Agile Otter Blog

Overall, pair programming isn't as controversial as you've heard. It depends on your styles of pairing. Some styles of pairing are very common, even among non-agile teams. They tend to be episodic, and last just long enough to get or give some aid. The good news is that they work. If a team views pairing with trepidation, these are common, non-threatening forms to start with: Rescue Pairing Training Pairing Brainstorming Experimenter/Researcher Others are such bad ideas that they are rightfully avoided by all sane teams I've seen so far.  If you are considering pairing, and a team member balks, you should see if their mental model of pairing matches one of these styles. I suspect a team should decide that these styles will never be practiced personally, or tolerated within the team's pod.  You have my blessings to object to pairing if "pairing" means: Worker/Rester Worker/Watcher Master/Slave Bully/Victim Writer/Critic Ball-and-chain pair marriag...

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 s...