|
Article Excerpt
1. Introduction
Although software systems are critical to almost every aspect of modern life, systems development projects are frequently behind schedule and over budget (Wastell 1999). It is striking that these problems have persisted despite automated tools, advances in programming languages and methods, and formal education and training in computer science and information systems (Brooks 1995). One may argue that such advances are not sufficient to improve the rate of successful systems development. Rather, software projects remain susceptible to failures because organizational members fail to learn from their own experience (Lyytinen and Robey 1999). Learning is crucial to the success of systems development (Wastell 1999). A learning perspective highlights the importance of considering systems development as a recurring process and encourages investment in building long-term capabilities.
In this study, we adopt the learning-curve approach to investigate the extent to which individuals, groups, and organizational units engaged in software development actually learn from their experience. Further, we consider what types of experience maximize learning rates. The organizational learning curve has been the subject of extensive study in many fields and several industries (Argote et al. 1990). The basic principle underlying the learning curve is that production experience creates a growing stock of knowledge that can be applied to improve the productivity of the organization (Argote 1999). The learning curve focuses on examining how organizations learn to work more efficiently.
Prior research has examined learning curves in manufacturing (e.g., Argote et al. 1990) and service industries (e.g., Pisano et al. 2001, Reagans et al. 2005). As industrial organizations become knowledge-based organizations, it is important to examine whether the advantages of experience evident in manufacturing tasks can be achieved in knowledge work. The learning curve assumes that as a worker performs a task repeatedly (such as in manufacturing and assembly operations, or in the making of pizzas (Darr et al. 1995)), the direct labor requirements to complete a subsequent unit of the task decline. Unlike manufacturing tasks, which are often repetitive (Argote 1999), or service work, which is frequently scripted, knowledge work entails less routinization and often requires problem solving. Compared to more unstructured forms of knowledge work like research or design, however, systems development is more routine and structured, as it makes use of methodologies and rules. Nevertheless, systems development is a knowledge-intensive activity that requires a considerable amount of abstract, technical, theoretical, and experiential knowledge (Sacks 1994). Although each systems development project is different and customized to the requirements of users (Basili and Caldiera 1995), developers can gain practice with each project and can construct intellectual schemas based on their technical and experiential understanding of software development tasks (Sacks 1994). Thus, there is some potential for experience-based learning in software
development, although the extent of that learning is unknown.
Our study contributes to the software development literature by determining how learning from experience affects software development productivity for individuals, groups, and organizational units. It is important to understand the role that experience plays in software development because the largest component of software costs is for labor, i.e., the developers. Thus, insights into the productivity impacts of experience-based learning in software development have implications for how much managers should value the experience of software developers, and the extent to which managers should factor in the learning curve in project planning.
Our study also contributes to the learning-curve literature by examining learning at multiple levels of analysis. Learning from prior experience can occur at different levels of analysis within a software development organization. Although learning curves have been found to exist at the individual, group, organizational, and industry levels of analysis (Argote 1999), prior studies have not considered learning at several levels of analysis simultaneously. It is important to make this consideration because many organizational activities inherently involve multiple levels of analysis (Hofmann 1997). Further, learning processes can differ across levels (Crossan et al. 1999), and the types of experience and their impacts on productivity can also differ at different levels.
Finally, our study contributes to the organizational learning literature by examining which kinds of experience best facilitate the learning of individuals, groups, and organizational units. In particular, we investigate if developers maximize their learning by specializing in a specific system, or by diversifying their experience through working on other related and unrelated systems. Accumulating specialized experience creates reliability in experience, thus enabling organizations to exploit their experience, whereas diversifying experience creates variety in experience, thus enabling organizations to engage in exploration (Holmqvist 2004, March 1991). Exploration and exploitation are both essential processes for organizations, but they compete for scarce resources (Gupta et al. 2006). We thus explore the exploitation versus exploration trade-offs by examining whether individual experience can best be leveraged through specialization or diversification. In [section]2, we describe the research setting--a large systems development effort at a telecommunications firm. Then in [section]3, we develop hypotheses that posit learning from experience in systems development at the three levels of analysis: individual, group, and organizational unit. Sections 4 and 5 describe the empirical evaluation of our hypotheses and the analysis of data collected in the field study. In [section][section]6 and 7 we present and discuss the results.
2. The Research Context
To examine learning at the individual, group, and organizational-unit levels within a software organization, we conducted a field study of an organization performing large-scale systems development in the telecommunications industry. We focused on a key telecommunications software telephony product developed by the organization. The product contains several million lines of code (written in the C programming language) with over half a million updates that have added new features or modified existing features. The product includes 63 major systems and 26 smaller systems. Each system was developed by a separate organizational unit that varied in size from 30 to about 300 employees. Organizational units were located at different sites and effectively functioned like subsidiaries of the company. Within each organizational unit, developers worked as individuals or in groups. Developers were sometimes rotated across several systems so that the organization could cater to fluctuating demands for resources in different systems. Hence, many developers had experience working on more than one system.
Given the size and complexity of the product, the organization used an incremental software development process, which is commonly used in many large-scale development efforts to progressively develop, evolve, and enhance systems over time (Rajlich 2006). In an incremental process, a release is a major product upgrade that affects one or more systems, and includes new software features and modifications to existing features. Different releases are introduced to the market at different times. To manage this incremental development process, the organization used modification requests (MRs), which are similar in concept to work orders. The initial development of the first release of the product was completed as a series of MRs. Subsequently, MRs were used to add new functions or modify and repair an existing function. A set of MRs representing a significant improvement to the software then makes up a new release of the software. All MRs were formally reviewed by a change committee before being approved and assigned to individuals or groups.
3. Theory and Hypotheses
In completing a release, work and learning can occur at multiple levels in the organization, thus allowing us to differentiate between three levels of analysis. At the individual level, developers complete individual development tasks. At the group level, teams of developers complete tasks that are interdependent. At the organizational-unit level, tasks performed by individual developers and groups of developers in the organizational unit complete the requirements for a release. In this section we develop hypotheses about how different types of experience influence productivity at the individual, group, and organizational-unit levels of analysis in systems development.
3.1. Learning from Individual Experience
Knowledge and skills are not only important inputs for software development work, but are also important outputs, because they are continuously enhanced with experience. Designing, coding, and testing of software are complex and difficult cognitive tasks that build on practical experience. As individuals accumulate experience by completing more units of work, they become more proficient in software development. We identify three types of cumulative experience acquired by individuals that are expected to affect productivity at the individual, group, and organizational levels of analysis: (1) Experience in a specific system; (2) experience in related systems; and (3) experience in unrelated systems.
Experience in a Specific System. In systems development, specialization refers to the accumulation of experience about a specific system. Specialized experience with a particular system increases developers' familiarity with the architectural domain of the system (Banker et al. 1998), including the structure of the components, files, and code within the system, and the linkages between them (Robillard 1999). In incremental systems development where new code has to be integrated with existing code, understanding the given component and its interrelations with other parts of the system is particularly important (Rajlich 2006). Developers spend a significant amount of time comprehending the source code of the system being changed or enhanced. Developers' existing knowledge of the structures of the files and components in specific systems will thus afford them with much greater efficiency in comprehending those systems and in updating, enhancing, and adding new components to the systems (Ramanujan et al. 2000).
Experience in Related and Unrelated Systems. Prior research in psychology has found that individuals can spontaneously develop a new understanding of a problem because they transfer knowledge from one domain to another: What was well understood in one problem domain suddenly provides an analogous solution to a new problem domain (Schilling et al. 2003). This transfer of knowledge may occur across domains that appear to have little in common (Simonton 1999). In systems development, developers can increase the diversity of their experience by working on a variety of related and unrelated systems. We expect developers to be able to transfer and apply the experience gained from developing one system to the development of other systems.
A key question affecting learning from experience is whether more leverage can be gained by specializing, where individuals focus on one kind of task, or by diversifying, where individuals switch between multiple kinds of tasks. Specialization allows individuals to complete more repetitions of a task within a given time, and to gain an in-depth understanding of the problem domain. An individual switching between multiple kinds of tasks--even if the tasks are related--might become distracted from learning concepts that apply only to the core task (Schilling et al. 2003). In contrast, diverse experience allows individuals to gain breadth of knowledge, which can increase their absorptive capacity, as varied prior learning improves individuals' ability to evaluate and utilize outside knowledge (Cohen and Levinthal 1990). Although developers can potentially learn from both specialized experience in one system and diverse experience in related and unrelated systems, they have limited time. Hence, there are trade-offs involved in deciding whether they should accumulate more experience in specific systems, or whether they should be working on a variety of related and unrelated systems (Gupta et al. 2006). Despite the importance of understanding the implications of this trade-off, the impact of specialization on organizational learning has received scant theoretical or empirical attention (except for Schilling et al. 2003). In the following sections, we develop hypotheses to understand the relative importance of each type of individual cumulative experience in facilitating productivity, and explore whether the relative importance differs at the individual, group, and organizational-unit levels of analysis.
3.1.1. Learning at the Individual Level of Analysis. Research in psychology has found that learning across tasks can contain two aspects: the knowledge content transfer (e.g., knowledge about the code and architecture of a system) and the learning process transfer ("learning to learn") (Schilling et al. 2003, p. 42). Learning to learn is the process by which individuals improve their ability to learn over time because they transfer their previous learning about how to apply particular kinds of information to a new problem (Ellis 1965, Schilling et al. 2003). As developers accumulate experience within a system, they can transfer both knowledge content and learning processes. We expect developers to gain the most leverage from specializing in one system as increasing familiarity with the code and architecture in the system has a direct impact...
|
