Code Reviews in Agile Teams

• http://blogs.atlassian.com/developer/2009/11/code_review_in_agile_teams_part_i.html
• Code review is even more important when a really junior developer joins a team. Senior developer don't have time to hand-hold the junior folks, since they need to be coding. That said, doing small but frequent code reviews of the junior developer's code is no big deal. The result? Senior developers can focus on writing code for most of the day and spend a 10-15 minutes a couple times per day to review the code changes by junior developers. The junior developers benefit from feedback, and the senior developers haven't lost valuable coding time.
• In the next instalment I'll share a few pieces of advice and precautions related to implementing code review in an agile team or company as a standard process. 
• http://blogs.atlassian.com/developer/2010/03/code_review_in_agile_teams_part_ii.html
• Keep it lightweight
• Don't force it
  Don't micro-manage
• Encourage asynchronous reviews
• Actively share interesting findings, constructs, design decisions via code review - be the champion
• Treat code review as yet another state in your project workflow
• Small and frequent over large and rare
• Concentrate on the code and conversation, not on the code review tool and its endless capabilities
• Do not include too many reviewers
• http://www.atlassian.com/software/crucible/learn/whitepaper.jsp
• Formality Spectrum (most formal first)
• Inspection: An inspection follows a well-defined procedure that includes six stages:
  planning, overview, individual preparation, inspection meeting, rework,
  and follow-up. Certain participants have assigned roles: author,
  moderator, reader, and recorder. The reviewers use work aids such as
  checklists of the types of defects commonly found in certain work
  products to carefully examine the work product for possible errors. Data
  collected is used to improve the organization’s inspection process and
  software engineering processes.
• Team Review: Team reviews are planned and structured but are less formal and less rigorous than inspections. The overview and follow-up inspection stages
  are typically omitted, and some participant roles may be combined. The
  author might lead a team review and the reader role is omitted. Instead,
  the moderator asks the reviewers if they have any issues on specific
  sections of the work product.
• Walkthrough: A walkthrough is an informal review in which the author of a work
  product describes it to a group of colleagues and solicits comments. The
  Author takes the dominant role; other specific review roles usually are not
  defined. Walkthroughs are informal because they typically do not follow
  a defined procedure, do not specify entry or exit criteria, require no
  reporting, and generate no metrics.
• Peer Deskcheck: During a peer deskcheck only one person besides the author examines the work product. A peer deskcheck can be fairly formal if the reviewer uses defect checklists, analysis methods, and standard record forms.
• Passaround: A multiple, concurrent peer deskcheck is called a passaround. The author delivers copies of the
• An effective code review support tool will include the following characteristics and capabilities:
• Make it easy to begin holding reviews.
• Impose a very low administrative burden.
• Notify participants of forthcoming reviews and review results.
• Easily collect review comments in context.
• Enable threaded discussions.
• Facilitate an established formal review process.
• Provide customizable metrics generation.
• Provide comprehensive reporting of review results.
• http://www.ambysoft.com/essays/whyAgileWorksFeedback.html
  
• Defect found via review or inspection costs more to fix than defect found via pair-programming