In software development, we see different types of reviews in different organizations. For example, there can be architecture review, design review, and code review, and they can occur in different phases of development. The aims of these reviews can differ as well — the goals could be, for example, better solutions or better quality control. Generally, different kinds of review are necessary and helpful for the organization to achieve better software that's easy to maintain and evolve.
Among all these intentions, I believe the most important one is to try to identify possible (usually big) flaws/impacts/constraints/defects as often and as early as possible via peer and expert review from different viewpoints. So appropriate review should help secure a smooth systems development life cycle, with good results. However, when it comes to Agile development that relies on the self-organization of the Agile team, conflicts can arise.
In Agile and self-organization, we hope to empower the team as much as possible, letting it decide the best means of design and implementation. What does the reviewer do, and will the review impact or break the team's self-organization practices? Reviews are usually done by experts from outside the team. Their opinions are usually important and should be followed, or at least considered, by the team.
At a certain level, I do believe that such review from outside the Agile team can impact the level of "pure" self-organization, since review brings in more people who can evaluate the product increment from different viewpoints. But will a review really break the agility and self-organization of the team? I believe not.
Reviews are needed for different reasons. If they're not needed or aren't beneficial to the organization, of course they should be reduced or removed from the life cycle. But let's imagine here that they are needed and useful. We can take it as an internal requirement that should be weighed, just like the external customer requirement. If we can use self-organization to meet external customer requirements well, we can use it to meet such internal requirements as reviews.
Use the same technique we use to communicate with customers: Engage in face-to-face communication, involve the reviewers as early as possible (don't wait till the last minute!), and try to continue such communication regularly during the life cycle.