It's official... (and a little value for your time)

Entirely for legal, insurance (read:liability) reasons, I've established a direct Partner relationship between Entinex and the SEI.

It means I can put this on stuff I do:


It's true that being directly listed in the SEI's Partner directory will have some marketing benefit since people look there for CMMI resources, but the truth is I get plenty of inquiries from other stuff I do.

It will be interesting to see if/how being listed as a Partner changes anything.

So... about Agile+CMMI.

Here's something to think about:

Many of us are impressed when we see the "before" and "after" photos of someone who got into shape. Whether they lost weight and got thin and buff or they pumped serious iron and got big and buff, we're equally impressed. The more the transformation the more impressive. Usually.

We're often reminded or compelled to ask how much time elapsed in between the "before" and "after" and more easily driven to ask "how" the person did it.

Since we're so easily impressed by these photos, and, we so readily accept that a process took place in order for the person to get from "before" to "after", why do people (read: many developers and appraisers) have such a difficult time recognizing that if we do a "before" and "after" of development products, that what happened in-between was a p r o c e s s ?

Is there anything wrong with that sort of evidence? Could the before and after of an affected work item/product collectively be a sufficient artifact?

The answers are: NO. There's NOTHING wrong with that. And, YES, that can be adequate evidence.

The question, then, is whether what caused the before and the after was on purpose, whether it can be defined, or managed, expected, or even predicted. That would make it evidence of process improvement. Not just that it "happened". That a process happened is just a process. That the process happened on purpose, and the extent to which it is defined, or managed, expected, or even predicted, makes it contribute to process improvement.

Brought to you by the letter J

"CMMI is full of big scary words."

A rather simple yet poignant comment by my dear wife, Jeanne, who was responding to a discussion we were having about my Hedgehog Concept.

It so happened that I had just returned from a meeting with a client at which I diffused a contentious exchange over the matter of Configuration Audits. 

For an example of why there's confusion, and why there's contention, visit the above link.  The answer provided to the question comes straight from the CMMI model text.  By contrast here's my explanation of what CM SP 3.2 expects:

In plain-talk, CM SG 1 would have us figuring out what we want to control the configurations of and a way to finger a given configuration of one of those controlled things at various points in time (or space).  SG 2 has us making sure that the things we want controlled only change when we want them to change and that we know what those changes are.

With all this emphasis and energy directed at things changing under a watchful eye, what SG 3 is saying with SP 3.2 is simply this: you don't want anything slipping through, so make sure SG 1 and SG 2 are working, OK?

Wasn't that so much easier?

Most companies worthy of their products are probably doing something to that effect anyway; CMMI is pointing out that it's probably a good idea to now be doing it regularly and on purpose.  After all, in development, a really bad day is when the customer calls and complains that the supposed "update" you sent to the product actually took out some nifty features they kinda liked when you sent them the previous update.

This episode of the AgileCMMI blog has been brought to you by the letter J and the number 3.2.

SEPG 2007 Report

SEPG has come and gone. This year held in hip, happenin' Austin, TX. Though, the weather only cooperated for maybe 1 of the 4 days, not including the Sunday on which I arrived.

Attendance was a few hundred lower than last year, but there are a number of possible explanations for this (purely conjecture on my part):

- The event was about a week later in the month than usual;

- The SEI hired an outside company to market, promote and handle much of the registration activities. By and large they did a decent job. However, one very noticeable difference was the increase in prices for everything from attending to showing at the exhibition area. Unless my memory fails me, as a speaker I don't recall having to pay for attending last year at all. This year I did pay for all days but the one day of my presentation. If there's one thing I can over-generalize about with little impunity it's that the process improvement set are not the sort who part easily with their cash.

Regardless of the net number of attendees, there was no shortage of content. As for those subjects that interest me the most (and maybe you), I am happy to report that the volume of presentations dedicated to Small Settings and Agile has blossomed to require that these two tracks be separated into their own individual sections.

It was nice to see the two topics not be inseparable and to see/hear so much content that wasn't necessarily assuming that all small settings use agile or vise-versa.
The proceedings (or some part thereof) will be available eventually from the SEI's web site.

It was also nice to see and catch up with David Anderson whose SEPG trip report can be found here. (Terrible pic of me, by the way.)

David introduced me to Clementino Mendonca who expressed an interest in speaking with me some more about my experience with clients implementing MSF for CMMI Process Improvement and my "AgileCMMI" process architecture that might be able to be wrapped around it.

It is somehow fitting that the person coincidentally in the photo with Clementino (should you wander over to David's blog) is a newer client of mine -- showing keen interest in MSF.

Back on the subject of Agile + CMMI... Paul Nielsen, SEI's CEO very clearly stated to me the desire for SEI to publish some sort of official "position statement" on where they stand with respect to agile methods. In particular, stating that the SEI is not opposed to agile methods nor do they advocate any sort of disparagement of agile or any expectation that agile methods be assumed incompatible with CMMI. (Or something to that extent.)

Mixed in with this discussion was a side comment by Dr. Nielsen to the effect of why the SEI has such a reputation -- to which I immediately pointed out that the SEI's marketing ability is far less powerful than the combined power of all those who walk the earth in their name. Specifically, all the appraisers and instructors. Most of whom (~90% ?) wouldn't know agile if they saw it and if they did, wouldn't know how to implement or appraise CMMI in an agile environment.

I'm really surprised I haven't blogged (read: ranted) about that sooner... Maybe I have already in my FAQ. It's gotta be somewhere.