For me, like many others in our field, talking to people and collaborating wasn't as natural as coding and designing.
I never needed to talk out a design, it would just happen. I loved creating software and I was quite good at it. In a few short years I went from code monkey to architect and project engineer.
In all this time, I never developed a sense of team, community or sharing. I had a hard time communicating my designs; I never thought about them, I just did them. I had difficulty listening.
When I first got to Oxygen, with only pair programming, I was completely frustrated. I was use to excelling and being the hero of the team.
At pairing and communicating I, well, let's just say it didn't come so naturally.
For me, the most difficult part of pairing and code ownership is giving up what's best for you and substituting it with what is best for the team. This is a concept that is very important for the entire team's productivity and happiness.
In our world we have a lot of brilliant developers, with a lot of brilliant ideas. Our designs are more of an art than a science and with any art, it is a personal expression. This is why collaboration, sharing and pairing is so difficult -- in our minds our design is always really good.
And for each individual that is true.
But for someone else, a solution that brings you great success may bring them great frustration and pain.
What is the solution? How can we all agree? In what ways can we share our knowledge?
I'm not sure... but I think about it a lot.
While differing opinions can bring the best ideas, spending an entire pairing session (or worse days, weeks, forever) bickering about differing opinions is much worse than not bringing your ideas to the next level.
In pairing, when you have two opinions, the best option is to choose an opinion and run with it. If its not the right solution, it will be obvious right away.
However, sometimes its not a wrong decision, its just not the better solution and the pain of the decision may not be felt at that moment.
Will the frustration of the person be felt in the group? Probably not if they are sometimes heard. If your environment has a few people who are more stubborn than others, you may have some frustrated developers who need to get their way more often.
On any team, with each pair, you will eventually find a groove. How long it takes and the style of your solutions with depend on the individuals of the team. And the style you find may be completely different than what you do on your own.
Whatever gives your team the ability to keep their velocity, happiness and quality high is the best practice.
Subscribe to:
Post Comments (Atom)
5 comments:
Aaarrggg! Yeah, that team stuff is really the hardest part of the whole thing. Or is TDD the hardest part? Strange to try consider them in isolation. Isolating the practices always feels pretty arbitrary... like trying to delineate the internal organs or an earth worm... :) Oh well, not many valuable conversations would come out of talking about XP without arbitrarily isolating its internal organs.
"Whatever gives your team the ability to keep their velocity, happiness and quality high is the best practice."
So how does Oxygen incorporate their chosen methodology (hard core XP and paired programming) into their HR practices? I agree with your comment about giving a team whatever they need to be the most productive...but it almost sounds like Oxygen is trying to establish the methodology regardless of the people participating in it?
I can see pair programming working when you have the right people with the right personalities doing it, but to make it a company-wide standard...just curious how that's worked out.
D
d'arcy,
We do all the hiring, as in the team -- we only pick people who will fit. For the most part, we're all new, so we fit together pretty well.
Some teams have people who may never fit into an agile environment. I've worked in these situations and making decisions about what to do then is tricky. Agile is about adapting to change, becoming aware of risk and making everything visible. Unfortunately, people don't change easily no matter how much your environment allows for it.
I'm a fan of fitting the people to the people and seeing what happens :)
I love your introspection and insight. And Scott's awareness of the hard parts.
Teaming is hard in everything, not just programming. Relationships, business, dancing, you name it - any time you have to consider putting aside the eminence of your own ego in favor of a group/team goal.
In programming, we so often identify with our code, that it's more obvious. "My code does..." and "your code shouldn't..."
@d'arcy: You might be interested to know that when we started growing the team at Oxygen and doing pair programming more consistently, one developer who had been at Oxygen for about a year basically opted off the team and left the company because he didn't like working that way.
-Luke at Oxygen
Post a Comment