Kurt King says (by email 11/6/2009):

I meant to add to my invitation that since I only have book learning on
this subject I hope you can help me. Personally, I'm not worried about
XP working for a talented person or group.  The arguments against it
relate to the organizational context which requires written
communications.  One issue is establishing and growing a requirements
document that is traceable to test cases.  Then the organization paying
for the effort needs documentation that they can understand.  This is
actually an area of current work – not settled at all.  And I'd like to
find a way to do it – at least at the IT Plan level, so that when an
appropriate project/team combination comes up the groundwork will have
been done.  

In contrast, the traditional methodologies that are in the current text
supported (more or less) those information needs, I thought were
horrendous to use. 

Here
is part of a book on auditing XP.

While I was looking for references on auditing agile I found
this great letter
describing Agile.

Name: "Dave Nicolette"

Home Page: http://www.davenicolette.net/agile

 

In the context of agile development (done properly), I
think the perceived risk of the rogue developer is mitigated to a great
extent just by the use of agile practices. To be considered "agile" at
all, the team will be almost certainly use at least two of the
following practices:

1. Pair programming.
   It's harder for two people to collude to commit fraud than for an
   individual working alone to do so, although it is still possible. When
   pair programming is done right, people switch pairs at least once a
   day; this further mitigates the risk of fraud by a rogue developer.
2. Collective ownership and refactoring.
   Everyone on the team has full access to the codebase and anyone can
   refactor code at any time they make a professional judgment that it is
   necessary. The team is accountable for code quality and delivery of
   value, both collectively and individually. All it takes is for one team
   member to notice something fishy, and the proverbial jig is up.
3. TDD (including refactoring).
   All new features and modifications are normally developed in a
   test-first fashion, which exposes any questionable application behavior
   very quickly. TDD also implies the codebase is accessible and often
   reviewed by all team members in the course of their everyday work. Even
   if a would-be rogue plants a logic bomb, it will be noticed by another
   team member within minutes (assuming the team uses continuous
   integration). This characteristic of agile development acts as a kind
   of filter to catch questionable code (even though that isn't its main
   purpose).
4. Code reviews. While not a
   "standard" part of agile methodologies like XP, most agile teams do
   carry out peer code reviews, typically once per iteration. This is yet
   another filter that can catch questionable code.
5. Small team size, team collocation, and daily stand-ups.
   When a small group of people occupy a small physical space together
   practically all day, every day, it becomes very difficult for anyone to
   hide anything within the codebase.
6. Agile recruitment and hiring standards.
   The fundamental agile values of transparency, trust, collaboration, and
   courage call for team members of good character and high ethical
   standards. The sort of person who would act as a rogue developer is
   unlikely to last very long among such peers, even if he/she managed to
   fool everyone long enough to be invited to join the team.

And here
is an article describing clearly when not to use Agile methods. 

And here
is a very interesting article where Steven Rakitin talks about living
through the Methodology Wars as I did.  He leans more toward the
formal-process camp, but discusses both sides fairly.