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 Geert Bossuyt mid-afternoon: April 19th, 2010
When two workmen are working on the same house but each of them uses a different plan (Off course they both think they are using the same plan), the house will not end up to be the intended house. Also, these two men will have a very difficult time appreciating each others work. What will you learn if you act perfectly according to the plan and someone tells you it sucks because he’s using another plan? You will either learn that the other guy is stupid, or you will learn that clearly you’re not as good as you thought you were. Both lessons are useless. Neither you, nor your collegue will improve your individual skills or your mutual ability to work together. So, the differences between the two plans will only become bigger. It’s impossible to be succesfull in this way.
Posted by Geert Bossuyt at around evening time: April 12th, 2010
This curve reflects some ideas on how and when a coach can take the lead and with what purpose.
Would you agree ? Or would it need to be an ongoing wave ? What about the phases … any important ones missing ?
Posted by Luuk Dijkhuis around lunchtime: January 20th, 2010
We as Agilists are extremely result driven: delivering value to the customer as soon as possible is the axle around which our work and vision revolve. This can help us but also hamper us in the process of bringing Agile to a non-Agile environment. Being aware of this may already help us be more effective in bringing about changes in an effective way. The question “is this a quick-change or a slow-change organization” should be an explicit part of your analysis. Be patient!