Actual E-Mail - II

I've been carefully re-reading that email, and it is not as bad as I initially thought. Actually, it makes very few over-the-top promises. Only one sentence really sticks out at me:


The CMMI is appropriate for organizations off all sizes whether Agile or Waterfall, engineering or IT, embedded or workstation, internal or external

This pre-supposes that all companies can always benefit from a single, universal model for process improvement. This means that dotCom companies, military defense contractors, Pepsi, Apple, and medical equipment manufacturers should all be climbing the same ladder.

And, to quote Renee Bullock, I reply:

Bull Pucky.

The CMMI is a model. Like every other model, it is imperfect. In fact, the CMMI is just a big list of best practices made up of a bunch of smart guys. Here is Matt Heusser's sloppy, cheap version of CMMI 3 in a nutshell:

1) You should have a defined way of doing everything. And actually do it that way.

2) You should know what you are building before you build it. (Requirements)

3) And, since the requirements will change, have a defined way to accept change.

4) You need to have a reason for believing how long things will take before you do
them. One term for this is 'planning' -> as in, all projects should have a plan.

5) The intermediate thingees in software development - plans, designs, tests, whatever - these are work products. Everyone needs to have artifacts to show that the work was actually done.

6) All these artifacts need to be placed under Configuration Management. (This is basically version control that should be able to recall the complete work product set at a given point in time, plus some labels.)

7) Every work product needs to be reviewed and/or audited, both by technical people (peers) and by management

8) You should have a change process for your processes, that is defined, placed under version control, reviewed, and so on.

9) Metrics are good. (At the higher levels, metrics are great. At the highest levels, and we thank them for our food.)


-------> I think that's most of the philosophy behind the CMMI. Now, a good CMMI-er will point out that these things are not required; for the CMMI, you just have to point out that the GOALS for each key process area are covered. For example, level 3 requires outsource management - you could just tell the assessor "We don't outsource development, so we don't need policies to manage outsourced projects."

Or, in theory, with some of the more wild work product requirements of the CMMI, you could go back to the goals and say "We don't have the problems that this key process area is designed to address."

So yes, there are Assessor's like Hillel that will work with your team to do figure out what you really need - but that's despite of theCMMI, not because of it.

The CMMI instills a value system, and it's about comprehensive documentation. If you think I'm kidding, download it and print it out. (And that's just the MODEL; try reading the SCAMPI appraiser's manual some time.)

The Agile Manifesto has a value system, that is about working software.

Putting the two together is possible; you can ask questions like "What is the minimum about of documentation I can give to satisfy the CMMI requirements? What is just enough process, just enough documentation, just enough auditing and compliance work?"

Insisting that all companies could benefit from CMMI? From a collection of best practices made by a bunch of humans with no real statstical evidence?

Now I'm going to Quote my roomate Mike from Salisbury University:

"Whatever, Dude"

POST-SCRIPT: The CMMI doc is something like 600 pages long. My assertion is that a organization that follows my sloppy, nine-point list above could probably be rated level three. If not, it would only take a half-dozen more bullet points, at most. The _REASON_ the CMMI is 600 pages long is not because it's inherently complex - it is, actually, surprisingly naive. It's about the value system inherent in the docs.

You can call that agile, er, I guess.

Whatever, Dude.