To really foul things up LO5224

Eric Opp (eopp@mrj.com)
Tue, 30 Jan 1996 08:51:40 -0500 (EST)

Replying to LO5104 --

On Thu, 25 Jan 1996, Gray Southon wrote:

> You describe CMM as if it was simply a personal exercise. The documents I
> read talk about largscale corporate exercise with dedicated quality
> sections, masses of formalised recording of procedures and measurements,
> certified inspectors who assess the level that organisation the
> organisation is up to and requirements by some customers that their
> contractors are up to particular standards. You yourself talk of the
> analogy with the automobile production line - and getting away from the
> concept of the lone operator. Are we really talking about the same thing,
> or have I got it wrong?
>
> How much objective evidence is there that it works, either as at the
> corporate level or the personal level? I have read some claims of success,
> but that was from the promotors of the system.

The point that I was trying to make with my two posts were that there
are two components to the CMM - one on an individual level and one on a
team level akin to the five disciplines, which have components which are
effective on an individual level and on a team or group level. The
individual level of the CMM comes down to discovering your personal
ability to estimate, your personal ability to eliminate those defects that
*you* the individual introduce into your programming assignments and those
things you can do to optimize your own programming process. This then
feeds into the team level. I.E. the manager of a team cannot give an
accurate estimate of the resources required for a specific project unless
he or she has a good understanding of the "productivity" and ability to
estimate of each of the members of the team. The manager cannot lead the
team to eliminate some of the bigger and subtler defects introduced into a
project by the individual team members.......

In short, you have not gotten it wrong, and we are talking about the
same thing! Personal Mastery is one of the five disciplines, which are the
components of a learning organization, but it is more of an individual
discipline that the others. Mental Models - ditto, but you will have a
hard time getting a team to question the whole team's Mental Models, if
you have not made the effort and practiced questioning your own personal
mental models.

The analogy to a production line is such that creative freedom is given
in those area of the project where it is actually required in some of the
design phases, while defining and understanding the programming process to
the point that both the individual and the team can produce a higher
quality product more efficiently. For Example, you might write a team
standard or template for functions (or subroutines) so that all members
can use the same format. This would be akin to defining which bolt (thread
size & pitch and strength) to use to assemble the cylinder heads, or the
connecting rods or whatever. It would certainly foul up the entire
production process, if you did not know what size hole was drilled and
what size threads were cut into the crankcase by someone upstream so that
you would have to stop the line for 1/2 hour for each engine to go to find
the matching bolt. Such things do, however, happen in the software
process.....

As far as evidence from third parties, it is hard to tell - I have much
"head" knowledge and little "practical" knowledge in this respect. It also
seems to be a bit of a chicken and egg dilemma. The CMM may not be the
"ultimate" standard, but more and more customers are looking for some kind
of rating or certification that uses the CMM as a measuring stick. I have
also gone through with enough small and large scale programming projects
to know intuitively that "there must be a better way."

I hope I have cleared up some of the points I have made in my earlier
post. I am definitely also "trying to figure this out" as I go along (more
on the learning and exploring end than the teaching end).

--
  Eric N. Opp
  MRJ Inc.
  eopp@mrj.com