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.)