Timely Code Reviews. Code reviews are well-documented as an effective tool for reducing bugs and improving the quality of software produced. Given the ideal frequency with which code is checked in, however, a traditional formal code review is impractical. Emanating from XP are several techniques which provide critical review within the fast-paced cycle of each Sprint including:

• Shared Ownership. The concept of shared ownership considers the codebase owned by the team as a whole; thus, each team member can be expected to review, fix, refactor, enhance, or otherwise work on, code they may not have written.

  Other than specialists with expertise in areas such as networking, threading, databases, etc., developers are generalists lacking in-depth knowledge of any given area of a product. By its nature, this aspect of shared ownership is its biggest flaw limiting the effectiveness of code review; in reality a generalist will likely not be familiar with the requirements a given block of code is meant to address thus rendering his/her review less effective.

• Swarming. In practice, swarming involves team coders working on one or a few stories concurrently rather than each working on an assigned story in parallel. As with shared ownership, stories are considered owned by the team not the individual. Developers are encouraged to actively work on the same story from initiation through check-in. Typically, once the author completes coding, other developers will begin follow-on processes to include review, refactoring, and, to the extent necessary, extending the code.

  Swarming ensures timely review and overcoming a frequent criticism of code review - that the reviewer is not sufficiently familiar with details of the story on which the code segment is based.

• Pair Programming. Pair programming, as the name implies, requires two developers to collaborate on the same code segment. Like swarming, pair programming provides real-time review.

  However, by its nature, pair programming can be difficult to implement and is arguably inefficient. Unlike swarming which permits each developer to work on a discrete tasks in parallel, pair programming requires each developer to work in a tethered fashion completing tasks in a serial fashion.

Static Code Analysis (SCA). Code analysis tools permit developers to test code for vulnerabilities outside of a run-time environment; examples of discoverable issues include security flaws (buffer overflows, format string errors, etc.), deadlocks, and functions that code be called with null or uninitialized parameters. Note that SCA tools cannot determine that code is robust enough to address all acceptance criteria; validation of nature must be addressed using automated unit testing or manual Peer Review.

Frequent Check-ins of Smaller Batches. Frequent check-ins are good for traditional teams but are a critical a pillar of the agile development process. A small piece of new functionality is considered qualified for check-in to a shared development platform when coding has been finished, a clean local build completed, appropriate unit tests have been coded, and automated comprehensive unit testing has been completed to ensure no regressions have surfaced.

Frequent check-ins uphold the principle of “continuous integration” enabling project managers good visibility into daily progress of individuals as well as of the team as a whole. Consistently followed, the practice can reinforce a team’s sense of accomplishment and, importantly, of momentum.

Importantly, frequent check-ins reduce risk by permitting suboptimal error prone code to be identified sooner thus enabling a timely rollback so as to limit potential loss.

Worth noting, absent use of one of the code review techniques discussed above, a formal pre-check-in code review could work against the practice by creating a bottleneck should a qualified reviewer be available when needed. A reasonable solution would be to enforce a timely post-check-in code review.

Continuous Automated Integration (CAI). A CAI process, typically used on larger projects, automatically pulls checked-in code onto a continuous integration server along with the related unit tests; it executes a verification build, and runs a comprehensive suite of automated acceptance & unit tests. Integration tests include those to validate APIs, other interfaces, and data formats.

CI encourages reuse and sharing of code by making it accessible to the Team upon its integration. It ensures Integration Engineers are promptly made aware of integration errors or conflicts. Repetitive labor-intensive and error prone aspects of the testing process are eliminated. Its efficiency reduces use of resources, increases code quality, and provides real-time visibility into the status of the system development process vis-à-vis the project schedule.