CMMI Crash Course™

I've been delivering this class I've been calling the CMMI Crash Course™ (What the SEI won't teach you) for several years.

For reasons I've as yet not taken the time to figure out, I'd never advertised it, never had a web page on Entinex.com for it, and only really made it public at the NDIA CMMI conference last year.

Well, my Chief Executive Genie (responsible for marketing research and homeland operations... a.k.a. my wife Jeanne), pointed out that not hello.World'ing the course was a great disservice to the industry.

She pointed out that if part of the Entinex corporate mission (and my personal quest) was to better educate folks about CMMI, and that this education was necessary to help more organizations understand how to adopt CMMI, and that all this was just prerequisites for eliminating the gap (perceived or real) between CMMI and Agile... well... people should know about it!

Until now, other than presenting at the aforementioned conference, my only deliveries of the Crash Course™ have been to prospects and clients.

SO...

Now you know. I've got this Crash Course thing I do. It's pretty decent. Teaches a whole bunch of stuff in a short time (4 hours). Conservatively, it could otherwise take over US$30k, about 4 weeks time over several years to gain what I've condensed into half a day of not-so-boring stuff.

I've had SEI folks sit in and they loved it. See... even though I say "What the SEI Won't Teach You" it's not that they don't, really... it's that they just do it in a very specific way that... well... doesn't connect with lots of people on the things they care about. That's just what happens when you've got a VERY large audience to satisfy. It's also symptomatic of having to toe a very fine but deep line on what they can/can't say.

Really... of course the SEI teaches this stuff... how else would I get it? (OK, unfair question... I'm a CMMI geek... I'd probably get it some way.)

Regardless... the AgileCMMI point to this is simply that training really does need to account for the needs of the participants, must be relevant to their projects and processes and must be timely so as to make a positive difference in decision-making. All-too-often I encounter perfunctory "process" training that has a worse effect than being bad. It foments cynicism and dissent for process improvement where the organization's only goal is painfully clear: prove you had training or the appraisal won't look good.

More people should know the content of the Crash Course™. It would make their CMMI (and probably Agile) lives easier.

If interested, I'll send you last-year's slides. (This year's are way better.)
[Yes, that was a shameless plug.]
I hope to be presenting this year's version at the NDIA conference again.
If you visit Entinex.com, you'll also read about my Crash Course™ plans for 2008.

Hey.... Thanks for noticing.

This entry is just a public thank you shout-out to the folks at Computer Aid, Inc. "The World Leader in IT Process and Productivity", for bothering themselves to notice this blog in their recent IT Metrics and Productivity Journal issue.

I and everyone working to close the gap between CMMI and Agile appreciate your contribution to spreading the word.

Planning Poker cards are here!

We created and produced decks of planning poker cards.

Right now, we're not set-up to sell them yet, so... if you ask nicely, we'll send you a deck.

More info here.

(The card on the right is the "I need a break!" card.
the backs of the cards have our AgileCMMI logo and *this* site's URL.)

Expand the scope of "value".

I get common resistance from agile proponents that part of the agile philosophy is to only perform activities that add value to the product, and thereby (the assumption is) to the client. This is often a stumbling block for the "lean" folks too.

The argument goes along the lines of: much of the CMMI practices to "maintain" and even many of the practices to "establish" certain work items don't add value. If not, why do them?

It's a strong case. But strong cases for not doing practices don't make for organizations that can get through a SCAMPI (CMMI appraisal) and end with a maturity level rating.^*

So what is there for an organization to do?

There are two ways (non-exhaustive and not mutually exclusive) to re-factor this thinking, both of which involve adding long-term value in addition to immediate value:

1) Adding value to the organization, and
2) Adding value to the future product (or, to the product in the future).

In the first approach, process activities are seen as adding value beyond the immediate project. Process activities are seen as an investment in the efficiency and productivity of future projects. And, on sufficiently long projects, these activities can provide feedback in time to make a difference to the projects underway and from which the process data is being collected. This approach adds value to the business in terms of know-how, intellectual property and competitive edge.

The second approach, while similar to the first is product-focused. In this view, the value in doing the process activities is in being able to reduce maintenance costs, make updates/upgrades less cumbersome or expensive and make the product more extensible. This often goes handily with allowing the developer to be different from the operator, the maintainer, or the help desk.

Many paradigms of process improvement use the metaphor of "throwing the product over the wall" as a means to describe what happens when products are developed in a serial, production-line fashion and not as an integrated, high-trust, highly communicative team (sound familiar?). The very antithesis of agile development.

Well, here's a wake-up call for some people, including self-proclaimed agile developers: the "wall" eliminated by integrated and agile development teams is not only between steps in the development life cycle. Sometimes the wall that needs eliminating is temporal. That is, stop throwing your well-tested, peer-reviewed, non-wasteful code over the wall for someone in the future to have to deal with. Most of us have had to make sense of someone else's spaghetti code at one point or another and we shouldn't be the ones to create it even if we did so by being lean and agile today while sacrificing the value of the product in the future.

So, the value we're trying to eek out of our process activities ought to take this sort of long-term view of "value" Some also refer to this as "Total Cost of Ownership" or TCO. Process activities ought to be calculated on the basis of TCO for the organization and the product.

In both approaches, the value being added to the organization as well as to the product is a reduction in waste. Companies don't become lean over night and they don't become great at agile practices with 2 days of stand-up meetings or one 30 day sprint. Often taking the time to identify, record, be methodical about, and update the organization's approaches can help find what works and eliminate what doesn't.

Really.... CMMI isn't what complicates this, it's not understanding CMMI that owns that job.

^* Let's be clear about something... Achieving a maturity level (or capability level) rating should not be any organization's goal. Improvement should be. PLENTY of benefit, value and improvement can be had without *ever* being appraised and/or without ever attaining a "level" rating. However, for obvious reasons, achieving ratings has other value, such as being able to compete for certain customers and in certain markets.