Dear Appraiser:
The other day I was browsing Amazon and I found the page of the book you are writing called Agile CMMI:http://www.amazon.com/Agile-CMMI-Jeff-Dalton/dp/0849383560 . I am very interested in this topic since my organization has projects which follow a formal Unified Process and they are CMMI compliant, but other projects use Scrum + XP, and are definitely not CMMI compliant. I am in charge of the SEPG in the company, and I have difficult times when I try to instill some CMMI artifact in the agile projects. They are all the time bragging about "Hey, check out the Agile Manifesto. It says Working Software over Comprehensive Documentation". Then, I'm speechless. I have no arguments to use except for "Yeah ok. But CMMI requires it". And that ends the discussion, and we cannot agree at all. I know I should try to show the business value of every piece of documentation that is used, but hey, I've never read of Configuration Audits in any XP book!!!
That's funny! The Agile Manifesto (which I believe was written on a napkin in "pumpkin patch" colored crayon) was based on Deming's "Theory of Profound Knowledge" which is the same foundation that CMMI was based on. Tell them to think about that one for awhile....
It's a topic that would take more than a few posts to answer but perhaps I can point you towards some information. I gave a talk at the SEPG conference last year on this subject. You can download it off of our site for free at http://www.broadswordsolutions.com/ off of our resources page. It was the foundation for the upcoming book.
Bottom line - many developers who say they're "agile" are sometimes just "lazy." I did NOT SAY all. I've worked with several that are truly Agile (My friends at DTE Energy being one). Yes, the Manifesto does say that about documentation, but it doesn't say "no documentation" at all. It stresses the right amount . . . which is all I stress as a CMMI Appraiser. Unfortunately, that is often interpreted by developers as "none."
Believe me, Agile is VERY compatible with the CMMI. You may have to get creative with your artifacts as the SEPG leader, and there will more than likely be "alternative practices." . . . one size doesn't fit all.
One interesting approach is to get them, as the "agile experts" to develop their own versions of the processes and work products. I'll bet you a dollar right now that they come up with something FAR more complicated than what you're trying to implement. Why? Engineers like to be very prescriptive! It can be amusing to watch the horrible things they do to themselves in the name of process. J ust be sure to step in and help before they get too out of control.
My friend and colleague, author Ron Jeffries, one of the original signers of the "Agile Manifesto," and I were on a panel discussion together the other day at an IT software developer event. The promoters of the event advertised it as a "smackdown" with Agile vs. CMMI. The place was packed with people from both camps anxious to see the blood fly. Guess what? We agreed on almost every question the moderator asked! It was fascinating to hear how the issues were more about interpretation and perception, not about conflict. You'd think the audience might have been dissapointed - but they stayed after for HOURS asking more questions and commenting on how valuable the discussion was.
Can't we all just get along? :)
http://www.broadswordsolutions.com/
2 comments:
You dont know what you are talking about dude. Apply to Thoughtworks and we will let you work as a developer in a project if you are good enough and you may have a chance to see what Agile really feels like... ;)
Wow! Thanks for that phatt job offer! Being on a development team again ... working weekends, all hours, not having a life. Man that sounds like fun! On second thought, maybe not. Thanks anyway!
Post a Comment