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

(responding to Scott P)

>> (Paul)
>| 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.

> (Scott P)
> First off, there are many software practitioners who DO work in shops
> that specialize in a particular domain and where projects are very
> similar over time. Companies that build products with significant
> software content usually have development teams that remain within
> the domain for long periods.  Even in consultancies, many specialize
> in either a technology domain or a business domain.

Agreed.  And it's good that these folk have something that suits 
them, assuming it does.

> However, I think that's beside the point, because I really disagree
> with the premise that CMM maturity is dependent on doing the
> same type of software over and over.

We thrive on disagreement  ;-)

> The CMM is about having a defined, institutionalized (that is,
> well-understood by all participants) approach to building
> systems; the CMM goals are generally about how you share
> information and how the organization monitors and controls
> projects, rather than about their technical processes.  Many of
> the elements of, for instance, XP, are very much in line with the
> CMM goals.

I *like* the CMM goals.  Except that bit where it keeps saying
everything needs to be *written*.  That's a solution to a set of
problems.  To me, that niggles, just like a design decision in
an analysis model niggles.

Let's take XP as an example.  There are 12 'rules' to XP, so
we say what we do, when we do XP.  Yet there is no way of
proving to an auditor that we do what we say; there's no
paper trail.

And then, XP teams do fail (down, J.B. ...) through lack of experience,
lack of somebody to keep them on track.  

There's a whole series of books on supplementary practices
to support the 12 rules.  One could call this the result of
process improvement.  There's the XP forum, to share experience.
Could XP teams that subscribe to XP Forum claim to be
doing process improvement?  In effect they are, but the
process tends to be in the minds of the team, rather than written
down.


> The only place that experience with similar projects really
> comes in is in items about estimation and collecting historical
> data to improve estimation.  If you're starting something new,
> you have to estimate based on the best analogies you can
> draw to things you have done before. That's not really
> surprising - every project has some aspects of novelty, so
> you're always extrapolating to one extent or another.

Of the projects that I cite in my previous mailing, about the
only ones that were fairly similar were the two DBMS.  Yet
of these, one had an in-house 'customer', while the other
had a 'customer' in another country.  In fact we didn't have a
defined process at all, except maybe 'just do it'.  I think it
unlikely that any defined process would be suitable for
both situations unless it said very little at all.  The point I am 
trying to make is that so much varied between projects that 
it was not worth our while trying to define a process.  Each
new project was 'cutting edge'; each had a whole new set
of problems.  The common process between the projects
would have filled about half a sheet of A4.  Had we given this
process to anyone else and asked them to follow it, they 
would surely fail.  The gap between that and what we had
to do to succeed was far too big for most folk to cross.

This situation has a lot in common with many others, but
the common factor seems to be the degree of variety in
the work.  If the work is vary varied, for whatever reason,
written process costs more than it is worth.  The idea of shop-
based process is also questionable in some cases, such as
where the team I was on was composed entirely of brought-in
consultants and in-house domain experts.  The team
dispersed after the project.  In fact this is merely an extreme
example of a common trend - people move between shops
frequently.  CMM is ideal for high stability environments,
but the underlying assumptions seem to fall over in more
chaotic environments.  Some other approach to process may
be better in these environments.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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
--^----------------------------------------------------------------