Posted by Iwein Fuld in the early evening: May 9th, 2010
Without exception in all teams I’ve developed software in people have expressed their aversion against pair programming. It’s not that developers don’t want to try, or that they don’t believe it will help. On the contrary, they are usually very enthusiastic about trying it and give it more than a fair chance. After a few days they sit alone behind their keyboard coding like zombies with headphones. What’s going on? Is pair programming too hard? Doesn’t it pay off? In this post I’ll try to explain what I think is happening, and I will give you some clear pointers to avoid the traps. At the end I will go into distributed teams and what part of the game changes there.
So what are people saying when they have stopped pair programming and you ask them why:
- I’m faster on my own
- Can’t pair with that guy, he’s getting on my nerves
- Pair programming is too tiring
- We’ve split up the work and we’ll get it done faster if we use two keyboards
- There’s too much background noise
- I’m just slowing her down
Some of this might sound plausible, so let me axe that down first. No you’re not faster on your own, you’re just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you’ll turn into a better programmer. Or maybe you can teach him something and he’ll stop getting on your nerves. If your code is so simple that you can split up the work in advance you’re writing it on too low an abstraction level, or you need to work on this in two pairs. If you’re slowing the other guy down, that’s a good thing. That will prevent him from writing code that you cannot maintain. If you don’t feel worthy of your colleagues code, get over it, or get off the team.
(more…)
Posted by Guido Schoonheim in the wee hours: August 26th, 2009
Agile2009 is the yearly conference of the Agile Alliance. This year we are in the windy city, Chicago. With over 1350 participants, 300 presentations and over 1500 initial submissions, this conference really is the cream of the crop on Agile software development.
This year I had the honor of presenting a case study on Fully Distributed Scrum together with Jeff Sutherland, co-founder of Scrum.
We presented about a Xebia client located in San Francisco working with our office in new Delhi using a single hyperproductive distributed Scrum team! Thats right, hardcore Agile results across all timezones, culture, language etc.
(more…)
Posted by Guido Schoonheim in the early evening: March 9th, 2009
Working distributed is all about handling distance. Geography, culture, methods & tools, timezones, languages are all adding to that distance. Not measured in miles but in people.
How to get a focus on individuals and interactions when your people are distributed across the globe? What is the secret sauce to use to get it running smoothly?
The classical route of bringing this ‘gap’ under control involves adding process and handovers. It actually forces you to go into a waterfall-like model and therefor widens the Gap instead of bridging it. All waste is institutionalized. Sounds like a horror to you? It does to me.
(more…)
Posted by Anurag Shrivastava at around evening time: February 1st, 2009
You have opportunity to work on an Agile Offshore project. It simply means now your project can be delivered faster and cheaper if you get it right. I would like to share some tips with you that have helped Distribute Agile Offshore projects become successful:
Before I write about 11 tips to make a Distributed Agile project successful, I would like to start with Tip #0.
Tip #0: You should have technically bright people in the team. This is a prerequisite to make a Distributed Agile Offshore project successful. My other tips will not make technically dull programmers deliver a successful project.
(more…)