[Dear Readers, our good friend Pat O’Toole, CMMI expert and seasoned consultant, is collaborating with us on a new 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 Alternative Practices. Take it away! ~ the CMMI Appraiser]
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!