How to document and peer review design in scrum? [closed]

Question

I am a relatively new developer in a small business (a team of 3 developers and an equally small QA branch) working on a medium-sized system. The current iteration is still under 100k lines of code (server & client combined), but I could imagine that, in the long term, the total size could be 200 kLOC or more. We are attempting to use Scrum for development, and we are working towards a CMMI level 2 appraisal.

We are adopting peer review methods to verify our software design and source code. We elicit software requirements during the sprint planning meeting, and we document the software requirements in a master SRS. This also gives us a start into the software design, but we don't have a formal method for reviewing design concepts, such as OO design, UI design, re-usable design patterns, and more. For our source code, we are trying new techniques, such as using spreadsheets to document over-the-shoulder reviews and e-mail pass-around reviews, but it can be difficult for the reviewer to understand the design concepts from just looking at the source code.

(Please excuse me if I am misrepresenting concepts; we are attempting a lot of this from scratch.)

We are not averse to using UML to express classes, objects, software interfaces, event patterns, or other design concepts, but we are not sure when or how to peer review our design efforts. Often, a developer can be 70+% complete with a user story and realize that a fundamental design element needs to be changed (and, subsequently, peer reviewed).

In an attempt to avoid open discussion on the topic and promote concise answers, I'll try to propose two specific questions:

1. Does anyone know of any good resources (i.e. books, papers, articles) on the best practices of peer reviewing design concepts?
2. I have read that the code itself is the (implementation of the) design. Can the peer review of source code be utilized as the peer review of design?

Thank you.