Agile is openness and collaboration, it takes courage and vulnerability and that scares people and we should be mindful of that. My post “The Shame of Pair Programming” is attracting a lot more attention than I’m used to. The comments range from “I feel that too” to comments that I could summarise as, “we just want to code” and I worry about what happens when an organisation pushes Agile onto a team. I guess it fails or they leave. Where do they go? How much do they suffer? What are the effects of that?
There is a ray of hope in a comment from James Scrimshire, he sees newer developers happier to pair. Perhaps the new generation, the Github generation as I’ve heard it called, will just see collaboration as part of software development and won’t feel this fear.
Today I coded alone, it was fun because the work was simple. If it had been complex, I might have been fretting, frustrated, fearful, lost or despondent. I need support when I struggle. I often need someone to remind me to do the right (not the easy) thing. A pair helps me find the courage to try something new and leave my comfort zone, and I when I go too deep, I need a friend to point out when to turn back. In our macho, male dominated culture that makes me feel weak. Perhaps in the future that culture will change and we’ll recognise the strength needed to ask for help. I see how much more effective we become when we do; less days spent digging rabbit holes when we could be building paths.
Diary of a ScrumMaster 
Hi Tom,
Thanks for sharing your thoughts on pairing, I’m really enjoying this series.
My current challenge doesn’t even get as far as working with devs to overcome their concerns with pairing. I’m faced with a rather stubborn attitude that states “we have not resourced this project for pairing”. When I hear this my thoughts always drift to an Ackoff quote: “the performance of the system is not the sum of its parts but the product of their interactions”. Anyway that’s a different story.
I think pairing brings a myriad of challenges for the people on teams some of which I documented in a since dead posterous blog. I plan to revive it soon but here’s a copy of the post from my dropbox, “The Dysfunctions of Pair Programming”. https://dl.dropboxusercontent.com/u/49058746/the-dysfunctions-of-pair-programming.html
We’ll both be at lkuk13, would love to discuss further there.
Chris
I posted my thoughts a while back on a since deceased posterous blog
Hi Chris
Thanks for the comment. “we have not resourced this project for pairing” 😦 Sound like you have a long job ahead, good luck.
I really enjoyed reading your post. I think your point that you need to have a team that trusts each other first is a good one. I’m not sure if you have read in other post but I work in a team where the majority of the members have been together for 10+ years so we have had plenty of time to develop that trust. I think there is a lot we can do to actively encourage trusting relationships and the vulnerability needed to collaborate effectively so that it needn’t take 10 years though, something to discuss at lkuk13.
Looking forward to meeting you
Tom
The issue is really to build trust, for people (even if they are developers) to talk openly and learn how to communicate without violence.
Even before pairing, are people ready for peer code review?
One ceremony I found cool is a code-pizza party.
The procedures:
– Schedule 90 minutes for the team
– Buy Pizza&Cola (or your local equivalence)
– 30 minutes before the meeting pick a developer at random (theoretically 😉
– Ask her to pick a class that intrigues her
– Read the code together and discuss it as a team while eating & drinking
The goal is NOT to fix the class, but to reach a common language, discuss coding standards, readability, etc. so your role (the SM?) is to gently block any criticism (even if the developer of the class is long gone) , encourage people to express opinion, and demonstrate cooperation.
Another idea – try a game of group programming, take a task that is estimated as easy for an expert, and rotate the keyboard – while the expert is not allowed to touch it.
To sum up (as we said over beer last week) – gamify.
Thanks Dov, code-pizza party sounds interesting. I can also imagine doing it with people new to the team even as part of an interview process.
A pizza for every candidate?! wow! you must live in the fast lane!!
Hi Tom, Chris – It’s peculiar that those who have “not resourced this project for pairing” are apparently fine with resourcing the project for a bureaucratic change control and code review process (that can easily end up blocking developers for half of their time, whilst actually resulting in lower code quality).
Hi David,
It is for those who understand the benefits of collaboration and can trust others to do their job. For someone who struggles so much with those concepts that they have to be present for every discussion members of a team have and has to have a say in every decision it seems like a reasonable excuse.
As Tom said there is a long job ahead 🙂
Chris
“The issue is really to build trust, for people (even if they are developers) to talk openly and learn how to communicate without violence.”
Good point. I have been involved in an altercation on a team that almost turned violent. I think you need a certain level of emotional intelligence to be trully effective in a team. I’m not sure about others, but i have been in so many teams, with so many devs, and many have sorely lacked the maturity to handle effective collaboration.
Often, those with the biggest programmer ego’s are also the ones with the lowest self esteem, and require constant “look at me” attention. Imagine the joy in pairing with someone like that. I can tell you that feeding/defending against someones ego all day is energy sapping work.
It would be nice if we could weed out the bad apples, but often, especially in some markets, thats not an option, you take what you can get.
When I read about our macho male-dominated culture in your post it made me think about the “it’s not the people but the system” approach.
The cultural aspect is really important, as I say it. Having ranking systems in place to differentiate who’s better from each team is not unusual. I have seen organizations blaming individuals when they ask for help because they “slow down the team”, managers that, encouraged by their HR assistants, foster competition between their team members, and teams that are forced to implement shortcut after shortcut, acquiring a level of technical debt that kills any opportunity in whatever they were trying to built, failing and learning are impossible in extremely risk-averse organizations… All these situations create the perfect conditions in which pairing can be useless, shaming and painful.
You were right in mentioning the culture, the system in which you operate makes your team able to work in pairs, while some other teams are unable to do it.
As someone who watches pairing, but doesn’t pair, I found this series of posts enlightening. It took courage to share and we are a better community for it. Thank you.
In a serendipitous event, my team had an hour long retrospective about pairing the same day I read your first post. I link to you post within my own write-up. http://goodrequirements.com/2013/pair-programming/
[…] headset on. We learn from each other and challenge each other. We keep each other honest and out of rabbit holes. When things get tricky we grab another pair for a quick swarm. There is banter, it’s fun and […]