dgp@stc-d.UUCP (dgp) (04/02/85)
Quality Circles
================
Recently I asked if anybody had experience of using quality circles
in a software development environment. I received four resposes
from people** who had relevant personal experience. In addition I
received a message from one person confirming the use of quality
circles but was not able to pass on the experience.
The basic message appears to be that Quality Circles are usefull
but not fundamentally important. One correspondent seemed to
equate Quality Circles with Reviews/Walkthroughs/Inspections
(R/W/I). However most people made a substantial distinction. The
consensus appears to be that R/W/I are applicable to a cohesive
workgroup as part of their work in "getting a product out". In
contrast Quality Circles is not applicable within such a
workgroup. Quality Circles seems to be primarily of use in the
activities which support and surround software design and
development.
My impression from the correspondents is that Circles need a lot of
management support but not detailed management involvement.
Quality Circles"s seem to die out fairly readily. Only one person
<halls@boulder.UUCP> said that Quality Circles"s were a permanent
feature of his company"s way of working. The others had either
tried one year experiments and apparently not carried on or had
more specificaly given up.
The specifics of the advice comming to me via network mail is:
- Quality Circles do best with projects and problems
that the circle can implement. <halls@boulder.UUCP>
<wmartin@brl-tgr.arpa>
- Choose problems that help one to do the job better
but not directly doing the job. <halls@boulder.UUCP>
- If you want to work in a company where there are no
"they s" , get Quality Circles started.
<halls@boulder.UUCP>
- Do not be too formal. (all respondents)
- Do not allow any one above the Supervisor level.
<olsen@wxlvax.UUCP>
- Keep the Management informed e.g. meeting with
higher-ups every four months. <olsen@wxlvax.UUCP>
<halls@boulder.UUCP>
- Allow grievances, complaints and the like to be
expressed. <olsen@wxlvax.UUCP>
The end result of the advice is that circles should target
themselves at:
- Procedures which cause hang-ups
- How to organise better R/W/I
- How to access necessary information
- Improvements in training (both formal and informal).
My conclusions after reading the mail are that Quality Circles
are not an essential. Their main use in a software development
environment seems to be:
- To provide additional communications channels
- To provide a safety valve for frustrations
- To give some high grade thought to procedural
problems.
Some of the recommended literature:
-The Mythical Man-month by frederick P Brooks ,Jr.
This book was first published in
1975 and covers the authors
experience with IBM System 360 in
the 1960"s. It is not about Quality
Circles but was recommended by
one correspondent.
-Quality is Free by Philip B. Crosby.
First published in 1979 it covers
the author's ITT experience.
"Quality is free. It's not a gift
but it is free. What costs
money are the unquality things
- all the actions that involve
not doing jobs right the first
time."
-There is an
International Association of Quality
Circles
PO BOX 30635
Midwest City
Oklahoma 73140.
(405)737 6450.
** Thanks to: <canopus@amdahl.UUCP> Frank Dibbell
<dcn@ihuxl.UUCP> Dave Newkirk
<halls@boulder.UUCP> Andy Halls
<li51x@sdcc3.UUCP> Michelle
<ndiamond@watdaisy.UUCP> Norman Diamond
<olsen@wxlvax.UUCP> Neil Olsen
<wmartin@brl-tgr.arpa> Will Martin
--
Regards,
Gareth Phillips. <dgp@stc.UUCP>
...!mcvax!ukc!stc-a!dgp