Cmm Is Evil

"To Create Consistent Suckage"

(a comment on the CapabilityMaturityModel)

Enclosed please find draft of <XYZ> procedure. The document lists major steps in <XYZ>. Please send me yr comments (additional activities, check list points, etc.)

+++ Attachment: 20 pages long document, complete with title page, table of contents and glossary of terms, describing the XYZ procedure. It also contains a one page Excel sheet with all the steps listed. Meaning of each step listed would be obvious to any practitioner in the field. +++

I am coming from this perspective: "long procedure documents full of obvious statements are evil, because they distract the reader with trivial details. Therefore nobody will read them more than once, and most people will not read them at all". So, although it gives a nice feeling to author some such document (at least, it does that to me), it rarely adds value. The essence of all the writing is Appendix A (the checklist). In my humble opinion, this is the only documentation that we really need to manage <XYZ activities>. Probably "task owner" column should be added to it; probably Appendix B "Ground rules" is also nice to have attached. Primary purpose of the kick-off meeting, again IMHO, should be then to pull out the previous version's checklist and consider in what ways it has to be altered for the new version. We were dealing on that basis with <XYZ activities in the previous project>, and it worked reasonably well. I know that as an author you love your creature (the remaining 19 pages), but at least please move the checklist to the front. This way, there is a chance that the process can be comprehended before the reader is distracted by all the trivial things in the rest of it. Also, the doc doesn't deal with delivery of <half of XYZ activities>.

FYI, The entire CMM <as implemented> is exactly under yr definition of: "long procedure documents full of obvious statements are evil, because they distract the reader with trivial details. Therefore nobody will read them more than once, and most people will not read them at all". In this case, please send email to <the big boss> to tell him CMM is long procedure documents full of obvious statements. My dear, we are in <big software shop, successfully using waterfall methodology>.

> FYI, The entire CMM <as implemented> is exactly under your definition.

Unfortunately, that is so. Does it mean that we need to create more of the same ourselves?

> My dear, we are in <big software shop>.

That's not convincing. Note that I am not against documenting work processes. I just have a short memory and find that more than 1-2 pages per ritual is impossible for me to remember. I also think that I'm not alone in this.

I totally agree with your approach, but when <the big boss> and all the QA team are asking me in official meeting specifically about this document, I can't show them Excel with 20 lines and tell them, this is the <XYZ procedure>. Unfortunately, such Excel will not pass the QA criterion and once this issue comes from management as "We need <XYZ procedure>", I have to do it by the book (and to mention even obvious statements).

-- AnonymousDonor

And most of the time, it will be after the product has been shipped.

I don't know if CMM is entirely evil, I'd say more that CmmIsAnAntiPattern?.

KeithSader

You cannot simply state that CMM is evil. Making that statement without an auditable artifact flow is against evil best practice. Please create an Evil Requirements Definition document to be submit to an Evil Review Committee as directed in the Evil Development Life Cycle Manual. Once you have obtained the appropriate signatures of the Evil Personnel, you can begin to prepare and Evil Design Document that must be reviewed not once but at least twice. Once you have completed and Evil Preliminary Design Review and an Evil Critical Design Review and again received the necessary Evil Signatures, you can begin to develop your Evil Statement. Once complete, you will have to submit your Evil Statement to an Evil Independent Test consisting of testers who do not know what Evil is but have read through your Evil Requirements Definition.

Of course, Evil is flexible. Feel free to generate your own tailored versions of the thousands of pages of standard Evil Procedures. These will be carefully reviewed by the Evil Process Waiver Committee and rejected after wasting even more time and effort.

These processes are necessary so that an outside Evil Auditor can review our Evil Artifact trail without having a clue as to what we do. Remember, it is not enough to say we are Evil, if we are ever to reach Evil Level 5, Continuous Evil, we need to stop all activity not directly related to creating Evil Artifacts, especially wasteful things like deliverable products.

Real-life story:

A team works in a project that is very different from what the company normally does. So, team sticks to the book on anything related to cross-team coordination (bug tracking, etc), but evolves their own way to do internal work [they are supposed to be tailored versions, right?]. All "tailorings" are carefully considered, documented, and accepted by project management. Everyone is happy. Comes corporate CMM assessment. Verdict: "team does professional work, but tailoring is beyond any rules". Team leader points out that the project is much more successful than three other similar projects. CMM assessors not impressed. "CMM barometer" score below average.

XpAndTheCmm FrankStoneOnCmm