Wednesday, April 2, 2014

What can we learn about Process Architecture from Justin Beiber?

[Dear Readers, for the past several months, our good friend Pat O’Toole, CMMI expert and seasoned consultant, has been collaborating with us on a monthly series of CMMI-related posts, "Just the FAQs." Our goal with these posts is to provide answers to the most frequently asked questions about the CMMI, SCAMPI, engineering strategy and software process improvement. This month Jeff takes the helm with an article about process architecture and Justin Beiber. And away we go! ~ the CMMI Appraiser]

Our Process Consultant tells us that we need to apply an equal amount of rigor to all 350+ practices in Maturity Level Three, and that everyone must do everything “the same way, every time.” She says that this will “guarantee” that we will “pass our appraisal.” Is this right? ~ Celia Z.

Justin Bieber’s “Baby” sounds pretty darn good on my iPod.

What? Did I just say that?

Yes I did. And as a matter of fact, he sounds GREAT on my iPod! Don’t get me wrong, he’s not my style, and if it weren’t for the fact that my 12 year-old niece gifted me a copy of it on iTunes (I must have done something very mean to her), I wouldn’t have it at all. But here it is - and it sounds GREAT!

It sounds great because the engineer turned all of the “knobs” to the right place. They’re not all turned up to “11.” In fact, some are turned most of the way down (and should be). The mix is tailored just for you (or my 12 year-old niece, to be more precise).

On the other hand, I have an old recording of Pink Floyd from the 70s that I recorded on a handheld cassette recorder at a live show in Madison Square Garden, and it sounds AWFUL. Now, I freely admit I don’t remember much about that night, but I do know one thing: those knobs were definitely in all the wrong places!

The CMMI is a little like the knobs on a sound engineer’s mixing board. In fact, the CMMI’s mixing board is a lot bigger, with more than three-hundred and fifty knobs in Maturity Level Three, each one of them affecting not only the outcome, but also one another. The potential for tailoring (and results) is staggering!

We can’t possibly have all of our process knobs turned up to “11,” and we can’t have them all set in the same way for each team, project, or company. Each instantiation deserves its own unique mix. That leads us to an indisputable truth that some practices are more (or less) important than others - but only as it pertains to your project, your team, and your objectives.

What? Some practices aren’t as important as others?

That’s right. That’s why “fixing” a “partially implemented” practice by reverse engineering the practice and cranking up its intensity and documentation doesn’t always yield the result you were hoping for. Sometimes that weakness is caused by the way we have all of the other knobs set. I call that approach to fixing appraisal results “whack-a-mole." Who knows what carnage you’ll introduce to the system when you ”fix” one of these? You’ll end up hurting yourself if you’re not careful!

Some consultants are fond of saying that ML3 is about “everyone doing everything the same way, every time.” I’ve heard others say “more than 54.7% of the subpractices must be implemented for it to be FI!” Others say that every practice and sub-practice must be given equal attention.

I disagree on all counts.

That’s because the model and the training materials scream “’DEFINED PROCESS’ DOESN’T MEAN ‘A SINGLE PROCESS THAT IS WRITTEN DOWN!’” It’s more akin to “select”, “customize,” or “modify.” But for some reason, people still don’t get it.

And for the record, it means “multiple,” not one.

Or to paraphrase one of my little niece’s favorite movies: “Defined. You keep using that word. I do not think it means what you think it means.”

In order to better visualize this, it helps to take an integrated view of the following practices:

IPM SP1.1: Establish the Defined Process
QPM SP1.2: Compose the Defined Process
OPD SP1.1: Establish Standard Processes
OPD SP1.3: Establish Tailoring Criteria and Guidelines
GP3.1: Establish a Defined Process

When you throw in clarifying material from the “Introduction to CMMI” class, it becomes obvious that a flexible architecture that supports multiple processes with controlled variability is what the model is calling for - and what makes your project more successful.

Contrary to these consultants’ claims that “sameness” is a requirement, in all but the most cookie-cutter applications adoption and enforcement of a single process, and by definition the absence of “a defined process” will likely lead to an unsuccessful appraisal. Why? Because forcing everyone down the same process path with all practices equally turned “up to 11” implies little or no tailoring, or that no analysis was used in composing a project’s defined process – or as I like to call it “the way do our work.” Talk about mindless Maturity Level One behavior!

Creating a successful Defined Process is all about where we choose to place the knobs. Should we use Planning Poker or COCOMO? Should we use Fagan Inspections or bench reviews? Should we use a daily standup or an all-hands status meeting? All of these tools can, and should, be in your toolbox – and pulled out at the right moment. It’s a question of where, when, and how they are applied.

Placement of the knobs will determine the outcome, so choose carefully, it’s the difference between a good project and a great one!

Oh, and for a fun example of how sound engineers turn their knobs to make people like Justin sound so good, check out this video on YouTube:

“Just the FAQs” is written/edited by Jeff Dalton and Pat O’Toole. Please contact the authors at and to suggest enhancements to their answers, or to provide an alternative response to the question posed. New questions are also welcomed!

No comments: