Definitions and suggestions for enforcement.
One practice we have come to value is that another team member reviews and accept a task before it is considered done. This should not be a time consuming or formal process! The obvious advantage of this practice is the Quality Assurance aspect: The chosen solution is verified by another pair of eyes. This often leads to suggestions for improvement. Another benefit is that knowledge sharing within the team comes at very little cost since at least two people will know any piece of the application.
Peer programming might be considered an extreme version of this practice. The Definition of DONE! 10 Point Checklist seems like a good starting point for defining DoD. Note that that this they accept pair programming as "enough" for done. Pair programming is only that two people is programming together, while peer entails that the two are at equal competence level. Peer programming is a lot better for QA than pair programming, while both support knowledge transfer. We would thus suggest that peer programming automatically entails acceptance of the produced code, while pair does not.