CMMI, the Beginning

July 21, 2007

This posting will introduce CMMI and some basic concepts.  To understand how to bridge Agile and CMMI, I mentioned in an earlier posting that I need to understand CMMI and its core concepts and requirements to a much deeper level than I do now.  This is the first step of that trek.  I will probably repeat this a thousand times, but this is not an endorsement of CMMI so please do not leave comments about the advantages of Agile methods over more rigid models like CMMI.  We will get there, I am for Agile methodologies but like many people need to operate in the world of CMMI from both within my current organization and from external forces.

Disclaimer – much of this information is taken from the Software Engineering Institute (SEI) CMMI website.  I am not claiming to have originally authored major portions of this article, only added in some insight where it made sense. 

The SEI has information about the adoption of CMMI and important points to consider.  When and if you consider adopting CMMi in your organization this is a great place to start.

CMMi was created to address problems such as high costs, late deliveries and frustrated resources that can be led back to lack of or inadequate processes.

CMMI stands for “Capability Maturity Model Integration”. CMMI is a process improvement approach that provides organizations with the essential elements of effective processes.  It’s the integration of several other CMM’s (Capability Maturity Models).

So CMMi is a process model.  Like UML is a language model for describing systems. A process model is a collection of practices that describe what makes up an effective group of processes. 

CMMi is not a process in itself but describes the characteristics of effective processes.

One theme of CMMi is that the quality of the product is largely determined by the quality of the process that is used to develop and maintain it.

The latest version of CMMI version 1.2 was released in August 2006. There are 3 constellations of CMMI in the new version: CMMI Development, CMMI Services and CMMI Acquisition

The CMMI comes with two different representations – staged and continuous. The staged model, which groups process areas into 5 maturity levels, was also used in the ancestor software development CMM, and is the representation used to achieve a “CMMI Level Rating” from a SCAMPI appraisal. The continuous representation, which was used in the older CMM, defines capability levels within each profile. The differences in the representations are solely organizational; the content is equivalent.

(CMMI) contains 22 key process areas indicating the aspects of product development that are to be covered by company processes. The method by which a company chooses to adopt CMMI is called a representation. Both the staged representation and the continuous representation contain all 22 process areas.

The business processes of developing engineered solutions are the focus of CMMI.  This helps understand why it is most widely applied in software and systems engineering organizations.

Without some insight processes and control over their processes a company cannot know how well they’re doing and will be facing surprises.  And if/when they wait until the end of a project to see review how close they came to targets it will be difficult to improve.

CMMI should be adapted to each individual company; therefore companies are not “certified.” A company is appraised at a certain level of CMMI.

So in summary CMMi is a method in which organizations can measure their product development or service processes against industry practice.

It describes best practices to tell you what to do but doesn’t dictate the how or who.  It also lays worth on evolutionary improvement from immature to mature processes in a company.

Oh yeah,  definitely check this out…   A CMMi FAQ. 

Agile and CMMi

July 15, 2007

Disclaimer: this blog post won’t answer any major questions.  It is going to raise more questions than answer them and it will leave us hanging at the end.  So with that intriguing lead… here we go.

Last Friday I attended a presentation by Scott Ambler titled Agile at the Enterprise Level.  Having read many articles from Scott I was naturally excited to hear him speak in person.  Especially interesting was the title where I thought there would be a lot of insight into implementing Agile practices in the real world with real world constraints.  Some of these constraints include mainly CMMi and client requirements along with client expectations.

I had listened to Scott’s presentations in podcasts before (one of them can be found here) and I believe even saw a video of one his talks.  So I knew he was pretty much a no holds barred type of agile advocate.  He gave the same warnings at the beginning that I had heard before so knew we were in for a good talk.  He is a straight talker (good!), uses facts to back up his arguments and is enthusiastic and really believes in what he is saying. 

A quick overview of the discussion involved introducing agile, the main principles.

·        Individual and interactions OVER processes and tools

·        Working software OVER comprehensive upfront documentation

·        Customer collaboration OVER contract negotiation

·        Responding to change OVER following a plan

Scott addressed any fallacies of Agile such as Agile projects do not document and do not plan.  He also presented many statistics and metrics, mostly from this survey  done in Doctor Dobb’s.

I did learn some new concepts and gained a deeper understanding of other areas, but what I was looking for was not directly answered to my satisfaction.  I believe in the world we operate in many people struggle to reconcile the two worlds of CMMi and Agile practices. This was evident as it was brought up multiple times in the Q & A session at the end.  Also, I know I was not alone that I went away still somewhat confused. I spoke to two other attendees and they had the same issue.  I don’t think anyone has any issues with Agile practices of test driven development (TDD), prevent creating unneeded documentation, deliver working software as a priority, involve the client on a regular basis, etc.   But in our day jobs we live under constraints that seem to make becoming a real agile shop a pipe dream. 

Like most development groups we have done parts of Agile.  We are almost doing TDD across the board, we occasionally have our people do some pair programming and we are lucky in that we have an engaged client which interacts with our developers almost daily (in a good way). But I would not consider us an agile group.  We spend a lot of time producing MS Project Plans, we create fairly large requirements documents up front and we are not delivering working software in small intervals.  Portions of this are cultural issues that can be worked on over time.  We are incrementally changing our efforts.  But, other parts are required because we are told they are CMMi requirements and working for the government and being CMMi compliant there is nothing we can do.  How to bridge the two and live in both worlds is the question?  At least in this neck of the woods, ignoring CMMi requirements is not an option. Scott repeated many times that of the 3 world’s worst SW development groups the U.S. DOD is # 1 and the rest of the U.S. government is #3.   (Thanks to the U.K. MOD for breaking up our super track history).  However, many of us pay our mortgages and our car loans based on working for one or both of these entities.  So, again ignoring it is not something I (or my bank manager I assume) is willing to do.

A quick search on Google brought back one specific site that addresses just this issue. The site, from a company called Entinex covers some of the issues but also leaves us with some unanswered questions.   This is useful but after contemplating it further and reading the information on this site I realized I need to do some homework.  Why?  I imagine I am not alone in this.  Although I know a little about CMMi, I really don’t understand it to the level I would need to understand it to tackle this type of issue.

– I need to understand exactly what CMMi requires and what is being assumed to be required?

– What does it mean to be CMMi Level 3 and maintain compliancy?

– What does the government require when they issue RFP’s and state that you must meet CMMi requirements?

After answering these questions I can move on to the next level and see if the two can be bridged.   Hopefully you will see more here….

Finally thanks to Command Information for organizing the Scott Ambler presentation I mentioned in the beginning of the blog.  Although I came away with quite a few questions, I learned a lot,  the organization was top notch and Scott is a great presenter.