If you're using CMMI as a religion, you're using CMMI wrong.
If CMMI is causing you more problems than it's worth, you're using CMMI wrong.
If ALL of your projects are generating a huge paper trail, you're using CMMI wrong. (Choose better "focus projects" for your appraisal.)
If CMMI is stifling innovation, you're using CMMI wrong.
If CMMI makes you focus on principles developed elsewhere instead of your business objectives, you're using CMMI wrong.
If CMMI isn't helping you improve your product quality, you're using CMMI wrong.
If CMMI isn't helping you, you're using CMMI wrong.
But that comes as no surprise. Most companies seem to be using CMMI wrong.
CMMI is a tool. If you hold it right, if you swing it right, if you have enthusiastic people skilled in using it, the tool can give you good results.
If you inflict the tool on reluctant people who don't have any experience in using it, you will likely get really bad results.
You should only use CMMI if you're serious about improving your software engineering processes. Don't blindly chase arbitrary numbers or timetables. Use it in ways that help you and don't use it in ways that harm you.
CMMI prompts you to think about which of your projects should use best practices from industry, like using requirements tools and bidirectional requirements traceability. You should use some of these practices on some projects, and you should avoid their use on other projects.