I wrote about how frustrurated I was with people who abuse the word agile.  It's a big problem right now.  A lot more people are learning about Agile Development and unless people understand what the real values are, it is possible that this whole Agile thing could fail.  People will try it in wrong ways and they will say "Well, I guess this doesn't really work".  Arrrggg.

Recently, there was a thread in an Agile Development mailing list about pair programming.  One person asked people to give feedback on pros and cons of pair programming vs. peer reviews.  Guess what was listed under pros section for pair programming.

Developers don't browse Internet during worktime.

Are you kidding me?  What were you going to do with this item?  Show this to your development team as a part of benefits of pair programming?  And immediately lose their trust?  Or hide it from your developers and just show it to your manager?  And still lose trust from your team?  Are you out of your mind?  It gets worse.  One person replied to the original message and I found this.

Another benefit of pairing not touched upon yet is the fact that peer pressure will push people to produce and not waste time (surfing the web, taking mental breaks, checking stocks, personal email, etc).

Can you believe it?  Put peer pressure to push people to produce and not waste time surfing the web, etc.  What a great way to build a team with passion!  I am constantly troubled by the people who strongly believe they know what Agile is about but in reality use it as a way to get more things out of developers.  Agile does <keyword>eventually</keyword> increase the productivity.  But Agile is more about delivering the right thing to your customers in a right way.  It's not about using these cool techniques such as pair programming or TDD to push developers to produce more.  If you do not change how you think or how to treat your developers and your customers, it doesn't matter if you have a super-duper-pair-programming-TDD-addicted-constantly-checking-code-in team.  Agile development is not a technique.  It's a culture shock and mind-shift! 

Please, get it this time!

* In case you are interested, below is my response to the thread mentioned above.

<youngjoo response>

I know this is a bit old topic but I want to give my two cents about one of the benefits of pair programming listed in this thread.

- Developers don’t browse internet during worktime
- …peer pressure will push people to produce and not waste time (surfing the web, taking mental breaks, checking stocks, personal email, etc.)

If you approach a developer and add this to one of the benefits of following Agile practices, you will NEVER win them over.  I believe people sometimes mis-understand the core value of Agile development practices.  Making people do more is not the goal of Agile.  The core goal of Agile is to develop the right thing in the right way.  If someone does a research on time/money wasted by developers browsing the web, taking mental breaks, etc and waste caused by building the wrong thing in a wrong way, I am very confident that the first case won’t even show up in the research paper as a main cause of development productivity loss

Admit it.  There is no way in hell to force someone to be 90% productive.  You will be lucky if you spend 50% of your time doing actual coding.  Writing code is a very intensive activity, especially to your brain.  It’s not a mechanical activity.  If you sit in front of the computer and code away 90% of your day, everyday, then you will eventually burn out and constantly deliver poor quality code.  This is why Agile advocates size-based estimates instead of time-based estimates.  It doesn’t matter you spend 10 hours or 100 hours to get something done.  What really matters is how much customer value you added during last iteration.

Agile practices solves productivity problem mostly by getting it right the first time and provide an environment to make changes very quickly if you didn’t.

</youngjoo response>