One of the key resources for Extreme Programming is that of Ward's Wiki aka Portland Pattern Repository aka C2.com. This is where a number of people hashed out various methodologies and documented them as they used them.
Within this wiki, there is a page: Extreme Programming Code Reviews that has a number of contributors to it, including Ron Jeffries and Kent Beck.
To this, they said:
Code reviews are considered important by many large-process gurus. They are intended to ensure conformance to standards, and more importantly, intended to ensure that the code is clear, efficient, works, and has QWAN. They also intended to help disseminate knowledge about the code to the rest of the team.
ExtremeProgramming requires that all development is done by two engineers working together. The code is actually reviewed on the fly, to quite a great degree. This ensures that more than one person has intimate knowledge of the code at all times.
ExtremeProgramming requires that all objects have UnitTests. These ensure that the object works, and continues to work as modified.
Some languages are reflective. In such languages, UnitTests can check directly for important standards conformance. (e.g. objects must implement both #= and #hash, or neither.)
ExtremeProgramming practices CollectiveCodeOwnership, which means that objects needing attention will be browsed by many developers. This tends to bring pressure to bear on those producing code that doesn't conform to standards. Visiting developers are encouraged/expected to bring code into conformance when they find deviations. This also ensures that knowledge of code is disseminated beyond the initial pair of programmers that created it.
Therefore, ExtremeProgramming projects do not require explicit reviews. Drop them from your methodology.
There is also quite a bit more discussion on the topic there from others.
The key points though being that with the combination of tests, collaborative ownership and pair programming these things resolve the goals that a code review is typically supposed to do such as:
- Disperse the knowledge of what is being done
- A second (or more) set of eyeballs on the code to make sure it is following standards
- Verify correct functioning of the code
These are being done continuously through pair programming and automated testing in Extreme Programming and thus an explicit Fagan inspection is unnecessary.