- the risk of establishing processes that are either inadequate (thus leading to project-level sub-optimization) or are significantly divergent from organizational norms making it difficult for skills and experience obtained on one project to be effectively transferred to another (thus leading to organization-level sub-optimization). By identifying these gaps early, response plans utilizing mentorship, formal training or even process automation can be initiated while such actions are still likely to meaningfully influence the project's ultimate success.
- Teams buy into implementing defined processes, providing a set of baseline expectations against which performance can be gauged. Periodic assessments provide opportunities to identify improvements and extract best practices that can be leveraged elsewhere within the organization. Importantly, such assessments may be used to reward teams and reinforce good behaviors, but never for disciplinary purposes.
- Accountability assumed by project leaders for implementing defined processes goes hand-in-hand with a firm expectation that they will transfer best practices to their team members (primarily through just-in-time coaching). Thus, current leaders act as change catalysts by growing the next generation of agile project leaders within the organization.
Figure 1: A process adoption plan shown in the Sapient|Approach adoption management tool
Agile teams thrive upon a deep-rooted commitment to doing the right thing for the customer. Delivering on this promise requires that teams embrace changing requirements, stakeholders, and project constraints, and commonly such changes warrant modifying process accordingly. Merely defining process is therefore insufficient for the purpose of ensuring ongoing implementation of best practice. Similarly, project teams should not change process merely for the sake of doing so. Thus, periodic audits are appropriate for ensuring that teams hold themselves accountable to established process adoption commitments, deviate from those commitments only as necessary, and leverage innovations.
The mere mention of the word "audit" is often enough to send shivers down the spines of developers and project managers alike. More often than not, audits conjure up images of armies of grim-faced, clipboard-wielding consultant-drones that are in the best of times a slight distraction and at the worst of times a significant drain on the team's energy and productivity. The team's relationship with auditors is generally cool if not downright adversarial in the most extreme of cases. However, audits can prove themselves of value to both a project team as well as the organization-at-large if approached with a cooperative spirit. Re-casting audits as a program of retrospection, current-practice assessment and coaching helps to remove some of the stigma associated with this term.
A thread of recent posts to the Agile Management email group has significantly progressed this idea.  One contributor suggested that project managers regularly observe one another's projects and debrief on what was seen. Another described a scenario wherein a team claimed that it had "tried" pair programming and it had "failed" when in fact it had two people sitting in front of a computer at the same time but they were not following the "protocol" associated with this practice (e.g. writing unit tests first, switching roles within pairs, rotating pairs, asking pertinent questions about the expressiveness of the code). Both posts point to the value in obtaining an objective "second opinion" and suggest that doing so is compatible with the values enshrined in the Agile Manifesto and does not suggest a shift away from individuals and interactions in overwhelming favor of processes and tools. 
Closing The Feedback Loop
Team retrospectives are a common practice amongst agile teams. They are used to encourage collaboration and reuse by surfacing best practices and improvement opportunities within a project context. However, in practice, retrospectives generally do not facilitate the transfer of