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

[Paul Oldfield]

(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. The first place I worked
I was working on an Expert System in Prolog, followed by a
metrics gathering and cost prediction tool in 7 different
languages. The second place I worked I was working on
an Ada compiler and development environment, two
object-oriented database management systems, a
Geographical information system, a system for computer-
supported co-operative work, a real-tine architecture
simulator, a distributed object system, and a feature-based
CAD system. The third place was a telecomms shop,
where the team may work on billing, CRM, switches or a
variety of other software, as the need arises. The fourth
team (Air traffic control) was entirely of external consultants
except for the domain specialists. The list goes on.

I agree that owing to the nature of my career, there may be
an inherent bias toward variety and places that deal in variety.
However, these places need some way of thinking about
process that breaks out of the rigidity of the CMM mindset,
that is not constrained by the mistaken, or at least not universally
applicable, assumptions that underpin much of CMM.


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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[p***@aol.com]

In a message dated 3/8/2004 12:55:35 AM Pacific Standard Time,
***@compuserve.com writes:
However, these places need some way of thinking about
process that breaks out of the rigidity of the CMM mindset,
that is not constrained by the mistaken, or at least not universally
applicable, assumptions that underpin much of CMM.
Paul:

Another of your "Pearls of Wisdom". I agree that the application of CMM is
most effective in places where they're concerned with developing the same kinds
of systems every time. However, what successes that have been achieved with
the CMM approach has created something of a "buzz" that has incented some to
seek certification and employ it as a competitive advantage for which it may not
be justified. Like certification in anything, "it ain't necessarily so!". It
is certainly not a guarantor of project success.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott E. Preece]

| From: Paul Oldfield<***@compuserve.com>
| Date: Mon, 8 Mar 2004 03:51:19 -0500
|
| (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.
---

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.

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.

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.

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.

scott
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Ian Chamberlain]

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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Paul Oldfield]

(responding to Scott P)

Post by Scott E. Preece

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

Post by Scott E. Preece
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 ;-)

Post by Scott E. Preece
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.

Post by Scott E. Preece
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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Michael Vizdos]

Hi all [responding to Paul and others who have contributed to the initial
thread]...

Thanks for an active discussion on this topic. As usual, I am learning
tons. After lurking here quietly for a few years, I'd like to start asking
more questions and throwing in my two cents when I can.

Regarding CMM.... In the end, it seems that CMM Level X only really shows
that a small percentage of an organization can repeat some type of
documented process (seems a lot like the ISO stuff except without the
ongoing certification checks). One of the points made in the article is
that there is no governing body to say who is really certified (yes the SEI
has people certified to bla bla bla), and that anyone who just blindly
believes that an organization is CMM Level X should do their homework. I
think that applies to any process or methodology.

Which leads me to....

Another part of the threads on topic kept trying to address what
methodologies to use. I know I am preaching to the choir, and others have
said this. Hang with me for a minute.

While working in this industry for only 15 years (still a newbie in relation
to many people on the list) and working on both prescriptive waterfall and
"agile" projects, I have found that the end user / customer does not care
what methodology is used to get to the end result -- working systems.

People are the main input to any of the methodologies -- either prescriptive
or agile or whatever combination is used. I have seen both prescriptive and
agile based projects fail, and usually the process is blamed. When it is a
success, it is usually transparent to the end user/customer/other
stakeholders and the process may not even be mentioned. As an industry I
continue to see IT departments get slammed because they cannot deliver. The
trust is blown away between the various stakeholders and the IT departments.
Sometimes consultants get called in. Silver bullets may or may not be
promised. A new attempt is made. People moan about it. The cycle
continues, until.... ?????

I'd like to get feedback on the ?????.... I have some thoughts but want to
see if this leads anywhere (or more specifically... Where it leads).

Just want to throw this out for thought (smile).

- mike vizdos

-----Original Message-----
From: Paul Oldfield [mailto:***@compuserve.com]
Sent: Monday, March 08, 2004 12:51 AM
To: INTERNET:***@topica.com
Subject: CMM thoughts; was: RE: [AM] Article of Interest in CIO Magazine

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

{mjv snip}

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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