TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Finally, there is the issue of coding standards. Because ideas of pair programming, collective ownership, and (let me not forget to mention) minimal documentation, it is critical that all of the code follow very strict guidelines. In this environment, "you simply can't afford to have different coding practices. With a little practice, it should be impossible to say who on the team wrote that code" [1].
Agile . since Jun 23 . Index . DOCs TOP TOC
Even the most casual reader will note the kinds of differences between CMM strategy and that of agile development. CMM is an organizational religion. It is intended to define relationships between large organizations, not unlike the medieval church. Agile development, on the other hand, if not a personal religion, is surely the religion of a small group (the team). Where CMM defines large external measures of obedience, agile development focuses on individual/small group responsibilities.
Where CMM is often referred to as a heavy or rigorous method, it is clear that individual contributions in an agile development "church" are much more closely scrutinized by the fellow members of the local church. Similar to many of the early Protestant sects, agile development insists on very proscribed behavior, which, in turn, assumes a high skill level among the team members.
A second factor that one observes when looking at agile development is how closely a series of psychological group dynamics, beliefs, and research are woven into the approach. People work better in groups, so we program in teams; code review is good, so we always have pair programming; output-oriented design is good, so we incorporate test-first development; people work better with enough rest, so we institute the 40-hour work rule.
In a typical CMM environment, organizations can organize any way they want or use any method they want, as long as they commit to doing the same things the same ways, measure what they do, and try to improve it. Agile development is a much more tightly integrated package. You can't decide to implement items 1, 4, 6, and 9 (out of the 12 ideas Beck proposes) and leave out the rest. Indeed, if you listen to many of the agile development gurus, you need to commit to the entire program if you're going to be truly successful -- each of the 12 items above is there for a reason, and taking any one item out can jeopardize the entire program.
It's interesting to note here the similarity between Beck's 12 practices and Deming's 14 points of management. Like Beck, Deming stresses that you need to do all 14 if you are going to be successful in instituting a successful quality program. Organizations almost always pick and choose which ones to include in their specific program. For example, organizations routinely ignore a number of Deming's rules, especially the ones about no slogans, driving out fear, and breaking down barriers between departments.
Agile development aims at forever changing the way people develop software. In my mind, it is a much more rigorous management approach than CMM. Agile development, like Deming's quality, requires a much stronger commitment up and down the line. Moreover, agile development, like Deming's practice, requires a commitment to a very different style of management. In CMM, we see most of the responsibilities being placed upon the systems and project managers. In agile development, most of the responsibilities are placed upon the team. Teams are responsible for setting priorities and schedules, designing, testing, and delivering. The product rolls out in small increments, but in an almost Japanese fashion, where individuals are not accountable except as part of a team.14