More on Models

EE GADS!

It's been over a month since my last post. In fact, possibly the longest stretch ever in the life of this blog. Sorry about that! Where *does* the time go?

Well... I hope everyone's been busy and successful with their time!

So... In a recent presentation, I displayed several pictures of models: a model airplane in a wind-tunnel, a model of an entire airport terminal, a model of an office building, the cover of a fitness magazine with a buff pretty-boy pictured, and last, but not least, a computer-rendered model, of a LEGO® model of the NCC-1701B, "USS Enterprise" -- which so far, NOT ONE PERSON seeing the picture didn't recognize as (at least) the "USS Enterprise" of Star Trek fame.

There on the screen were five models. They all share one very basic characteristic:
not one of them is real in any way. Not even the photo of the fitness model. At the very least it's a picture, not a real person. Yet, in every case, each model could be used to do any number of things such as learn by example, take relative measurements, try and communicate ideas, and also, put pictures in our minds.

The importance of understanding the concept of a "model" is critical to understanding and effectively implementing process improvement with CMMI.

The distinction to make is how "models" are different from (1) "standards", (2) "specification", and foremost, from (3) reality.

Without clarity of these distinctions, implementation of CMMI will be challenging, tedious, and frustrating, and implementing CMMI in agile settings (or vice-versa) will be effectively impossible.

There's a certain skill (not sure how to describe it) in having the ability to take a model and make something real out of it. The more abstract the model, the more developed this skill must be. Because models are abstractions (some more-so than others), it's often helpful to be as detailed as possible when describing examples of what the product of the model might look like. This is what CMMI does. There are many examples throughout of what might be produced when the model is used.

Some of these examples are called "typical work products", and to some, even the "Specific Practices" can be more readily applicable when thought of as "sample" or "suggested" practices.

But here's the point to this post: in the picture, the USS Enterprise (NCC-1701B) is recognized by nearly everyone in every presentation I've ever shown it. And yet, it's not just a model. It's a LEGO® model and still, it's recognized. More than that, it's a computer-rendering of a LEGO® model and still, it's recognized. BUT WAIT! THERE'S MORE! It's a computer-rendering of a LEGO® model of a FICTIONAL space vessel that WON'T BE BUILT for *another* 400 years!

And yet, everyone recognizes it. No one denies that it is an instance of a model.

Here are two things that make this possible, and it is these the confluence of these two things that must be present to enable a successful implementation (or appraisal) of CMMI (or of whether or not it is being applied) in an agile (or any) setting without having to create or see the precise examples of practices or work products described in the text:
(1) People must understand what the model is and how to discern whether what they're doing or seeing represent the model. This is a skill, not everyone has it. And,
(2) People must be thoroughly exposed to, if not immersed in, the context in which the model is being applied.

There are people every day trying to use or appraise CMMI who don't have one or the other or both. It's no wonder they don't recognize the Enterprise when they see it.

Earlier, I mentioned how "models" are different from (1) "standards", (2) "specification", and (3) reality. I'll get to that shortly.
(I hope the wait was worth it.)

Forget the model!

aka: Start with the Process Area names.

I had a tough time coming up with an appropriate title for this entry because of the simple point I want to make...

When/if you're just getting started with your "CMMI journey", don't obsess over the practices or their goals, just look at the names of the process areas and ask yourselves the following question: WHAT do we do in this area?

NOT "Do" we do this area, yes/no? But, "what" do we do?

EVERYWHERE & ANYWHERE it might show up throughout the development processes of your organization.

I would not expect any one PA to show up in any one place, in fact, I wouldn't limit my expectations for where to expect PA "stuff" to show up, so, to widen the net for "what" you do, I'd toss the question out to as much of the development participants as I could from PMs and TMs to developers and testers and product mgrs. Where possible and related to a PA, I'd even seek input from customers.

You need to know what you're doing before you should try to improve it. Too often I find folks trying to dive into the practices in a PA before actually knowing what they actually do.

You can read the purpose statement of the PA to get a sense of it, because your organization might not call what you do by the same name, but from that point forward, until you've described your actual way of performing the PA -- on name alone -- don't get all caught up in the PA's goals and practices... BECAUSE those are meant to IMPROVE your processes, NOT DEFINE them.

If you aren't doing anything in a PA, that's another story. But, my suspicion and go-in expectation is that you've gotta be doing something or you wouldn't be in business.

More on that another time.

Agile Project Leadership Network (APLN) Maryland Group May 15th

Will the shame ever catch up with him?...

Agile Project Leadership Network (APLN) Maryland Group May 15th
Meeting

Keys to Making Agile & CMMI Compatible – speaker Hillel Glazer

You are cordially invited to attend the Agile Project Leadership
Network (APLN) Maryland Group Meeting. The meeting will be held in
Hunt Valley, MD on May 15, 2007 at PHH Arval. The reception starts
at 6 PM, the meeting will start at 7 PM. There is a $15 cost to
cover the food. Plan to bring a friend. We ask that you let us know
if you plan to attend by sending an email to: aplnmd@agilemaryland.org.

Speaker: Hillel Glazer, Principal & CEO, Entinex, Inc.
Topic: Keys to making Agile & CMMI Compatible
Description: A discussion of how to make CMMI agile, and how to
appraise agile methods to CMMI. Discussion will include a hands-on
exercise to demonstrate the compatibility of Agile & CMMI on the same
team.

For details on the meeting including directions, go to our website
apln.agilemaryland.org.

Shameless Plug...

Hey... anyone know anyone who wants to take Introduction to CMMI?

I'll be delivering the class myself for a client, and they have (at this moment) 3-4 spare seats. There will only be 10 people in the class. Nice and intimate with lots of room for personalized attention and Q&A.

Normally, I refer to the Introduction to CMMI as "3 days of wrist-slitting" and *I'm* an instructor!! But that's only if you're stuck in a class led by Borg drones. Which -- unfortunately as it may be -- is a necessary evil of how the materials must be constructed. However, a class led by yours truly... weh-heh-heh-ll... that's a different story of course!

In any case... the class is in Arlington, VA, May 29-31. You get the instruction, all the course slides and exercises, the "blue" book (CMMI® Guidelines for Process Integration and Product Improvement), continental breakfast, and of course, extra attention from *me*!

The class costs are set by my client at only 1000US$! Which is not only less than SEI and most other places, but considering that the course is BOOKED at SEI through the FALL! It's quite a deal!

Hurry! Hurry! Hurry!

Register here.
(You pay me, I pay them.)