An empirical study on the utility of formal routines to transfer knowledge and experience.
Most quality and software process improvement frameworks emphasize written (i.e. formal) documentation to convey recommended work practices. However, there is considerable skepticism among developers to learn from and adhere to prescribed process models. The latter are often perceived as overly "structured" or implying too much "control". Further, what is relevant knowledge has often been decided by "others"---often the quality manager. The study was carried out in the context of a national software process improvement program in Norway for small- and medium-sized companies to assess the attitude to formalized knowledge and experience sources. The results show that developers are rather skeptical at using written routines, while quality and technical managers are taking this for granted. This is an explosive combination. The conclusion is that formal routines must be supplemented by collaborative, social processes to promote effective dissemination and organizational learning. Trying to force a (well-intended) quality system down the developers' throats is both futile and demoralizing. The wider implications for quality and improvement work is that we must strike a balance between the "disciplined" or "rational" and the "creative" way of working.
Figure

1. A model of knowledge conversion between tacit and
explicit knowledge [27].

Figure

1 expresses that practitioners first internalize new
knowledge (i.e. individual learning). The new knowledge is then
socialized into revised work processes and changed behavior
(group learning). The new work processes and the changed
behavior are then observed and abstracted, i.e. externalized. This
new knowledge is then combined to refine and extend the existing
knowledge (organizational learning). This process continues in
new cycles etc.
To enable learning is the crucial issue, both at the individual,
group, and organizational level. The latter means creating and
sustaining a learning organization that constantly improves its
work, by letting employees share experience with each other.
Around the underlying experience bases, there may be special
(sub-)organizations to manage and disseminate the stored
experience and knowledge, as exemplified by the Experience
Factory [7]. We also refer to the workshop series of Learning
Software Organizations [4] [9].
Other fields have introduced the term organizational or corporate
memory to characterize an organization's strategic assets,
although not only from a learning point of view [1].
The knowledge engineering community has also worked on
experience bases, often with emphasis on effective knowledge
representations, deduction techniques etc., and towards a wide
range of applications. The subfield of Case-Based Reasoning [3]
has sprung up from this work, enabling reuse of similar, past
information (cases) to better master new situations. We will also
mention the subfield of Data Mining [20].
Social anthropologists and psychologists have studied how
organizations learn, and how their employees make use of
information sources in their daily work. Much R&D effort has
been spent on the externalizing" flow, looking for valid
experience that can be analyzed, generalized, synthesized,
packaged and disseminated in the form of improved models or
concepts. For instance, to make, calibrate and improve an
estimation model based on the performance of previous software
projects. Explicit knowledge may nevertheless be misunderstood
due to lack of context and nuances, e.g. how to understand the
context of post-mortems?
However, the hard part is the internalizing" flow. That is, how to
make an impact on current practice, even if updated knowledge
may be convincingly available? See for instance the ethnographic
study on the use of quality systems in [40]. Typical inhibitors are
not-invented-here", mistrust (been-burned-before"), lack of
extra time/resources (not-getting started), or plain unwillingness
to try something new or different (like adhering to formal
procedures in a quality system). A study of maintenance
technicians for copy machines indicated that such experts were
most likely to ask their colleagues for advice, rather than to look it
up in or even to follow the book [10]. Indeed, how many times
have not computer scientists asked their office mates about
commands in Word or NT-Windows, instead of directly
consulting relevant documentation - although a query into the
latter can be hard to formulate.
Furthermore, the existence of software quality manuals, either on
paper in thick binders (sometimes 1-2 m in the shelves) or in web
documents on an Intranet, is no guarantee for their use. In fact,
since manuals may dictate people on how to perform their job,
traditional quality departments in many software organizations are
not looked upon with high esteem by developers. For instance,
there are over 250 proposed software standards [32], many of
them recommending standard process models, but how many of
these are in practical use?
So, if we are to succeed with formal routines and explicit
knowledge in a quality system or a SEB to achieve learning, we
must not carry the traditional QA hat of control. This does not
mean that all, formal knowledge in the form of books, reports etc.
(like this article) has to be discarded. The lesson is just that formal
routines must be formulated and introduced with proper
participation from the people involved, in order to have the
intended effect on practice.
Lastly, many of the ideas and techniques on quality improvement
(TQM and similar) come from manufacturing, with rather stable
products, processes and organizations. Information technology, on
the other hand, is characterized by rapid product innovation, not
gradual process refinement [33]. One IT year is like a dog
year (7 years) in other disciplines, and time-to-market seems
sacred (i.e. schedule pressure). The strength of many software
SMEs (Small and Medium-sized Enterprises) lies in their very
ability to turn around fast and to convert next week's technologies
into radically new products and services. Barrett [6] has used the
term improvisation, a jazz metaphor, to characterize performers
that execute evolving activities while employing a large
competence base. With reference to our software development
context, we must carefully adopt a set of quality and improvement
technologies that can function in a very dynamic environment - so
how to manage constant change [17]? Since SPI assumes that
there is something stable that can be improved, we must pick
our learning focus accordingly. For instance, the Norwegian
Computer Society (www.dnd.no) is now offering a course in
chaos and complexity theory as an alternative to manage highly
evolving projects.
However, it is fair to say that especially TQM is aware of the
cultural and social dimensions of quality work. TQM has a strong
emphasis on creating a learning organization, and having all
employees participate and involve themselves in order to satisfy
their customers.
So, how can software organizations best systematize, organize and
exploit previous experience in order to improve their work?
3. CONTEXT, QUESTIONS, AND
3.1 The SPIQ Project
The SPIQ project [12] was run for three years in 1997-99, after a
half-year pre-study in 1996. SPIQ stands for SPI for better
Quality. The project, which was funded in part by the Research
Council of norway, involved three research institutions and 12 IT
companies, mostly SMEs. More than 20 SPI pilot projects were
run in these companies. A follow-up project called PROFIT is
now carried out in 2000-2002.
The main result of the SPIQ project was a pragmatic method
handbook [16], with the following components:
A dual, top-down/bottom-up approach, using TQM [15] and
Quality Improvement Paradigm [7] ideas.
An adapted process for ESSI-type [19] Process Improvement
Experiments (PIEs).
The Goal-Question-Metric (GQM) method [8], and e.g. GQM
feedback sessions.
The Experience Factory concept [7], to refine and disseminate
project experiences.
An incremental approach, relying on action research [22].
Reported empirical studies from five SPIQ companies.
Typical work in the 12 SPIQ companies included pilot projects to
test out a certain improvement technology, like novel inspection
techniques, incremental development, or use of measurement and
software experience bases.
For further results from comparative studies of SPI success in the
SPIQ companies and in several other Scandinavian PIEs, all
emphasizing organizational and cultural factors see e.g. [13], [14],
[18], and [37].
3.2 How the Study Was Performed
organization: The actual study was carried out between
NTNU/SINTEF and five companies participating in the SPIQ
project. Data collection was carried out by two NTNU students in
the last year of their M.Sc. study, as part of a pre-thesis project
[11]. The two students were advised by the two authors of this
paper, the former being their teacher and also a SPIQ researcher,
the latter being a researcher and Ph.D. student attached to the
project.
Preparation: First, the student read and learnt about the project
and relevant literature. Then we tried an initial formulation of
some important issues in the form of research questions, and
discussed these. At the same time, we contacted potential
companies and checked their willingness to participate and their
availability. Then a more detailed interview guide (see 3.3) was
designed, in dialogue between the students and their advisors. The
companies had been briefed about the questions, and when and
how the interviews were going to be run.
Research questions - important issues to address are:
Q1: What is the knowledge of the routines being used?
Q2: How are these routines being used?
Q3: How are they updated?
Q4: How effective are they as a medium for transfer of
knowledge and experience?
And, furthermore, are there important differences between
developers and managers, and how much cooperation is involved
in making and updating the routines?
Subjects: Initially, we tried to have a dozen companies involved,
but the time frame of the students' availability (three months in
spring of 1999) only allowed five companies. One of these was in
Trondheim, the rest in Oslo. Three of the companies were ISO-
9001 certified. Two of the companies were IT/telecom companies,
the rest were software houses. A convenience sample (i.e.
available volunteers) of 23 persons were interviewed based on
their experience with SPI, whereof 13 developers and 10
managers. The latter group included one quality manager and one
software manager (e.g. division or project manager) from each of
the five companies.
Data collection: After finishing the interview guide, this was sent
by email to the respondents. A few days later, the two students
visited the companies, and spent a full day at each company. At
each place they spent up to one hour with each respondent in
semi-structured interviews. In each interview, the four questions
were treated one after another. One of the students was asking the
questions, and both students made notes (interview records)
during the interview. The other student served as a scribe, and
wrote down a structured summary immediately after the
interview. The first student then checked this against his own
notes.
Data analysis: The ensuing categorization and data analysis was
done by the two students, in cooperation with the authors, and
reported in the students' pre-diploma thesis.
3.3 The Interview Guide
As mentioned, we formulated four main research questions,
with a total of 14 sub-questions:
Q1. Knowledge of the routines.
1.1 Describe the (possible) contents in routines being used for
software development.
1.2 How were these routines introduced in the company?
1.3 What was the purpose of these routines?
1.4 What is you personal impression of the routines?
Q2. Use of routines.
2.1 What status does a given routine have among developers?
2.2 To what degree are the routines actually being used?
2.3 Who are the most active/passive users?
2.4 What is the availability of the routines?
2.5 How is follow-up and control of usage done?
Q3. Updating of routines.
3.1 What procedures are used to update the routines?
3.2 Who participates in the update activities?
Q4. Routines as a medium for transfer of knowledge and
experience.
4.1 Do you regard written routines as an efficient medium for
transfer of knowledge and experience?
4.2 What alternatives to written routines do you think are useful
or in use in the company?
4.3 What barriers against transfer of experiences do you think
are most important?
The interview guide contained advice on how to deal with
structured questions, usually with three answer categories such as
yes-maybe-no or little-some-much. We allowed more
unstructured commentaries in the form of prose answers to solicit
more direct and commentary opinions.
4. RESULTS
In this section, we present the results of our study regarding the
utility of formal routines as a medium for transfer of knowledge
and experience. The focus is on participation and potential
differences in opinion between developers and managers
regarding the utility of the routines.
4.1 Knowledge of the Routines
All respondents had a fairly good knowledge of the routines that
were in place in their respective companies. In fact, two thirds of
the respondents showed good knowledge about the content of the
routines. Table 1 illustrates this, and shows how well developers
and managers were able to describe the specific contents of the
routines in their company.

Table

1. Knowledge of company routines.
Software developers Managers
Frequency Percent Frequency Percent
Little -
Some 646220
Much 754880
However, when it came to knowledge about how the routines
were introduced, 50% of the developers did not know anything
about this process. On the other hand, only one manager did not
know about the introduction process. All in all, it turned out that
about 30% of the developers and 70% of the managers had
actively participated in the introduction of routines (Table 2).

Table

2. Degree of involvement during introduction of
routines.
Degree of involvement
Low High
Freq. Percent Freq. Percent
Developers 969431
Managers 330770
Furthermore, it seemed to be a common understanding regarding
the objective of having formal routines. Most respondents said
that such routines were useful with respect to quality assurance.
Other respondents said that they would enable a more unified way
of working. However they emphasized that:
Routines should not be formalistic, but rather useful and
necessary.
Respondents in the three ISO-9001 certified companies claimed
that their routines were first and foremost established to get the
certificate on the wall, and that the quality of their software
processes had gained little or nothing from the ISO certification.
One of the respondents expressed his views on this by the
following example:
You might be ISO certified to produce lifebelts in concrete,
as long as you put the exact same amount of concrete in each
lifebelt.
Although some of the respondents were critical to the routines,
stating that:
10% of the routines are useful, while the remaining 90% is
nonsense
Most respondents, nevertheless, had a good impression of the
routines, typically stating that:
Routines are a prerequisite for internal collaboration.
Routines are a reassurance and of great help.
4.2 Use of Routines
Software developers and managers agreed on the degree to which
the routines were used. In general, they answered that about 50%
of the routines were in use, and that the more experienced
developers used the routines to a lesser extent than the more
inexperienced developers do. Furthermore, it was a common
agreement that:
There is no point in having routines that are not considered
useful.
However, the status of the routines among the software developers
was highly divergent, as seen from the following statements:
The routines are generally good and useful, but some
developers are frustrated regarding their use.
The system is bureaucratic - it was better before, when we
had more freedom to decide for ourselves what should best be
done.
The routines are easy to use.
Routines are uninteresting and revision meetings are
boring.
4.3 Updating of Routines
None of the companies had scheduled revisions as part of the
process for updating their routines. Most answers to this issue
were rather vague. Some respondents explained that such
revisions were informally triggered, while other respondents did
not know how to propose and implement changes to existing
routines.
However, respondents from all of the companies, both managers
and software developers, said that all employees in their
respective companies could participate in the revision activities if
they wanted to.
4.4 Routines as a Medium for Transfer of
Knowledge and Experience
The answers to this issue varied a lot, and indicated highly
different attitudes regarding the effectiveness of formal routines
for knowledge and experience transfer. Particularly, it seemed to
be a clear difference in judgment between software developers
and managers. While seven of the ten managers regarded written
routines as an efficient medium for knowledge transfer, none of
the developers did! Furthermore, half of the developers considered
such routines to be inefficient for knowledge transfer, while only
one of the managers shared this view.
Typically, managers said that written routines were important as
means for replacing the knowledge of the people that had left the
company. Software developers, on the other hand, did not make
such a clear connection between experience, knowledge transfer
and formal routines. One software developer said that different
groups within the company never read each other's reports, while
another developer maintained that it would take too much time to
learn about the experience of the other groups. Several of the
developers explained their views by stating that the
documentation was not good enough, it was hard to find, boring to
use and that it takes too much time.
When asked about useful alternatives to written routines, the
respondents answered that they regarded some kind of
Experience base or Newsgroup as the highest ranked
alternative. Other high-ranked alternatives were Socialization,
Discussion groups, Experience reports, Group meetings,
and On-the-job training. Table 3 shows these alternatives in
rank order (1 is best) for software developers and managers
respectively.
We also asked the respondents about what they regarded as the
most important barriers against transfer of knowledge and
experience. Nearly all of them said that such transfer, first and
foremost, is a personal matter depending on how much each
individual whishes to teach their lessons-learned to others.
Furthermore, the willingness to share depends on available time,
personality, self-interest, and company culture.

Table

3. Alternative media for knowledge transfer.
Rank
Medium Developers Managers
Experience base/newsgroups 1 1
Socialization
Discussion groups 3 2
Experience reports 4 3
On-the-job-training 5 6
Work with ext. consultants 6 -
Group meetings 7 5
As shown in Table 4, seven (six developers and one manager) of
the 23 respondents answered a definite No to the question
regarding the efficiency of written routines as a medium for
transfer of knowledge and experience. Likewise, seven
respondents (managers only) answered an equally clear Yes to
the same question. The last nine respondents answered somewhere
in between, and said that in some cases written routines could be
effective, while in other situations they would rather be a barrier.

Table

4. Do you regard written routines as an efficient
medium for transfer of knowledge and experience?
Software developers Managers
Frequency Percent Frequency Percent
Both 754220
Due to the rather small sample size in this study, and the low
expected frequency in several of the cells in Table 4, we
compared the respondents' assessments of the routines and their
job function using Fisher's exact probability test. With this test,
the exact probability (or significance level) that the obtained result
is purely a product of chance is calculated [23]. The test statistic
of 13.02 was highly significant (p=0.002, two-tailed). Thus, we
rejected the hypothesis of independence and concluded that there
is a difference in the distribution of assessment of the usefulness
of formal routines as an efficient medium for transfer of
knowledge and experience between software developers and
managers.
Since software developers had been involved in the process of
introducing the routines to a much lesser extent than the
managers, we compared the respondent's assessment of the
routines with the level of involvement using Fisher's exact test

Table

5). The test statistic of 14.71 was highly significant
(p<0.0005, two-tailed). Thus, we concluded that there is a
difference in the assessment of the usefulness of formal routines
as an efficient medium for transfer of knowledge and experience
with respect to the degree of involvement in the introduction
process.

Table

5. Degree of involvement vs. assessment of formal routinized solutions that often ignore the social realities of the
routines as an efficient medium for transfer of knowledge and workplace, see work by Kunda [24] and Thomas [38].
experience.
Against this background, we can more easily understand the
Degree of involvement preference of formal routines within the SPI community as
espoused by quality managers or members of Software
Efficient medium? Low High
Engineering Process Groups (SEPGs). Likewise, managers will
-7rather put emphasis on rules, procedures, and instructions than on
dialog, discussion and employee participation.
Both 54
software development is radically different from
manufacturing. The former is not a mechanical process with
strong causal models, where we just need to establish the right
formal routines. Rather, the developers view software
5. DISCUSSION development largely as an intellectual and social activity.
In this section, we restrict the discussion to possible explanations Therefore, we cannot apply a rationalistic, linear model to
of why none of the software developers in our study regarded software engineering. We should admit that reality for most
formal routines as an efficient medium for transfer of knowledge software organizations is a non-deterministic, multi-directional
and experience. The reason for this is that we regard formalization flux that involves constant negotiation and renegotiation among
and participation as important issues for the relevance of much of and between the social groups shaping the software [17].
the SPI work done today by both researchers and practitioners.
This does not mean that we should discard discipline and
The respondents in the study were software engineers and formalization altogether. What is needed, is to balance the odd
managers with an engineering background. Furthermore, software couple of discipline and creativity in software development [21].
and quality managers with an engineering background wrote most This balance can be challenging, since losing sight of the creative,
of the routines. Thus, the routines were for a large part written by design-intense nature of software work leads to stifling rigidity,
engineers - for engineers. Still, there was a highly significant while losing sight of the need for discipline leads to chaos.
difference in attitudes regarding the usefulness of the routines for
This leads us to the second possible reason for the divergent
transferring knowledge and experience between software
attitudes between developer and managers; that of employee
engineers and managers.
participation around formal routines.
As seen from our point of view, there are three main reasons for
the observed diversity regarding the assessment of the efficiency 5.2 Participation
of routines. One is the potential conflict between the occupational
Employee participation, and the way people are treated, has been
cultures of software developers and managers. The second reason
noted as a crucial factor in organizational management and
has to do with the degree of developer participation in developing
development ever since the famous productivity studies at
and introducing the routines. The third explanation has to do with
Western Electric's Hawthorne plant in the 1920s. The results of
the views of working and learning and thus, the ability of written
these studies started a revolution in management thinking,
routines in general to transfer human knowledge and experience.
showing that even routine jobs can be improved if the workers are
These reasons are discussed in 5.1-5.3 below.
treated with respect.
5.1 Occupational Culture Interestingly our study shows, that not only did managers
participate significantly more during the introduction of routines,
There was a general agreement among all respondents that the
but also during the actual development of the routines. However,
intention of introducing formal routines was to contribute to an
no one is more expert in the realities of a software company's
efficient process of developing quality software. In other words,
business than the software developers themselves. They are not
the intention behind the formal routines was to provide
only experts on how to do the work - they are also the experts on
appropriate methods and techniques, and standardize work
how to improve it. Thus, the developers are a software
processes needed to solve the problems at hand.
organization's most important source of productivity and profits -
The differences we observed in attitude to the efficiency of formal the human capital view. It is therefore important to involve all
routines between software developers and managers has close the people that take part in a problem or its solution, and have
resemblance to the lack of alignment among executives, decisions made by these. In this respect, all of the companies
engineers, and operators described by Schein [34]. He explained violated one of the most important aspects of employee
these differences from a cultural perspective, defining culture as involvement on their own work environment. They may even
a set of basic tacit assumptions about how the world is and ought have violated the Norwegian work environment legislation!
to be, that a group of people share and that determines their
Formalization is a central feature of Weber's [39] bureaucratic
perceptions, thoughts, feelings, and, to some degree, their overt
ideal type. Viewed in the light of our results, it is not surprising
behavior (ibid., p. 11). Schein claimed that major occupational
that research on formalization often presents conflicting empirical
communities do not really understand each other, and that this
findings regarding its efficiency. Adler and Borys [2] explained
leads to failures in organizational learning. According to Schein,
this divergence by saying that prior research has focused on
the engineering culture and the executive culture has a common
different degrees of formalization, and has paid insufficient
preference to see people as impersonal resources that generate
attention to different types of formalization. They emphasize an
problems rather than solutions. Furthermore, the engineers' need
enabling type of formalization, where procedures provide
to do real engineering will drive them toward simplicity and
organizational memory as a resource to capture lessons-learned or
best practice. The opposite is the coercive type of formalization,
where procedures are presented without a motivating rationale and
thus tend to be disobeyed, resulting in a non-compliant process.
Our results regarding the developers' assessment of the routines
closely resemble the coercive type of formalization. The
developers are clearly not against formal routines. In fact, they
expressed views in favor of such routines, especially those that
captured prior project experience. Contrary to the existing
routines, which they deemed coercive, they wanted routines of the
enabling type of formalization. Thus, the highest ranked
alternative to formal routines was some sort of experience base
or newsgroup.
5.3 Working and Learning
Another aspect of our results is that they support Brown and
Duguid's [10] perspective on learning-in-working. That is, we
should emphasize informal, as opposed to formal learning. The
same authors referred to these learning modes, respectively, as
non-canonical and canonical practices. They suggested that
training and socialization processes are likely to be ineffective if
based on canonical practice, instead of the more realistic non-canonical
practice:
People are typically viewed as performing their jobs
according to formal job descriptions, despite the fact that
daily evidence points to the contrary. They are held
accountable to the map, not to road conditions. (ibid., p. 42)
Thus, formal routines alone are inadequate, and might very well
demand more improvisational skills among developers. This is
because of the rigidities of the routines, and the fact that they do
not reflect actual experience [17]. Although many routines are
prescriptive and simple, they are still hard to change, and they
cannot help in all the complex situations of actual practice from
which they are abstracted.
It is not surprising, therefore, that socialization and discussion
groups were among the highest ranked alternatives to formal
routines. This is also in agreement with Brown and Duguid's
finding that story-telling is of utmost importance for dealing
with the complexities of day-to-day practice. Furthermore these
authors highlighted story telling as a means of diagnosing
problems and as shared repositories of accumulated wisdom. This
is similar to Zuboff's [40] emphasis on story-telling to deal with
smart machines, and to Greenwood and Levin's [22] use of
narratives in action research. Thus, contrary to the rigidities of
formal routines, stories and the tacit social activities are seen as
more flexible, adaptable and relevant by the software developers
in our study.
Furthermore, our results support the assertion that significant
learning should not be divorced from its specific context - so-called
situated learning. Therefore, any routines, generalizations
or other means that strip away context should be examined with
caution. Indeed, it seems that learning could be regarded as a
product of a community i.e. organizational learning, rather than of
the individual in it. Thus lessons-learned cannot easily be
transferred from one setting to another, see Lave and Wenger [25].
5.4 Implications
Although the study is limited, the discussion above suggests
several implications. First, studies of the effects of formalization,
whether they are enabling or coercive, should focus on the
features of the actual routines as well as their implementation. In
addition, we should pay attention to the process of designing the
features and the goals that govern this process.
Second, we must recognize and confront the implications of the
deeply embedded and tacit assumptions of the different
occupational cultures. And, furthermore, learn how to establish
better cross-cultural dialogues in order to enable organizational
learning and SPI.
Third, a major practical implication is that managers should
recognize the needs of balancing discipline and creativity, in
order to supplement formal routines with collaborative, social
processes. Only by a deep and honest appreciation of this, can
managers expect effective dissemination of knowledge and
experience within their organization.
Based on the findings of this study, we conclude that both
software managers and developers must maintain an open
dialogue regarding the utility of formal routines. Such a dialogue
will open the way for empirically based learning and SPI, and thus
attain the rewards of an enabling type of formalization.
5.5 Limitations and Recommendations for
Future Research
This study focused on the utility of formal routines to transfer
knowledge and experience. Although it can provide valuable
insights for introduction of formal routines in the software
industry, our study is not without limitations.
First, the small sample and lack of randomness in the choice of
respondents may be a threat to external validity. In general, most
work on SPI suffers from non-representative participation, since
companies that voluntarily engage in systematic improvement
activities must be assumed to be better-than-average.
Second, a major threat to internal validity is that we have not
assessed the reliability of our measures. Variables such as degree
of involvement and efficiency of routines are measured on a
subjective ordinal scale. An important issue for future studies is
therefore to ensure reliability and validity of all measures used,
see [18]. We may also ask if the respondents were truthful in their
answers. For instance, they may have sensed we were looking for
trouble, and thus giving us what we wanted - i.e. exaggerating
possible problems. However, their answers to the four main
questions and their added qualitative comments show a consistent
picture of skepticism and lack of participation concerning formal
routines. We therefore choose to generally believe their answers.
Despite the mentioned limitations and lack of cross-checks, we
feel that this study makes an important contribution to the
understanding of formal routines and their role in organizational
learning and SPI.
Future studies should examine the enabling features of formal
routines in much more detail. The features could be refined and
operationalized and used for cross-sectional and longitudinal
studies of a much larger number of companies. Furthermore, such
studies should include a multiple respondent approach to cover all
major occupational cultures. They should also perform
supplementary, ethnographic studies on how developers really
work and how their work relate to formal routines - see [31] on
observational studies of developers at ATT.
6. CONCLUSION
Results from the survey reported in this paper show that software
developers do not perceive formal routines alone as an efficient
way to transfer knowledge and experience. Furthermore, the study
confirms our suspicions about large differences in perception of
the utility of formal routines to transfer experiences and
knowledge. That is, developers are skeptical to adopt formal
routines found in traditional quality systems. They also want that
such routines are introduced and updated in a more cooperative
manner.
These results are not revolutionary and in line with many other
investigations on similar themes [2], [24], [34]. See also Parnas
and Clements' article [29] on how to fake a rational design
process. So in spite of a small sample, we think that the results are
representative for a large class of software companies.
The remedy seems to create a more cooperative and open work
atmosphere, with strong developer participation in designing and
promoting future quality systems. The developers also seem open
to start exploiting new electronic media as a means for
collaboration and linking to newer SEB technologies - see also
our previous studies [13] on this. However, the major and most
difficult work remains non-technical, that is, to build a learning
organization.
Lastly, we were not able to make precise hypotheses on our four
issues beforehand, so the study has a character of a preliminary
investigation. Later studies may be undertaken with more precise
hypotheses and on a larger sample.
7.

ACKNOWLEDGEMENTS

Thanks to colleagues in the SPIQ project, to colleagues at NTNU
and SINTEF, and not at least to the students Jon E. Carlsen and
Marius Fornss that did the fieldwork.
8.


--R



Wolfgang M







Carlsen and Marius Forn


"Software Experience Bases: A Consolidated Evaluation and Status Report"
Out of the crisis
Tore Dyb
Tore Dyb
Tore Dyb
ESSI project office
Chapter on

Introduction to Action Research: Social Research for Social Change

Control and Commitment in a High-Tech Corporation
Legitimate Peripheral Participation
Marciniak, editor, Encyclopedia of Software Engineering - 2 Volume <Volume>Set</Volume>
The Knowledge-Creating Company


The Capability Maturity Model for Software: Guidelines for Improving the Software Process


"Discipline of Market Leaders and Other Accelerators to Measurement"

The Fifth Discipline: The Art and Practice of the Learning Organization


What Machines Can't Do
Makt og byr
In the Age of the Smart Machine
--TR
A rational design process: How and why to fake it
In the age of the smart machine: the future of work and power
Encyclopedia of software engineering
People, Organizations, and Process Improvement
Software creativity
The capability maturity model
An ISO 9000 approach to building quality software
From data mining to knowledge discovery
Reexamining organizational memory
An Instrument for Measuring the Key Factors of Success in Software Process Improvement
Evaluating software engineering standards
Improvisation in Small Software Organizations
Software Experience Bases
<I>Coda</I>

--CTR
Tore Dyb, Enabling Software Process Improvement: An Investigation of the Importance of Organizational Issues, Empirical Software Engineering, v.7 n.4, p.387-390, December 2002
Reidar Conradi , Alfonso Fuggetta, Improving Software Process Improvement, IEEE Software, v.19 n.4, p.92-99, July 2002
Tore Dyba, An Empirical Investigation of the Key Factors for Success in Software Process Improvement, IEEE Transactions on Software Engineering, v.31 n.5, p.410-424, May 2005
knowledge transfer;software process improvement;knowledge management;formal routines;developer attitudes