A starting point for a discussion on marrying Agile methods and CMMI.New CMMIFAQ Q & A
Posted by Hillel on Aug 7, 2007 in consultant, interview, lead appraiser, skills, talent | Comments Off
A new Q &A have been added to the CMMIFAQ.
Answered is the not so trivial question: How do we pick a consultant or lead appraiser?
This question has come up a number of times. Not usually in such a straight-forward way. Actually, it often comes up in the form of something like:
Doesn’t the variation from lead appraiser to lead appraiser in model interpretation and what will be considered acceptable appraisal evidence make the model bereft of meaning and value?
It’s a legitimate question. How can a model really provide any guidance when there’s so much room for interpretation of the practices and what would be accepted as evidence by an appraiser during an appraisal?
Well, let’s go back to a basic and fundamental root: it’s a m o d e l not a standard or a process. (See this post, please, for more on that.)
And, as such, models are both incomplete and only representative of a particular reality, at best. Some people are just plain better at working with models than others. I’m beginning to believe it’s a talent. And, I’m not sure whether it’s a skill that can be taught — at least not quickly.
I’m still working on how to assess/interview a prospective consultant/lead appraiser for their “talent” at working with the CMMI model. The challenge for most organizations in need of a CMMI consultant/lead appraiser is that their knowledge and comfort level with the (CMMI) model may not be sufficient to recognize “good” answers from “poor” answers — in the context of the given organization, of course.
If you’ve got ideas, please let me know.
(Though… come to think of it… maybe that’s a handbook I ought to write!?)
Nice getting to know companies who know what they’re doing.
Posted by Hillel on Jul 25, 2007 in APLN, Number Six | Comments Off
Earlier this month I spoke at the DC chapter of APLN, which they posted here.
This entry is not to plug that event, but to plug another blogger who did a really great job of summarizing many of the salient points.
What struck me in reading the entry was the fact that the person writing is the company’s CEO, Brian Lyons. Specifically, the accuracy and relevance of his notes, technically, and his knowledge of CMMI.
It’s not often I’m talking to a CEO of a significant software business concern who’s so well-informed about and interested in understanding CMMI.
I’ve known about Number Six Software for several years and had not had a chance to cross paths with Brian until the APLN meeting. Doing so caused me to go back and browse their company site. I was glad to get to know him and the company a bit more.
I suggest plugging a feed from their blog to your favorite reader and keep up with what they’re up to. They’re up to good things and know how to do it.
While on the topic of High Maturity or Capability….
Posted by Hillel on Jul 19, 2007 in CL, High Capability, High Maturity, ML | Comments Off
Just a quick word about Agile & “High Maturity” or “High Capability” practices:
I’m currently visiting the SEI for their Understanding CMMI High Maturity Practices class (since I already understand the concepts, I’m mostly taking it to force me to spend a lot more time with the actual model language than I’d do left to my own devices — and to satisfy certain certification requirements).
One thing I would like to report, since I haven’t pointed it out before, is that agile methods have a serious advantage over non-agile or “traditional” methods when it comes to the High Maturity and Capability practices.
Specifically, Agile’s predisposition to project retrospectives, progress metrics (velocity, etc.) and continual re-planning all lend themselves to having various measures collected, analyzed, and the results worked back into the next iteration or project. Obviously, there must be value to doing so, and even so, doing it should be as automated as possible. But for agile teams working in larger organizations with a process-oriented infrastructure (think: agile team w/in a defense contractor), such a team could get to, sustain and appraise for high maturity or capability levels long before and without nearly as much change or pain as their non-agile co-habitating projects.
For an explanation of what high maturity practices are, please refer to here and look for process areas with an “ML4″ or “ML5″ following the name.
For an explanation of what high capability practices are, please refer to here and look for the goals and practices beginning with “GG4/GP4″ or “GG5/GP5″. You might notice familiar language to the above link.
This site.
The opinions expressed here are the authors' and contributors' and do not express a position on the subject from the Software Engineering Institute (SEI) or any company or SEI Partner affiliated with the SEI.
Your Host
Hillel Glazer
Principal & CEO Entinex, Inc.
Email me.-
