This week I
completed my 88th presentation of “Introduction to CMMI-DEV” and, needless to
say, my evolution from slide-reader to evangelist took place long ago.
Me (using my
best evangelical, big tent voice): “Goals
are WHAAAAAT?”
Them (in a
postulate tone): “R-E-Q-U-I-R-E-D!”
Me:
“Practices are WHAAAAAT?”
Them: “E-X-P-E-C-T-E-D! “
Me: “Everything else?”
Me: “G-O-O-D
I-N-F-O-R-M-A-T-I-O-N! “ Whoo
hoooo!
I followed
that up with my usual sermon about what “expected” really means - it’s what the
CMMI generally expects to see in order to achieve a given goal within the
context of the business model. Since we
conduct appraisals through the examination of practices and the “evidence” they
collectively produce, it’s usually a hot topic during my classes that are often
filled with potential Appraisal Team Members.
In the back
of the room, a young woman (who I could have sworn had just been nodding off)
raised her hand and asked, “what if we’re just smarter than you are?”
Rut roh! Cue the music!
She was
making a great point. I’ve been lucky
enough to work with people who are almost universally smarter than I am, and
with so many approaches to systems and software engineering executed across so
many cultures, I am always learning about innovative ways to accomplish a task.
Lead Appraiser’s haven’t seen everything, and the very fact that the practices
are “expected” is recognition of that.
These are, of course, known as “Alternative Practices.”
The CMMI
glossary defines an alternative practice as something that is a “substitute”
for one or more Specific or Generic Practices.
This leads
us to Rule #1: “Sometimes there is
another way.”
In general,
the CMMI does a reasonably good job of anticipating the practices a project will
employ to achieve a particular Goal, and they are described in general enough
terms that they apply to most situations.
In fact, some of the practices are SO general and high-level, that it
leads to confusion in the market about what projects teams are supposed to do!
That leads
to Rule #2: “There are not many other
ways.”
Every few
years this topic is hotly debated on one of the CMMI message boards that has
not yet been shut down due to the religious extremism exhibited by its members,
and they always end up in the same place:
Rule #3: “Just ‘cause it’s interesting doesn’t mean
you’ve discovered an alternative.”
My good
friend and “Just the FAQs” writing partner, Pat O’Toole, dug into this topic a few
years back in one of his useful ATLAS studies.
He asked the community to provide examples of “alternative practices” that
they had run across in their travels. His
data suggests that they are few and far between – 5 out of 44 candidates were,
in fact, agreed to by the community-at-large to be true alternatives to the
CMMI’s Specific and Generic Practices.
And some of those are, IMHO, still open for debate.
Pat calls
those 39 remaining practices (and I presume many others he has run across) “alternative
implementations,” and I use the term “innovative implementations.” Teams do often
come up with innovative ideas for behaviors and processes, but that, in itself,
does not mean that an alternative has been discovered (nor does it mean that
the authors of the CMMI thought of that innovative implementation when they
designed the model!).
In searching
for examples, people sometimes get hung up on the sequence and grouping of
practices, and they find themselves searching for that direct one-to-one
alternative to a single practice. Save
yourself some time because . . .
This leads to
Rule #4: “Alternatives rarely map
one-to-one with the CMMI practices.”
There are often
many-to-many, or at least a “many-to-one,” relationships between any
alternative and a single or group practices, creating even a greater
opportunity for confusion between “alternative” and “innovative.”
In my
experience, the most commonly referenced “alternatives” are related to one
“agile” practice or another. Perhaps
this is because they are gaining in popularity, (or because they just aspire to
be different…), but team members often refer to agile estimation techniques –
planning poker or Fibonacci sequencing for example - as an alternative to the CMMI’s estimation
practices in Project Planning. I mean –
who wants to do THOSE THINGS? But even
though these are both VERY innovative approaches to estimation, they are simply
collaborative techniques based on sizing that fit quite nicely into the
“expected” category.
Another
common suggestion is that the use of “sprints” (scrum) or “iterations” (XP) are
an alternative to the CMMI’s expectation that a “lifecycle” be defined and
employed (PP, OPD, IPM, et al). Ditto
for Kanban for software. Again, while these
are an innovation in the software product management, these are still a kind of
“lifecycle” – albeit conceptually very different from what some of us experienced
while we were coming up in the industry.
Here’s some
others I often hear:
Pair
programming? Nope, peer reviews.
Retrospectives?
Uh uh. Collect Process Related
Experiences
Backlog
Grooming? Ah ha! That must be one! It’s REALLY alternative! Nope.
It’s an innovative combination of Requirements Management, Validation,
and Project Planning. Good stuff for
sure – just not an alternative practice.
While
Alternative Practices are sometimes treated as secret black magic that only the
most seasoned Lead Appraisers can interpret, my experience has been quite the
opposite…..
This leads
Rule #5 – the final rule: “Most alternative practices are mundane and
administrative.”
“What? After all this you tell me that the mythical “Alternative
Practice” is BORING?”
I’m afraid
that’s mostly true. Maybe not all of them (since I’m not smart
enough to know them all), but the most common ones seem to be pretty
unimpressive.
·
Your customer directs you to use a supplier
·
Your customer tells you what the architecture
and technology will be
·
The government “helps” you by giving you the schedule and budget they want you to use
·
Another company does independent V&V
·
On a 10-year maintenance project you use a
“push and pop” ticketing system since a WBS with life-cycles is not that useful
On the other
hand, if your customer changes the requirements the night before launch, it is NEITHER alternative nor innovative!
Good luck –
and focus on innovation, not alternatives!
“Just the
FAQs” is written/edited by Jeff Dalton and Pat O’Toole. Please contact the authors at jeff@broadswordsolutions.com and pact.otoole@att.net to suggest enhancements to their
answers, or to provide an alternative response to the question posed. New questions are also welcomed!
