Schedule and Events



March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com

Monday, April 23, 2007

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.

3 comments:

Dave Christiansen said...

This post made me think of the law of diminishing returns. I think it applies very strongly to things like process documentation. Most of the value of process documentation comes from a very small portion of the document itself. In the example of CMMI, you can get 90% of the value from your bullet list. Is the other 10% really worth the cost of reading a 600 page document? I would lose my soul trying to read that thing.

Hillel said...

Hi !

Appreciate the plug! :-)

I would be remiss to not help you in your quest to understand the Beast.

First, one must ask the business question: "Do we have a development process we'd like to improve?" If the answer is "yes" then CMMI (for development) *can possibly* help. If the answer is "no" then one ought to also look elsewhere for process improvement guidance.

(See here for a more detailed explanation of the current model.)

ALso, an easy-to-make misunderstanding is that CMMI's value system is "about comprehensive documentation". Sure, that's how *way* too many people have applied the model, but that's actually not the value system. The value system is process improvement, pure and simple.

The appraisal process, on the other hand looks for Objective Evidence of process improvement taking place.  I concede that, again, *way* too many appraisers expect to see documentation and rote regurgitation of the model during interviews as exclusive forms of objective evidence, but there are other forms objective evidence can assume.

One such form of non-document-centric objective evidence that I encourage clients to communicate/demonstrate is the "before" and "e;after" type. It goes something like this:
"You're telling me that you've got a process that addresses this goal? Great! Show me something affected by that process."
At which point my clients will show me some artifact before the process happened and after the process came through. If there was a process, the differences would be the evidence.

Unfortunately, accepting that sort of evidence in an appraisal requires a lot of time, effort, and capability on the part of the lead appraiser and/or appraisal team. The unfortunate part is that such lead appraisers maybe make up about 10% of the entire lead appraiser community.

Last point (this isn't my blog, after all): Matt Heusser's sloppy, cheap version of CMMI 3 in a nutshell should not be attempted without consulting your physician, or in this case, a lead appraiser you trust. These things alone will bring you closer to a desired level rating only by accident. I also believe the original was in reference to the (also original) CMM for software, which really is quite a different animal than CMMI.
Cheers!

Jeff Dalton said...

Matt,

Just noticed your post on the email. Thanks for the plug! Actually, I didn't send the email, I just gave the presentation. Like you, I'm a huge Agile advocate, but I also believe that discipline has a place - even in Agile development. Your commentary on the CMMI misses my point however.

I'm don't "pre-suppose" anything about a company's ability to apply the CMMI usefully. I tell clients all the time that it's not appropriate for them. My good friend Hillel would tell you the same thing. My point is that IF a company desires to apply the model to their organization it's agnostic - it doesn't care about waterfall vs. Agile vs spiral, etc. It can be applied in ANY type of software development environment. As an appraiser I try to work with my clients to develop process solutions that make sense for them - not that are designed to satsify a model.

Of course, if your interpetation of the CMMI is reflected in your numbered list, I can see where one might come to the conclusion that CMMI is not a fit in an agile environment. Unfortunatley, it reflects an basic misunderstanding of the spirit of the model. The CMMI is indeed a complex model - that doesn't mean the implementation need be complex as well though.

TO hear more about how the CMMI and Agile might work together I invite you to view my blog at: http://asktheCMMIAppraiser.blogspot.com.

I'm also speaking at GLSEC - what do you say we sit down and chat? jeff@broadswordsolutions.com