For the first week in September, I’d been immersed in an "unconference" located at a remote skiing town in the Rockies, Mt. Crested Butte, Colorado.

The origins of the event date back twenty years to people who were/are students of Jerry Weinberg, so while over the years, participation by consultants of any stripe has been actively solicited, the strong tendency is for the attendance to be dominated by software-centric consultants.

And there I was.

This was my 2nd time attending and for whatever reason, this year was far more valuable to me than my first. To answer the question/statement posed in the title of this entry, what you do is SHUT-UP, LISTEN, and LEARN. OK… so shutting up isn’t my strongest ability… but what I try (and hopefully reasonably succeed) to do is add value by and via what I say when I do speak.

Let’s put it this way… there’s VERY strong evidence to suggest that the term "agile development" was born at the instantiation of this event roughly 10 years ago (pre-dating the Agile Alliance) in a conversation between one of this year’s attendees and a previous attendee, none other than Jim Highsmith, who at that time (so the story goes) was still working on the label, "lightweight" development for the ideas.

Moving right along… One session was on, you guessed it: Agile + CMMI. And, believe it or not, it was *not* my suggestion! Nonetheless, I was asked to attend by the facilitator, and the results were nothing short of a fount of value.

Attending this session were folks whose consulting business were in mostly in either the CMM/CMMI/SEI/Process world as well as those in the agile world. As usual, I crossed both lines, but would put myself in the CMMI crowd if forced to pick one, if only because I don’t actually do any software development.

There were many valuable products of this session’s efforts. Including a very succinct list of primary/fundamental characteristics for the intent of both agile, and CMMI. One list for each. There was also a list of "parting thoughts" that could span any aspect of either CMMI or agile. But, in between, and perhaps the most valuable, was a long list contrasting agile paradigms with CMMI paradigms.

What made this last list most interesting and valuable, is that nothing on the list was based on "perception" or "reputation". Nothing on the list was "fightin’ words". These lists were created by people who believed in their respective ideas while respecting the ideas of the other paradigms. This list is gold. And I got to take it home with me.

And, I’ll post the list here in an upcoming entry.

Side note: I had the opportunity to think, work, and be creative with folks from all sorts of consulting points of view. Would-be competitors helping each other. Growing the pie, rather than worrying about taking bigger slices of it. My mind was expanded easily several times more than my business prospects… amazing what is generated when growth and learning take priority over possible differences.

In other words, exactly the sort of mindset required for bringing CMMI and Agile together.