Posted by agilecmmi on Apr 4, 2010 in Blame, CMMI in a box, Culture, LCPBC, Level-Chasing, Pathological Box-Checkers, Perf, Performance, TQM, lean, value | 4 comments
Stop blaming CMMI for bad processes. Stop blaming CMMI for not getting real value from performance improvement efforts. Used correctly, CMMI fixes processes, doesn’t make bad processes. Bad processes are a symptom of using CMMI incorrectly and blaming CMMI is to run away from the true issues. The true issues are that the organization/company doesn’t have a culture to support high performance results long before anyone thought to use CMMI.
This is most typical of level-chasing pathological box-checkers who want ratings at any expense to effectiveness, morale or efficiency.
You can always tell these types of organizations from those who truly want to improve. Level-chasing pathological box-checkers (LCPBCs) don’t know what their own processes are, and when they start to look they don’t like what they see but refuse to do anything progressive about their ineffective, inefficient, and otherwise broken processes. LCPBCs often rule by fear in one form or another; they don’t practice TQM, don’t employ Lean principles, don’t value when people challenge the status quo, don’t value the expertise of people not in powerful positions, and don’t empower their people to make decisions or to take responsibility for the entirety of the health and well-being of the organization. LCPBCs are also easily picked out of a crowd by their belief that you can improve performance without changing anything difficult and by limiting whatever changes might happen to the technical staff alone. You’ll often find them hunting for “CMMI in a box” (or even “agile in a box”) and they’re looking to do it cheap, fast, and start “right now!”.
True, that some executives are LCPBCs because they don’t know any better, but there’s hope for those executives who are interested in making informed decisions. Others are doomed to low returns and continued recurring process (and appraisal) costs. Slapping CMMI on top of such a discordant, caustic, corroded, and sick culture will only make things worse. And, blaming CMMI for failures to produce advertised outcomes, or for costing time and money and adding no value is just another symptom of the problems that existed in such organizations before CMMI was ever introduced.
Blaming CMMI is just the latest cop-out excuse in what’s likely a long list of excuses for the organization’s failures to materialize success –
It’s not CMMI … it’s immature, unreliable, culturally caustic organizations being exposed by the dust the CMMI stirs up.
Next time: How to not be a LCPBC: Making the marriage of CMMI and Agile a no-brainer.
Copyright Agile CMMI Blog
CMMI, and SCAMPI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
WordPress Theme by: Wood Street, Inc.
Facebook Twitter
I agree with what you said. CMMI has never restricted the use of certain practices.
Also, LCPBC can obtain the level without making the accomplishment. I think this applies to other best-practices (e.g. ISO).
Another point, how the process improvement is managed (OPF, OPD) in my view is critical to gaining results rather than certificates.
Hi, I really look forward to the next post! I have always wondered how an Agile approach to CMMI would look like. Getting Agile is difficult. Getting above CMMI Level 2 the same. Marrying the two must be an extremely challenging journey!
I have used CMMI a lot, and I have always regarded CMMI to represent “the right side” of the agile manifesto. There is nothing in CMMI that encourage you to “do as little planning and analysis as possible” or have self-managed, self-organised feature teams. On the other hand, there should be nothing stopping you from doing this either.
I think the main problem is that most organisations out there is LCPBCs. I can not see how these guys will make it..
[...] bid on work they currently can’t bid on, but that’s a problem addressed in two separate posts (here and here) from a while [...]
[...] organization was using CMMI incorrectly. A topic I cover at least in the following posts: here and [...]