The goals they have are good ones. If you're stuck with more than 10 programmers of varying levels of ability, and you're taking marching orders from a client who has no idea what the tradeoffs are, they're arguably the best way to get things done.
When you're a group of fewer than 5 programmers and you're all smarter than the average bear, they're useless.
In essence, they're a ritualization of the communication and testing process that has to happen to make software good and reliable. Without some communication and testing, the software will suck; at a certain organizational size, or with programmers of lower ability levels, you can't rely on the programmers to do it themselves.
But in the end, to build software you have to communicate. Once the group working on the software is larger than 5 or 6, unless everyone on the team is phenomenally good, you need to formalize this communication somehow. All of these formal development methodologies are ways of accomplishing that -- none of them are necessarily good, but at least they solve that problem so you can get to other problems.
Of course, this leads to other problems, such as the ISO 9001 compliant company that has all of its dysfunctional processes documented in explicit detail that must be followed. (I worked there once. It was like Office Space meets Brazil.)
I deal with CMM on a daily basis (gov. contracting). It is a huge waste of time, money, and resources. If people spent less time writing documents and more time writing software, the world would be a better place.
As for me, I don't like it. I abide by it at work and it's generally a huge bottleneck for all projects. Many of the ideas the SEI proposes are good practice, and I have a feeling a lot of developers already follow them without knowing that they're part of any "process".
A bad implementation of CMMI at an organization only makes things worse. For example, the latest version of CMMI encourages us to engage in rapid feedback cycles with customers, which is great. But the system we're supposed to track when and how we did that is clunky and consumes time, to the point that you don't want to go talk to customers for fear of having to do more writing and documenation.
These models were "invented" for non-technical types like MBA monkeys to help them feel like they are in control of software engineering process. If you look at these models closely, you realize they resemble various principles employed by mechanical/civil engineering.
So what we have here is the attempt by non-technical managers, to bring some "feel" of control over something inherently complex (software development), modeled by their semi-successful methods of management employed in traditional industries (read companies like GE).
What those guys fail to realize is that software engineering is fundamentally more complex and, therefore, unpredictable than manufacturing industry they're used to (from their business school books).
I think the keys to CMM are perfectly valid. However I don't think there's a direct correlation between CMM level and the success of the company. You can say that by looking at the companies with a high CMM level that there is a relation, but I could argue as to whether that it is the cause or the effect.
It sucks all the fun out of writing software. An awful methodology. I left the company that used it after only 3 months (would have been sooner if I found another job sooner).
not in most startups... I don't see anyone here getting into defence contracting any time soon.
Granted, there are some common sense aspects that are slam dunks (c'mon, version control, why wouldn't you use it) but a lot of it still favours serious software where all the engineers wear dark suits and ties and do big design up front.
Most startups would run out of time and money just getting to level 2 CMMi compliance before they even started to really cut any code.
When you're a group of fewer than 5 programmers and you're all smarter than the average bear, they're useless.
In essence, they're a ritualization of the communication and testing process that has to happen to make software good and reliable. Without some communication and testing, the software will suck; at a certain organizational size, or with programmers of lower ability levels, you can't rely on the programmers to do it themselves.