CMMI - The Good things

This is the first chapter in my effort to bat for both sides of CMMI and Agile. Agile and CMMI are two ends of the spectrum and I am trying to study whether if there is at all a point of "marriage". I know there is a lot of reading material on the web on this, so will try to get the maximum out of them as well.


CMMI as a model is very informative and has been built using best practices gained from many organizations. It gives almost an entirety for a  software organization with respect to the process . The point that should be noted is that CMMI is tool or implementation agnostic, giving us the option of interpreting and implementing for our own usage. The following are some points which I observed to be important areas from the model which I am not sure if complete Agile focus would have and otherwise could very easily could go unnoticed. Here I am actually highlighting the intent but not the rigor from the model.

1. The process focus
The model has 5 process areas dedicated for process management. This introduces the need for an organization to maintain a process asset library (PAL), train new recruits on the process and the continuous improvement of the process. I specially like the concept of PAL since it gives a single access place for all process documents, templates, guidelines and exemplary artifacts.

2. Requirement Traceability
The model emphasizes the need to have the ability to trace requirements cutting through the different stages of the lifecycle.

3. Product Integration
In version 1.3 this allows to be mapped to continuous integration, the focus on this and followed by the focus on making sure integration testing can be greatly helpful.

4. Concept of reviews, check lists and Templates
When the above is introduced to the most essential points in the life cycle the quality of the output and the efficiency of producing standard outputs can be greatly improved.

5. Project Management focus
In an organization with the specialized project manager role, the model gives a good guideline for the activities to be performed, including project planning, resource planning, stake holder analysis and risk management

6. Involving the management into the process.
Under the general practices it highlights the need for management reporting and the need for management to monitor people, projects, products and process.

Further to this, there is some welcoming news in the form of CMMI for Development Version 1.3.

The CMMI Version 1.2 which we worked on doesn't have even a mention about agile in the model document, but the version 1.3 tries to "marry" them.

Quoting from the 1.3 Document, "To help those who use Agile methods to interpret CMMI practices in their environments, notes have been added to selected process areas. These notes are added, usually in the introductory notes, to the following process areas in CMMI-DEV: CM, PI, PMC, PP, PPQA, RD, REQM, RSKM, TS, and VER."


read my earlier writing related to CMMI

http://balagowri.blogspot.com/2009/07/tips-for-facing-cmmi-interview.html
http://sayys365.blogspot.com/2011/04/embracing-cmmi-and-organizational.html

Embracing CMMI and Organizational Culture

This blog is almost turning out into a travel blog, so finally I decide to break away from the shell I had got into and finally wrote about something else :D

CMMI as we know is a model for process improvement, its not a process by itself, its a set of guidelines for organisations/units to implement their own process and help the organization to improve performance . From what I have been observing in recent times, organisations who want to adopt this should give greater consideration to decide whether CMMI is the right route for them. Its now becoming a fad and it seems that organizations get drawn to it without much consideration.

A fundamental rule for organisational acquisitions is to actually compare and contrast the core values of the two organizations involved in the merger. When the organizations in a acquisition/merger have contrasting core values the chances of failure is high. It doesn't apply only to organizations, but also to human relationships (specially the more intimate ones) where people who have contrasting core values will find it hard to get on together. Its a proven time tested fact.

In the same way when an organization wants to embrace CMMI model, they should closely scrutinize the assumptions/values on which the CMMI model is based.  As I understand the following can be considered as the core values of CMMI.

1. If commonly held values in the organization are strictly adhered to the chances of the organizational success is more. I would put it as an approach where you have a "cookie cutter" model.
2. Historical success formula is repeatable
3. Projects done are of similar nature
4. Organization is medium to big scale, where enough empathize and resourcing can be given to process improvements.
5. Large proportion of the work is expected to be done in the standardized way.

If an organization wants to embrace CMMI i think they should compare and see whether if they are already there or whether if they want to get there.