Much has been written about the commonality or even the lack of it between Agile and CMM. CMM claims to be a flexible model that can be tailored and adapted to many life cycles. The continued discussion is evident enough that it is not sufficient to compare practice to practice and arrive at any reasonable conclusion about their overall compatibility. The one difference that seems to have earned consensus amongst most of the published literature on the subject is "the people aspect" of these models.
Much has been written about the commonality or even the lack of it between Agile and CMM [1,2,3,4]. CMM claims to be a flexible model that can be tailored and adapted to many life cycles [4,5,6]. This facilitated attempts to bring-in the iterative life cycles and practices of Agile under CMM model [1,2,3,4]. However, the debate on their compatibility continued as is evident in Kevin Trethewey‘s blog, which is one of many of its kinds.
The continued discussion is evident enough that it is not sufficient to compare practice to practice and arrive at any reasonable conclusion about their overall compatibility.
The one difference that seems to have earned consensus amongst most of the published literature on the subject is "the people aspect" of these models [3,4,8]. While CMM has little people focus, Agile's foundation is people focus. In the context of Generation Y becoming a major part of the work force, this people aspect may become one of the main drivers for organizations to endorse Agile and reject CMM with or without Agile practices in it [9,10].
There are multiple aspects of CMM and its implementation makes the people aspect take a back seat. As James Bach puts it "The CMM reveres process, but ignores people." 
Following is a compilation of some of these aspects culled from the available literature..
Historically, CMMi's predecessor CMM was originally published in 1989. This date is much before the advent of Internet. Following is an excerpt from a relatively recent paper from SEI suggesting to embrace both Agile and CMM
"If we look at the genesis of the CMM, it predates the internet and nearly everything associated with internet technology. For that matter, CMM predates many software development, deployment, and infrastructure technologies, languages and methods. We've all learned a lot in the past 20 years. When the DoD set out to address their "software dilemma," the software world was different than it is today." 
CMM was mainly focused on models for high-risk, government contractor projects. In the age where there was not so much communication let alone collaboration channels established, the model had to be something that enforced accountability rather than expected it.
CMM later expanded to multiple other models and the latest being CMMi 1.2. However, the remnants of old times are present even in today's models. The following reference states that explicitly.
"While the language of CMMI, admittedly, may retain some of the flavor and phrasing of this context, each release of a CMMI model grows further away from these roots to embrace a richer and more dynamic set of contexts." 
The same paper goes on to explain how the situation worsens further by practitioners who don't move with newer versions of CMM that are made to suit to modern contexts. All this makes CMM and its newer variations a distant old relative to the current generation. With little effort anyone can relate to their distant older relatives, but it would be inconceivable that they would be convinced to live like the earlier generation.
Defined with the value system having roots in a contractually handled market system, all the relationships would be between non-life abstract entities like organizations but not people.
"CMMI for Development, Version 1.2".  recognizes people amongst the three critical dimensions of an organization. But it emphasizes that it is the processes that hold the other two. Since the technologies are changing quickly and people are regularly changing jobs, CMMi believes to entrust more on processes that can be made static and can address the other two dynamic dimensions. Following is an excerpt that draws an analogy with manufacturing industry.
"Manufacturing has long recognized the importance of process effectiveness and efficiency. Today, many organizations in manufacturing and service industries recognize the importance of quality processes. Process helps an organization's workforce meet business objectives by helping them work smarter, not harder, and with improved consistency."
The historical fears of the changing world may not be relevant today as the s/w is not organized; either in punch cards or long procedural codes. The object oriented, componentized, building block style of code with the very advanced tools does not make changing people and technologies as big an issue as it was in earlier decades.
The analogy with manufacturing to s/w industry is rather demeaning. In the industrialized world of the manufacturing industry, work is done and goods are produced by machines. Humans only operate machines that are part of a long assembly chain. On the contrary, if it is humans that have to deliver goods that too of intellectual nature, the analogy with manufacturing industry cannot withstand. The only analogy that can suit the situation would be creation of art .
It has been mostly the services/consulting companies that went for appraisals and certifications. This is the main reason why there are more Indian IT companies with more certifications than others [11,12]. It would be difficult to find product/technology development companies like Oracle, Apple, Google going for such elaborate process models and certifications. The distinction is that the technology-centric companies need not prove their ability to build new technologies to the external world. The end product in the market place establishes their capability. When it comes to consulting companies, they cannot exhibit "a product" in the market place; since service is a matter of customer experience. Earlier client references may fulfill a part need to showcase their ability. However, a need for a more credible body certifying a consultant company stays intact.
Following excerpt from the case study "Managing Growth in a High Technology Venture - the Fact-Tree Way" explains this need.
""Processes" and "Quality Certifications" were the buzz words now. It was not just the Fact-Tree management that felt a strong need to get the organization certified, the prospective customers, especially the European clients, preferred firms that could flash a Quality certification such as ISO." 
The firm discussed in this case study starts with an ISO certification and then suddenly finds itself in the need for an SEI-CMM assessment. The reasons for this as stated in the paper are not necessarily to do a better job, but sustainance in the competition with other companies in the certification race.
The decision of these companies going for ISO, CMM or an Agile model tomorrow is not because of their own convictions and/or internal needs; but would be determined by their competition and what is a "hot" certificate in the market place.
"Meanwhile, Fact-Tree's top competitors were going for SEI-CMM (Software Engineering Institute- Capability Maturity Model) certification and Fact-Tree did not want to stay behind." 
It would be an easy observation for anyone who works closely with Indian IT companies. In such an environment where flashing a certificate becomes the business need, everything else including people focus takes back seat. To start and survive in such market starts with the strategy of how quickly the certification can be achieved.
As Nagaraju puts it in his reply to the case study "What is wrong with the Indian Software Industry?" , this environment creates more value for the people who fall in line with the process and make them grow up in the career as leaders and managers.
"The CMMI does not preclude innovation and change. The process owners are the ones who are the gatekeepers to progress." 
The core skills needed to perform a technical job becomes secondary. These incapable managers and leaders who grew up quickly not because of their technical abilities will find it difficult to work with the programmers working for them. This in turn results in the mistrust between managers and teams.
Quality groups, checklists and audits become the major activities in such organizations.
"The job of the quality department was felt to be policing rather than playing an important role in developing the system." 
The mistrust in the atmosphere results in manufacturing data, last minute documentation and an overall unhealthy atmosphere.
"The perennial problem is that of employees not being too keen on the processes and treating processes as a burden. New entrants still feel that documentation is a hell of work and the tendency for last minute documentation is a common phenomenon."
Agile by definition is a bottom-up approach. Team gets to decide what works for them. There is an added trust and responsibility on the team to retrospect and fix its own course... and most importantly this is not driven from the top or external departments. Trust leads to responsibility that leads to commitment. This contrast of "we control our course" vs "we follow and work under a prescriptive process/model" becomes very significant differentiator.
The very first line in the Agile Manifesto states "Individuals and interactions over processes and tools". This being the major value definition, any and all the flavors of agile keeps this at the top of their priorities.
"Scrum believes that people, their skills and how they are harnessed are the most important factors for the success of a software development effort." 
"XP also emphasizes open workspaces, a similar
"people issue" that is outside CMM's scope."
Once Trust becomes the core of the working model, it results in giving more ownership to the team. The only expectation on the team would be delivering what they are good at, that is working software. "Scrum Team: Responsible for developing functionality. Teams are self-managing, self- organizing, and cross-functional, and they are responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration and managing their own work to do so. Team members are collectively responsible for the success of each iteration and of the project as a whole." 
Agile prescribes delivering in short and frequent intervals.
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" .
There are multiple objectives that get met through this principle. It gives an opportunity to realize the benefits quickly, the trivial one being reduced time to market. It gives frequent retrospections for the team to reflect on their own progress and collectively alter their course for betterment, and gives an opportunity to demonstrate what is being built for the customer and get necessary feedback to align their course to meet customer's expectations.
There is another aspect that is a direct result of these short cycles. The team gets to see the results of their hard work pretty quickly. This results in a team getting the sense of fulfillment at regular and short intervals. This makes a staggering contrast to ambiguous and abstract control charts under the supervision of a quality group that may not understand what the team is building.
Success of a team in an Agile environment rests with team and not with Agile. The same cannot be said in a CMM atmosphere where the success is assumed and accredited to the process.
A major portion of work force today belongs to a generation that is termed as Gen Y. These are the people who are born between 1977 and 2000. They are estimated to be more than 20% and are the fastest growing segment of the work force  . This is the generation that grew up with numerous TV channels, Internet, CDs, DVDs and cell phones. They are highly educated, tech savvy, know how to quickly get help and from anywhere. They like to own their work and control it. They are willing to accept the responsibility for what they own. They would rather take this responsibility than take orders from the top or work in a completely prescribed working model, for whichthey have no time .
Gen Y has grown up educated, informed and formed opinions at a very early age. They have high expectations from their employers. They expect fair and direct managers . They expect the managers to help them grow professionally. They cannot take a controlling manager who doesn't trust them.
Gen Yers want to learn quickly, continuously and from their co-workers. They also want ownership and immediate responsibility. They want to control their fate and are willing to face consequences for their decisions. This makes it impossible for a CMM-like atmosphere to engage them where they get audited periodically for some compliance or other. In contrast, the same trait works perfectly to Agile as they can continuously get feedback for which they are directly responsible and have an opportunity in their own hands to take corrective actions.
The best way for organizations to exploit this high energy generation is to provide such a relatively free and trusted environment. Organizations can set high level goals for Gen Y and demand quick returns. Organizations in fact can relieve themselves from trying to educate this generation on how to achieve the goals. This generation does not need those expensive heavy-weight models to make them work any more.
This makes Agile a ready buy-in with Gen Y. The feeling that they are in control of what they are doing wins their hearts more than anything else.
As Mary Christensen puts it "Corporations trapped in outdated ideologies are struggling to adapt to these free-spirited individuals." Teams that are learning to trust individuals are adapting to a generation that's producing results struggle-free.
 Ana Sofia C. Marçal, Bruno Celso C. de Freitas, Felipe S. Furtado Soares, and Arnaldo D. Belchior1, "Mapping CMMI Project Management Process Areas to SCRUM Practices",
 Srinivas Chillara and Pete Deemer, "Scrum and CMMI: A High level assessment of compatibility"
 Mark C. Paulk, "Extreme Programming from a CMM Perspective", ftp://ftp.sei.cmu.edu/pub/documents/articles/pdf/xp- from-a-cmm-perspective.pdf
 Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, and Sandy Shrum, "CMMI® or Agile: Why Not Embrace Both!", http://www.sei.cmu.edu/pub/documents/08.reports/08tn003.pdf
 David J. Anderson, "Stretching Agile to fit CMMI Level
 CMMI Product Team, "CMMI for Development, Version1.2", Software Engineeering Institue, CarnegieMellon http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html
 Kevin Trethewey, "BLOG: The difference between Agile methods and CMMI"
 James Bach, "The Immaturity of CMM"
 Vasudeva Varma, Vamsi and Kirti Garg, "Managing Growth in a High Technology Venture - the Fact-Tree Way", http://www.canopusconsulting.com/resources/techarticles/facttreecasestudy.pdf
 Nagaraju Pappu, "Response to the Fact-Tree Case Study
- What is wrong with the Indian Software Industry?", http://www.canopusconsulting.com/resources/techarticles/whatiswrongwithindiansoftwareindustry.pdf
 Ajay Batra, "What makes Indian Software Companies Tick? (CMM Practices in India)"
 QAI in the press
 "Agile Manifesto", http://agilemanifesto.org/
 "Agile 12 Principles", http://agilemanifesto.org/principles.html
 Gen Y on Wikipedia, http://en.wikipedia.org/wiki/Generation_Y
 Mary Christensen, "Be a recruiting superstar" AMACOM publishing May 7, 2008
 Carolyn A. Martin Ph.D, and Bruce "Tulgan Managing generation Y" HRD Press
 Cara Spiro "Generation Y in the Workplace"
 Donald E. Knuth "Computer Programming as an art",
1974 ACM Turing Award Lecture http://www.paulgraham.com/knuth.html
About the Author: Akkiraju Bhattiprolu has a masters in computer science and a total 15 years of software industry experience. He's currently working for ADP (Automatic Data Processing) in India as a senior manager. Before returning to India in 2004, he lived and worked in California for 7+ years. He Worked for PeopleSoft USA for 5 years as a development manager in reporting, datawarehousing and buisness intelligence tools. firstname.lastname@example.org
Disclaimer: Views expressed in this article are that of the author and do not necessarily reflect the views of his current or past employers.