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. 


Phil Hack has listed 19 Eponymous Laws of Software Development.  Notice number three…

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.

Chaos Report Background

July 12, 2007

After my last post discussing the Standish Group someone brought to my attention an interview done by Deborah Hartman, an Editor at InfoQ, with Jim Johnson from the Standish Group. In the interview he explains the history of the research, the method and the role of Agile.  Read it here.  An interesting read considering the press the report gets everywhere.

Making A Difference

July 12, 2007

I started this blog a few days ago.  I mentioned Zoho 2 days ago.  I had a comment from Raju at Zoho yesterday thanking me for using it and hoping I like it.  I mentioned the other blog where I told you he talked about how he was impressed how they keep an eye on the blogosphere and when Zoho is mentioned.  This makes a difference and drives me to want to use it more.  Simply Amazing!

We’re Making Headway

July 12, 2007

The textbook I have been using in the course the last 4 semesters, Information Technology Project Management, 4th Edition, Kathy Schwalbe, uses excerpts from the Standish Groups 2003 Chaos Report. Some of the data sited are cost overruns at a rate of 43%, which, while still quite large, are a marked improved from 189% (yes, you read one-eight-nine) in 1994. The dollar amount of IT projects in 2002 was $55 billion, which includes canceled projects overruns, compared to $140 billion in 1994.

If you look at the history of how successful projects are there is a dramatic improvement between 1994 and 1998 and then a slight improvement since then. I could never really put my finger on why this period caused such a dramatic improvement.

I always ask the students what they believe the reason for the improvement is between the mid 90’s and a few years ago. The following is a short list of what we usually come up with:

· Improved project management techniques

· Improved estimating and controlling techniques

· Shorter projects (not biting off too much at one time)

· Better developer methodologies

While a case can be made for all of these, it never really made me feel as if we had really come up with the reason for the improvement.

Well, maybe this is it. If you read here you will find one theory from the Founder and Chairman of the Standish Group, Jim Johnson. The dawn of the Internet and the type of development browser based systems were the catalyst for such a dramatic improvement. Need to think about this some, but you know… it makes sense.

In the coming semester I plan on using Zoho as a teaching aid for the students.  It is free for 1 project and being web based we can collaborate.  I discussed this type of tools in my other blog (which still overlaps in some ways with this blog but will eventually become solely a SW development blog) some tools and did a non comparison evaluation.

Here is an blog post to Zoho and where it is mentioned on how they keep a close eye on the blogosphere.  I can attest to that, they commented on my other blog thanking me!

 So, I will be getting back into the product and discussing it on and off in the blog here.  My earlier posts was a 3 part series (the 2nd looked at Basecamp which is an awesome product too) where I introduced the subject of Web based project management tools here and took a deeper look at Zoho Projects here.

Sweet Smell Of Success

July 10, 2007

Everyone has a different definition of what success means and most people have set goals in their own life on when they would say they have neared or achieved success. One question I will ask at some point in every class is

“How do you think you can define a project as success?”
(followed by some feigned look of contemplation)

“When the client pays!”
(followed by some slight looks of amusement from a small minority)

But, when is a project a success? I was reminded what a moving target project success can be when reading this blog entry. One definition is it is a success when a project meets time, cost and scope expectations (triple constraint) set out in the project definition phase. Another can be when the customer signs a project acceptance form signifying the project has met requirements. Another could be when the project has passed a rigorous form of QA and user testing and is running in its production environment.

I have had developers tell me that they worked on projects that were considered a success by their companies or the client but not by them. They didn’t implement the database interface the way they wanted or the user interface could have been implemented with the newest widget to make it look better. The answer to this is; get over it. You delivered software to a client who is happy. He paid for it, you didn’t. His opinion matter more than yours. Besides, the reasons you state the project were not a success have no effect on the world’s view of the projects successfulness. So, the project was a success.

However, being somewhat of a nebulous term and allowing considerable lee way in its definition I think there is not a definite answer. The answer lays in the fact the user and the developer must be on the same page, in almost every step of the project, on what success is and their definitions must be the same or very similar. The exact definition will change, become more refined, and each party must understand and be in agreement with the changes.

This is why I believe agile development really does help in achieving project success. Agile allows the team and client to experience small portions of success on the long road to the ultimate success. It is like passing mile markers on a long road trip.  In Agile we can correct when we stray from the path that leads to achieving that success before it is too late. And finally the user is involved constant providing guidance and feedback on leading to that final goal. Here is another blog post that does well in formulating some of these points.

So success is when the development team, stakeholders and the eventual users worked together to develop a product that met the criteria they worked on together to develop.

Of course if it is on time and within budget it will be a really big success….


July 8, 2007

Where did this name come from…

The Pareto principle or better known as the 80-20 rule states that 80% of the effects come from 20% of the causes. I have often stated in my IT Project Management class that I not only think this is incredibly important for project managers, but equally important as a rule in everyday life.

Since I plan on using this blog as a teaching aid (exactly how I am not sure) and knowledge base for the class it was fitting to name it after this rule. I have made countless students suffer through repeated attempts to convey how important I believe this rule is and how useful it can be to making us more effective project managers. So named this blog after the principle. By the way, “Pareto” is used so we got the long version.

Because I spend my entire day as a Java developer the blog will slip into the world of Java and Java projects.  But for the real Java stuff from me look here.