Why I Like CMMI

I continually work with customers to help them achieve greater success with their software engineering processes.  Generally speaking, I come across a large number of fairly large and successful organizations who rely on technology for their business yet maintain an extremely low success rate with their IT projects.  What makes a project successful?  To some organizations simply finishing a project that they start is considered successful – nothing like keeping that achievement bar right up there.   In my humble opinion a project needs to be on-time, on-budget, and more importantly on-function.  If your projects are on-budget and on-time yet lack the business valued functionality that you planned on providing – are you successful?  My opinion is that you are not. 

There are many different types of companies and thus, many styles of software engineering.  For example, a company that develops off-the-shelf software will likely develop software differently than an insurance company wishing to implement a new claims solution across their offices with their in-house developers.  I could go on and on here as I can classify at least 4 distinctly different types of situations where software is developed, yet one thing I’ve learned over the years is that despite these differences, there is still a great deal of common problems in the way many organizations develop software, and thus, common solutions to those problems.

One of the first things that I do with customers is to try to get them to think outside of the day to day project mindset.  Think about software engineering as it exists across and between projects – take a holistic view of how they develop software and achieve a perspective of what truly drives them.  Very commonly I find that the processes and techniques that surround gathering, analyzing, and representing requirements to be a stumbling block.  This isn’t news to a lot of people and this recognition is a driving force behind many of the agile methodologies which put a great deal of emphasis on the continual interaction with users to ensure that the requirements are correctly communicated.  Generally speaking, I’m a big fan of agile based methodologies; however, I’m also a fan a bit of formality and ceremony.

What does this have to do with CMMI?  Well, I’ve been a silent fan of CMMI for a while, employing much of its patterns and guidance in my consulting practices.  Why silent?  Well, it seemed that every time I would bring up CMMI to other developers or organizations I would get bombarded with comments like “CMMI?  Bla – that’s only for extremely large organizations who want to waste their money” or “CMMI – that will bloat the software construction process and is totally against agile methodologies.”  Additionally, I typically get a great deal of negative feedback from developers because the discipline that CMMI was thought to impose would restrict the intellectual freedom of the developer (I tend to go off on tangents on this topic because discipline and freedom are not opposing forces – the greatest artists (music, art, dance, etc) the world has ever seen got that way through vigor and discipline – yet many developers seem to feel they fit outside of this paradigm). 

Back to CMMI – I like it because its not just best practices –they are also goals.  We have goals in everything else we do – our career, our businesses, our family – why can’t we have goals, and practices that help us achieve those goals, in the way we develop software.  Another reason I like CMMI is because it re-enforces my claim to separate your software engineering practices into perspectives – and to have one of those perspectives span all projects and deal with the ongoing process of improving all areas of your engineering practices.

I’ve always believed that CMMI does nothing to hinder the agile development team.  CMMI is not specific and is enhanced with good management tools (Microsoft Visual Studio Team System stands out here).  CMMI may not be for everyone, but for me it provides a “design pattern”, if you will, of process improvement that can be taken and interpreted for different organizations, depending on their specific needs.  On that note, many organizations do not require CMMI certification – that is having all of their software processes at a particular level (staged).  In fact, I’m a much bigger fan of the continual model where the needs of the project or organization (because they are distinctly different) drive the maturity needs for different areas within CMMI.

It’s my belief that we are going to see a revelation of sorts regarding software engineering – moving from ad hoc disconnected processes to one that is more disciplined (yet agile).  In fact, software engineering can’t even be considered an engineering practice until we see a more professional and disciplined approach to its definition and its construction and maintenance.  I can also see a split in the future between those who are the “engineers” and those who are closer to trade workers – much like most other industries (eg – Electrical Engineers and Electricians, Automotive Engineers and Mechanics, etc) – both perspectives requiring a great deal of training and education but focused in different areas.

Just some random thoughts early on a holiday weekend.