RE: CMM thoughts; was: RE: [AM] Article of Interest in CIO Magazine

> Paul Oldfield Sent: 08 March 2004 08:51
> 
> (responding to Mike)
> 
> > Just looking at that magazine last night... It has on the cover, 
> > "Bursting the CMM Hype" How to probe CMM claims, 12 
> critical questions 
> > to ask.  Have not read it yet but on my list.  Might be good to 
> > discuss here.
> 
> Having had a quick look at the article and questions, I find 
> I might want to take the discussion in at least 3 different 
> directions. Yet if I investigate the directions, they all 
> have an underlying theme. While I have great respect for the 
> list of goals that CMM provides, I have problems with the 
> assumptions that underly their idea of 'process'; in 
> particular the ones that result in the idea of 'repeatable 
> process'.  This seems to be based on an assumption that a 
> shop will be producing the same broad type of software time 
> after time, so there will be a large degree of commonality in 
> the process that is needed to develop that software.
> 
> Where this is, in fact, the case, this is fair enough.  Yet 
> that does not help the places where the software varies 
> considerably for each project.  It does not help 
> consultancies that need to 
> advise on process for a wide range of development shops.
> It does not help a mobile workforce that move from one shop
> to another following the work.  In fact, this basic 
> underlying assumption does not hold for any of the places 
> that I have worked, throughout my whole career.  
<snip>

I think one of the greatest misconceptions about CMM in particular and
process in  general is that it will automatically produce great
software. CMM is about maturity of process. That doesn't necessarily
mean having the same process all the time. In fact the higher levels of
CMM require constantly adapting the process, and that almost fits with
some of your own ideas. The goal of CMM is to have the right process for
a particular project.

However having the right process for a project provides absoklutely no
guarantee that the project will be a success. It just means it won't
fail because of inappropriate process. It could still fail through any
number of the other traditional reasons.

Process it just one factor that contributes towards the success or
failure of a software project, and as we have frequently discussed is by
no means the most important. You can have the best process in the world,
but with the wrong people you will get failure.

Which is why, of course, the agile manifesto puts people ahead of
process.

Regards

Ian Chamberlain

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------