I have been working as a software consultant for more than 11 years. Because of that I am an eager supporter of lean principles and agile methods.
The main problem with peer reviews (or software inspections) is that they belong to a traditional way of looking at software development. In agile methods there is no need for peer reviews.
In traditional software development (waterfall, V-models and RUP) testing is pushed to the end of the development cycle and because of the very long cycles/iterations it becomes expensive to find and correct errors. To cope with this problem it is often considered, by the QA, to be a good idea to introduce peer reviews to find errors earlier in the cycle. However this is only treating the symptoms instead of finding the cause of the problem. One problem is that the process is too heavy and instead of slimming the process, adding peer reviews makes it even heavier.
A better way to solve this problem is to introduce agile ideas into the process e.g. short iterations to get quicker feedback, working closely with the end users, collective code ownership and using testing to support the development instead of just finding errors i.e. test driven development.
Software Inspections - an article by a guy who is thinking in a box, and who probably doesn’t agree with my article since he makes a living from inspections. Read his article to see the waterfall approach and treating the symptoms instead of attacking the cause.
Update [2006-08-22] Some views on code reviews:
Code Reviews Considered Hurtful
The Spirit of Code Reviews
Peer reviews exist in agile practices as well. Also, pair programming is a kind of Instant Peer Review(TM).
Left by Fredrik on May 17th, 2006