I wrote harsh words about the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) (The connection between leadership and process in IT Keep the Joint Running 1/14/2008).
Nobody wrote to disagree. Not exactly. Hillel Glazer, an SEI insider, politely informed me that I was hopelessly out of date: SEI abandoned CMM in 2001 in favor of Capability Maturity Model Integration (CMMI). He agreed to an interview to explain the situation. Mike Konrad, one of CMMI's authors, reviewed Hillel's answers and wrote me independently to endorse them.
Bob: SEI describes CMMI as a general-purpose process framework that can be used to create just about any sort of business process -- not just software methodologies. Do we need yet another process methodology, given that we already have: Lean, Six Sigma, Lean Six Sigma, Theory of Constraints, and Reengineering?
Hillel: To be more precise, "CMMI-DEV" is not for creating business processes or for creating (developing) products, but for improving the business processes of product and service development. CMMI assumes a given organization already has business processes and desires to improve them. What happens all too often is organizations are compelled to use CMMI but start out not having/knowing their processes and so CMMI becomes both how they define their processes as well as how they improve them. It's a fundamental -- and widely held -- misunderstanding of CMMI.
Bob: In his 2005 interview, Capers Jones was openly dismissive of Agile and similar adaptive, iterative methodologies. With CMMI, has SEI softened its stance?
Hillel: Capers Jones is not a reviewer or contributor to CMMI, and I wouldn't say SEI folks and Capers Jones see eye to eye on many things.
When CMMI was being written, reviewers were criticizing SEI for making it so "waterfall" centric. The authors were genuinely dumbfounded as to what it is in the model that gave that "anti-iteration" connotation. CMMI is 100% agnostic as to the product development life cycle an organization chooses to use, and always has been. Also, the SEI has created a team-oriented development method called "Team Software Process" (TSP) which has been demonstrated as being very agile-oriented.
Bob: Does any of this really matter to bread-and-butter IT shops? Most companies don't develop -- they integrate and configure purchased applications. The packaged methodologies, waterfall or iterative, weren't designed for this world. Does CMMI offer something useful for it, or is it also intended for new development?
Hillel: Right now, ITIL probably provides more value than CMMI to pure-play IT shops. However, stay tuned, there's another CMMI in the works for "services" organizations that goes beyond a static library of management and service workflows and offers a continuous improvement mechanism to companies providing services -- IT or otherwise.
Bob: I've recommended culture change as the first step in implementing a more process-driven approach in any organization -- to create a "culture of process" -- and to make sure process owners are fully educated in process management. Do you agree? If not, how do you recommend starting down the CMMI path?
Hillel: I completely agree. When working with companies that do need a culture shift, the first thing I get them to internalize are the CMMI's "generic practices" which provide the process acculturation so many organizations lack.
In many cases, no matter how much power they've been given, you can't start with the CIO, you must start with the CEO. The CEO needs to see the business value of being process-oriented. Otherwise, the CIO will be placed in an untenable position at the business level.
Bob: Anything else?
Hillel: What's most often misunderstood about this is that "CMMI is a model, not a standard." CMMI contains no processes or procedures of its own, and is not a thing that can be complied with. It's a fundamental shift in expectation and experience of most CMMI users -- who are used to complying with standards. Wrapping one's head around and being able to apply a model takes a whole different set of aptitudes than complying with a standard.
We hear "just tell me what to do" all the time. Combine that with the impatience (read: short attention span) and lack of process culture among too many executives -- a topic you regularly rail against -- and you have a recipe for process disaster.
Bob: Last question: Do you agree Keep the Joint Running is the most insightful commentary in the IT industry? Or would you rather have me twist your responses in creative ways that make you appear to be the biggest schlemiel in the trade?
Hillel: LOL!
Bob: Don't say I didn't warn you ...
-----------------
Copyright and other stuff -- The great KJR link point
No comments:
Post a Comment