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 Anurag Shrivastava mid-afternoon: January 28th, 2009
You never believed in it. You wondered if it could ever have worked for anybody in past two decades. However, it has arrived. You are going to work Agile and worst still Distributed Agile Offshore. You were skeptical about this right from the beginning when it started in your company but no one would listen to you.
Here are 11 tips that will ensure early death of a Distributed Agile project:
(more…)
Posted by Guido Schoonheim in the late afternoon: August 21st, 2008
Agile 2008
At Agile2008 in Toronto Jeff Sutherland and myself presented our article outlining how to achieve hyperproductivity in distributed Scrum when working in an offshore situation. InfoQ recorded our presentation and will publish it online in November as the end of a series of Agile2008 talks.
Download article Download presentation
Also see this InfoQ article
Agile and Offshoring, oil and water?
If you are reading the Xebia blog chances are that you are already familiar with the benefits of Agile development. Practicing Agile (in our case Scrum combined with XP) delivers hyperproductivity combined with very high quality. The promise of offshoring in the modern IT industry is also clear: more available talent, scaling up and down without local layoffs or knowledge drain, and of course cost reduction. Together they make a killer combo!
However, Agile and offshoring seem like oil and water, they don’t seem to mix. 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?
(more…)