Project management process models as antecedents for job satisfaction

Abstract

This study analyzes conceptual differences between two well-known software development models, Scrum and Waterfall (e.g. agile, and non-agile) as a foundation to compare employee job satisfaction. Current research supports the general claim that agile software development processes are related to higher job satisfaction than non-agile processes. Hypotheses proposing differences in five aspects of job satisfaction (creativity, job security, social status, authority, and responsibility) between the two process models are empirically tested. A sample of 52 software professionals experienced with both process models was collected for this study. Results show that even though the general perception of Scrum is positive, a more differentiated analysis of satisfaction with responsibility, job security, and social status does not offer the same definite answer. Results show that managers are significantly more satisfied with their authority in Waterfall than in Scrum. This highlights the need for differentiated theoretical arguments regarding project management process structures and their influence on various performance criteria.

Keywords: Project process model, Scrum, Waterfall, Job satisfaction

Introduction

The practice of software development makes use of several competing process models to assure efficient and effective software creation and implementation. The most common process models are Waterfall and Agile. The Scrum model is the most popular implementation of agile. West, Grant, Gerush, & D’Silva, (2010) survey shows that, until 2009, 10.9% of the responding organizations adopted Waterfall in their project and 8.4% adopted Scrum. The Waterfall model entails a sequential process structure laying out the different steps for development and stresses the importance of requirements, which are necessary to clarify project goals (Hass, 2007). The main critique is that the model is inflexible when changes or adjustments of the initial requirements are necessary. The relatively new agile models promise to improve upon the Waterfall shortcoming and are gaining more and more popularity. Agile process models present advantages such as providing higher productivity (Cardozo, Neto, Barza, França, & Silva, 2010) and efficiency (Dingsøyr, Nerur, Balijepally, & Moe, 2012; Li, Moe, & Dyba, 2010; Lindvall, Basili, Boehm, Costa, Dangle, Shull, & Zelkowitz, 2002).

Besides improvements in the outcomes it is widely assumed that agile process models lead to higher employee satisfaction. This assumption is supported by Melnik and Maurer’s (2006) comparative analysis of job satisfaction with agile and non-agile process models. Their results show that twice as many software development team members who are using agile models are satisfied with their jobs versus members using non-agile models. Job satisfaction has been proved to be an important predictor of job performance (Judge, Thoresen, Bono, & Patton, 2001), and organizational outcomes (McFarlin & Sweeney, 1992), and employee voluntary turnover rate (Lambert, Lynne Hogan, & Parton, 2001; Mobley, Griffeth, & Hand, 1979; Price & Mueller, 1986; Williams & Hazer, 1986).

Past research has been instrumental in shedding light on the relation between the employee job satisfaction and different process models but only few studies focus on the Scrum and Waterfall model (Mannaro, Melis, & Marchesi, 2004; Moe, Dingsøyr, & Dybå, 2010). However, these studies do not explore the conceptual differences between Waterfall and Scrum and how they are related to different aspects of employee job satisfaction. However, these differences are key to a better understanding of how job satisfaction is affected. Relying only on general statements about the satisfaction with a specific process model could lead to insufficient conclusions about the choice and implementation of a specific process model, e.g. it is not clear how the structural changes that come along with the Scrum model and their consequences for the leadership roles are related to the job satisfaction of project managers and other managerial positions. A differentiated analysis will also contribute to the theoretical discussions of project management structures and their consequences for outcomes. So far the literature mainly focuses on contingencies and management processes and their impact on project outcomes but consequences of alternative project management structures are rarely addressed.

The structure of our study follows the goal, question, metric (GQM) paradigm (Basili, 1993). Our goals in this research are to reveal how the conceptual differences between the Waterfall and Scrum model are related to job satisfaction. Secondly, we will analyze empirically whether the employee job satisfaction differs between different roles under the Waterfall and Scrum model. Table 1 provides a summary of the GQM approach of this study.

Table 1. GQM approach

Basic Definitions of Waterfall and Scrum Process Models

The Waterfall model is characterized by linear progression of discrete, consecutive process steps (Bullinger, Fähnrich, & Meiren, 2003). Basic assumptions of the Waterfall model are the following (Ktata & Lévesque, 2009):

• Project requirements are set and fully evolved before the project starts
• No revisit phases
• Stable context

In the Waterfall model, fully stated specifications and requirements are required before the planning starts. And design, development, testing, and deployment are performed in order. Once a phase is completed, it will not be revisited unless that phase fails inspection, review, or testing. This model also assumes that the development environment does not change much before the project is completed. However, clients usually find it quite difficult to completely define all requirements at the beginning of the project. Because of limitations like this, some researchers even pointed, “the Waterfall model is dead” (Boehm, 1988, p. 61).

Agile is a group of process models based on iterative and incremental development to develop software through collaboration between self-managing cross-functional teams (Conboy & Fitzgerrald, 2004; Fowler & Highsmith, 2001). The Scrum model is the most popular implementation of agile models (West et al., 2010). Basic assumptions of Scrum based on past literature can be summarized:

• Requirements always evolve due to the technology changes, customer’s need changes, and etc. (Turk, France, & Rumpe, 2005)
• Iterative project development processes (Schwaber, 1995)

The flexible, lightweight, and iterative process enables Scrum to embrace changes and survive in an unpredictable environment. Customers don’t need to worry about the disadvantages that requirement changes bring to projects. This is one of the major reasons why Scrum is gaining popularity in the rapidly changing and developing software industry.

The Scrum life-cycle model is composed of five distinct Scrum activities: the kickoff, the sprint planning meeting, the sprint, the daily Scrum, and the sprint review meeting (Cervone, 2011; Schwaber, 2010; Schwaber & Beedle 2002). These five activities are briefly introduced below. Figure1 presents the Scrum life-cycle model.

• The kickoff is a meeting in which the product owner defines and introduces the high-level backlog and the major project goals to the Scrum team and Scrum Master.
• The Sprint planning meeting takes place at the beginning of each Sprint. In the first part of the meeting, the product owner presents and discusses the product backlog (a prioritized requirements list for the project) with the Scrum team (the Scrum Master is considered as a member of the Scrum team). In the second part, the Scrum team determines the sprint goal, and creates the sprint backlog.
• The sprint is an iteration cycle of two to four weeks in which the functionality of the product is further developed. The product development processes such as development, testing, and adjustment happen in the sprint phase in an unpredictable and uncontrolled way (Schwaber, 1995).
• The daily Scrum is a meeting, which is held by the Scrum Master every day for less than 15 minutes, aimed at tracking the progress of project, improving communications between the Scrum team members.
• The Sprint review meeting is held at the end of each sprint, in which the Scrum team demonstrates the product to the product owner.

Conceptual Differences Between Waterfall and Scrum Process Models

In the next section, we will compare conceptual differences between the Waterfall and Scrum model in the following perspectives:

• Planning perspective

• Execution and Monitoring & Controlling perspective
• Role perspective
• Project context perspective

Planning Perspective

According to A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) – Fifth Edition, Planning, Execution, Monitoring and Controlling are the core project management processes. Figure 2 compares the basic software development phases of the Waterfall and the Scrum model to project management processes (D. Fernandez & J. Fernandez’s, 2008).

The planning process in the Waterfall model occurs up front, at the beginning of each project. The detailed planning phase consumes a considerable amount of time. A significant amount of requirements documentations are produced in this phase (Boehm, 1988; Hass, 2007). The plan developed in the planning phase applies to the entire project. The work breakdown structure (WBS) is an important planning tool, which breaks a project down into subprojects, tasks, subtasks, working packages, and so forth (Tausworthe, 1980). It is a must for the Waterfall model to structure the whole project, provide foundations for time and cost estimating, and monitor project status (Koskela & Howell, 2001 and 2002; PMI, 2013).

Figure 1: Scrum life-cycle

The planning in the Scrum model occurs in every Sprint based on the refined product backlog. Detailed plan for each Sprint will only be made in the Sprint planning meeting by Scrum teams (Cervone, 2011). This also helps to avoid problems that plan changes bring during the project development. The project duration and cost will not be settled in planning process and will change during the project implementation.

In the Scrum model, three artifacts together fulfill the function of the WBS. They are the product backlog, the Sprint backlog, and burn down chart. The product backlog is a prioritized requirements list for the project. The Sprint backlog is the subset of product backlog items, which are defined as the work for a particular Sprint (Figure 1). The burn down chart is a detailed tasks list to instruct how many tasks need to be done and depict the total backlog hours remaining in the Sprint. Even though the three artifacts of Scrum accomplish the function of the WBS, there are still some differences between the WBS and Scrum artifacts. First, the WBS seldom changes during the project, but the product backlog needs to be updated continuously by the product owner. Secondly, unlike Waterfall, the cost and duration estimation in Scrum is only accurate in the current Sprint based on the Sprint backlog and burn down chart (Cervone, 2011).

Figure 2: Compare project management processes to software development phases of Waterfall and Scrum

Execution and Monitoring & Controlling Perspective

In the Waterfall model, the project development phases are performed in a linear finish-to-start sequence (Boehm, 1988; Schwaber, 1995; Boehm & Turner, 2003). Once a phase is finished, it will not be revisited. Formal information distribution methods are utilized, such as emails. Project managers are responsible for the decision-making. Team members develop the product by following project managers’ command and control.

In the Scrum model, functions of the product are developed incrementally through Sprints (Schwaber, 1995). The daily Scrum meeting helps control the progress of the project. Contrary to the Waterfall model, Scrum mainly relies on the informal face-to-face communication to distribute information. Face-to-face communication is a richer media than any type of former computer based communication (Barkhi & Pirkul, 1999). Also face-to-face communication helps to reduce the cost of moving information from people to people, to improve communication efficiency, and to contribute quicker responses to the environment (Barkhi & Pirkul, 1999). Command and control is substituted by cooperation and collaboration between members. The Scrum team is entitled to make technical decisions without the involvement of management.

Role Perspective

In projects that use the Waterfall model, there are two major roles, project managers and team members. Teams in the Waterfall model are manager-led teams, in which project managers divide projects into segments and assign them to relevant functional individuals (Larson & Gobeli, 1989). Therefore, team members are responsible only for the execution of assigned work (Hackman, 1987).

Scrum implements the iterative, incremental practices through three roles: the product owner, the Scrum Master, and the Scrum team. The product owner is a functional unit manager who is responsible for representing the interests of all parties in the project and its resulting product. Only the product owner is responsible for managing and controlling the product backlog. The Scrum Master is a new management role, whose major role is to enable the Scrum practices and processes (Cervone, 2011). The Scrum Master is also a member of the Scrum team. Besides enabling the Scrum practices and processes, the Scrum Master also needs to participate in the development process like the other Scrum team members. The team leader, or project leader, often assumes the Scrum Master role. In some industry practice, Scrum team members could also take turns to become the Scrum Master. The Scrum team typically is a self-managing team consisting of five to ten people who work on the project in the same location. The team is responsible for developing products by following the product backlog and Spring backlog. In the self-managing Scrum teams, leadership role within the team is not fixed, and team members take on responsibilities to regulate tasks by themselves (Cohen, Ledford, & Spreitzer, 1996). Teamwork is exclusively important for the success of the project. Managers have to relinquish some of their authorities to the Scrum team. The agility self-managing teams need to have a common focus, mutual trust, and be in charge of the collaborative decision-making process (Cockburn & Highsmith, 2001).

Project Context Perspective

In the current industry, software technologies are frequently and rapidly evolving. In such an unstable and flexible environment, it is quite hard for customers to fully state requirements at the beginning of projects. However, the Waterfall model is built based on the assumption of a fully developed requirements list from customers before the project development, and a relatively stable development environment. That’s one of the reasons that Waterfall has been losing popularity in software development projects.

In the Scrum model, functions of the project are developed incrementally through each Sprint, and a detailed plan is only made for the current Sprint. Therefore, changes in plan, including requirement changes or technology updates, can be easily applied and do not interrupt the current functions development. Thus, the plan changes are welcomed as opportunities to satisfy customers’ needs and improve the product (Turk et al., 2005). Therefore, the Scrum model is more likely to be applied in an uncertain, unpredictable, flexible environment.

Hypothesis Development

Based on the comparison between the Waterfall and Scrum model from four perspectives, we are proposing that the Waterfall or Scrum model is closely linked with employee job satisfaction, which is the dependent variable in our model.

Job satisfaction refers to “an overall affective orientation on the part of individuals toward work roles which they are presently occupying” (Kalleberg, 1977, p. 126). The Minnesota satisfaction questionnaire (MSQ) is a well-established questionnaire to test the employee job satisfaction, in which 20 aspects of job satisfaction are measured¹ (Weiss, Dawis, & England, 1967). The theoretical foundation of MSQ is the theory of work adjustment, which is about the relationship between the individual and his or her work environment (Dawis, Lofquist, & Weiss, 1968). Since MSQ measures satisfaction with specific aspects of work, it is feasible to obtain a more individualized picture about which aspects of work an employee is satisfied with. In this paper, we focus our research on the following 5 out of the 20 MSQ aspects: creativity, job security, social status, authority, and responsibility. These 5 aspects are selected because they are directly related to the conceptual differences between the Waterfall and Scrum model (Table 2). For the remaining MSQ aspects no significant differences between the two models are expected.

Table 2. Summarized conceptual differences between the Waterfall and Scrum model

Satisfaction with Creativity

Individual creativity is the ability to identify new ways, and to transform subjective understanding into new actions (Joas, 1996). Interactions between individuals with different attitudes are argued to facilitate innovations. And teamwork can foster interactions between individuals. Therefore, Sacchetti and Tortia (2013) indicate that satisfaction with creativity at the work place is enhanced by the teamwork. The Scrum model is characterized by teamwork and cooperation. Furthermore, this model is typically used in a highly turbulent, unpredictable, and changing software development environment, which also fosters innovation and creativity (West & Farr, 1990). However, compared with the Scrum, the Waterfall model does not contain these qualities to foster creativity. Hence, based on the indications mentioned above, the hypothesis is as follows:

Satisfaction with Job Security

Greenhalgh and Rosenblatt (1984) defined job insecurity as “perceived powerlessness to maintain desired continuity in a threatened job situation” (p. 438). Probst (2002) described job security as the perceived stability and continuance of an individual’s job as he or she knows it. For the individual, feeling insecure about the job may have detrimental effects on employee well-being and job satisfaction. Hartley, Jacobson, Klandermans, and Van Vuuren (1990) even suggested job insecurity as one of the most important stressors in the employment situation. Hence, studying the job security satisfaction will be significantly meaningful.

Probst (2003) argued that job technology changes are one of the antecedents of job insecurity. And job insecurity also causes low job security satisfaction. Therefore, there is a distinct relationship between technology changes in job and job security satisfaction. The Scrum model is frequently used in an uncertain, unpredictable, and changing environment, which requires more frequent technology updates. This unstable project environment is more likely to bring a sense of insecurity about one’s job, which is also related to low satisfaction with job security. Therefore,

Satisfaction with Social Status

The power structure in Scrum is different from Waterfall. In a self-managing team, members do not need to follow managers’ instruction and control all the time. Even though they do not get promoted, the participation in the decision-making process makes them feel more important. This virtually increases the social status of members in Scrum. We expect that people’s satisfaction level with social status is higher when they possess higher social status. Therefore:

Satisfaction with Authority

Authority involves power over someone or something. Individual’s authority plays an important role in his or her job satisfaction. There is a positive relationship between the authority a person holds and his or her job satisfaction (Bavendam, 2000). Adequate authority is an important factor that leads to job satisfaction (Muindi, 2011). Eimers (1997) demonstrated that the lack of authority in work can seriously mitigate job satisfaction in this aspect.

In the self-managing Scrum teams, managers have to relinquish their power over the project. That means managers have less authority. Since managers are not naturally willing to give up their authority (Hoda, Noble, & Marshall, 2013; Nerur, Mahapatra, & Mangalaraj, 2005), their satisfaction with authority in Scrum will decrease. On the other hand, in the self-managing Scrum team, members possess more decision-making rights than before, which gives them more power over the project. Additionally, the flexible environment requires giving the Scrum team members more authority to cope with it (Goldman, Nagel, & Preiss, 1995). In this research, we consider Scrum team members and programmers in Waterfall as “members,” product owners, Scrum Masters, project managers, and some higher management roles such as vice presidents, directors and so forth as “managers”. Therefore, based on the above analysis, the job satisfaction with authority depends on the employee’s role (members, managers) in the Waterfall and Scrum model.

Satisfaction with Responsibility

Responsibility is the individual’s liability and accountability for the job that he or she performs (Oosthuizen, 2001), and the awareness of the consequence of his or her own actions (Schwartz, 1968). Cooper, Rout, and Faragher (1989) implied that the highest level of satisfaction is reported for the amount of responsibility given in work.

Participating in the decision-making process helps individuals to develop a higher sense of responsibility, and makes them more satisfied (Asproni, 2004). According to Muindi (2011), participating in a decision-making process can help to satisfy one’s need for achievement, and provide recognition and responsibility. Therefore, the Scrum teams’ decision-making ability empowers them with more responsibilities. Relatively, managers in the Scrum model don’t need to participate in technical related decision-making process compared with the Waterfall model. Based on McGregor’s (2006) Theory Y, the average individual is not only accepting but also seeking responsibility. Thus, managers should not be satisfied when their responsibilities are taken away. Therefore, the job satisfaction with responsibility depends on the employee’s role (members, managers) in the Waterfall and Scrum model.

Research Methodology

For this paper, we employed a survey approach to study the job satisfaction differences between the Waterfall and Scrum model. The survey approach is useful in accurately documenting the norm, identifying extreme outcomes, and delineating relationships between variables in a sample (Fowler, 2009; Gable, 1994).

First, a pilot survey was conducted by sending a questionnaire to five professionals who have both Waterfall and Scrum working experience. All five responses were completed and returned to us and served as a basis to revise and improve the questionnaire. In the second step we distributed the revised questionnaire to employees of two US software companies and participants of an industry conference about software project process models in Canada. Based on the data provided by the Hofstede Centre, the 6-D data of the United States and Canada are very similar², which indicates that the US culture and Canadian culture are alike. Therefore we decided to conduct our survey in both countries the United States and Canada because they are culturally similar and can generally represent North America. We received 52 completed and qualified surveys. In order to qualify, respondents had to have both Waterfall and Scrum working experience. Since a portion of the questionnaires were sent out via a web platform, it is impossible to calculate the exact response rate.

Questionnaire Design

The questionnaire consists of three sections: role and experience background, general perception and preference, and job satisfaction.

The role and experience background questions of the first section focus on the respondent’s experience in both the Waterfall and the Scrum model. Gathering data about the respondent’s experience will help us to evaluate whether the respondent’s job satisfaction toward the Waterfall and the Scrum model is in fact a result of his or her actual experience. Figure 3 shows the respondents’ background with Waterfall and Scrum as percentage. The median of the Waterfall experience participants have is 3–5 years, and the median of the Scrum experience participants have is 1–2 years. Figure 4 shows the respondent’s role. In this study, we categorize respondents with the title of vice president, director, project manager, product owner, and Scrum Master as the “managers” group; we categorize Scrum member and programmer as the “members” group. The “others” category contains respondents from consulting, testing, and strategy departments. Over half of the respondents are from the “members” group, and around 30% of the respondents are from the “managers” group, as shown in Figure 4.

Figure 3 Respondents’ experience with Waterfall and Scrum as percentages

In the general perception and preference part, three sets of statements are presented to the respondents (Table 3, Table 4). In the general perception statements in Table 3, the respondents are asked questions about their opinions regarding the two models, such as whether they think the Scrum model is more fun to work with. A seven item Likert scale is used here, ranging from 1=Totally Disagree to 7= Totally Agree. In the preference statements in

Table 4, respondents are asked to directly answer if they prefer the Waterfall or Scrum, or have no preference.

In the job satisfaction part, 25 questions of the MSQ scales are presented to measure the employee job satisfaction with authority, creativity, responsibility, job security, and social status³. A five item Likert scale ranging from 1=Very Dissatisfied to 5= Very Satisfied is used to collect data in this part. Each job satisfaction scale consists of five equal-weighted questions. The respondents are asked job satisfaction questions twice, the first time based on their Waterfall working experience, and then based on their Scrum working experience. By collecting the job satisfaction responses for each process model separately from the same person, we could eliminate individual differences sampling error.

Figure 4 Respondents’ role.

Data Analysis Method

In this study, we utilize a Chi-squared test to analyze respondents’ preferences about the Waterfall and Scrum model. The null hypothesis states that the number of respondents who prefer Scrum is equal to the number of respondents who prefer Waterfall. Additionally, we employ a student T-test to assess whether the employee job satisfaction in the Waterfall model are significantly different from the satisfaction in the Scrum model. T-test assumes that two sets of data should be the same.

Data Analysis and Results

General Perception and Preference

The general perceptions of the Scrum and Waterfall model are captured through three sets of questions in the questionnaire. This part answers Q2 in Table 1, which is “what are the perceptions of Scrum and Waterfall? Which model is preferred?”

Table 3 presents two sets of statements and statistic and test results. As can be seen, the Waterfall model scored below “Neutral” (1=Totally Disagree, 4= Neutral, 7= Totally Agree) in both statements, and the Scrum model scores higher than the Waterfall. The T-test result also illustrates that every two sets of data are significantly different. Therefore, it can be concluded that the respondents believe that the Scrum model is more fun to work with, and it also enables lower error rate and the earlier detection of errors.

Notes: * p< 0.05, ** p<0.01

Table 3. Statistic results from general perception questions

Notes: * p< 0.05, ** p<0.01

Table 4. Statistic results from preference questions

Table 4 shows the statements and results of the preference questions. Here, the respondents are asked to choose directly from Waterfall, Scrum, and no preference. The Chi-square results show that the response distributions of both questions are indifferent (p=0.2>0.05). And significantly more respondents prefer Scrum to Waterfall (p-values of both questions are less than 0.01). Hence, the majority of the respondents prefer to work with Scrum and believe that Scrum enables better results than the Waterfall does.

Non-Role-Depended Job Satisfaction Aspects

Based on our previous analysis, the job satisfaction with creativity, job security, and social status do not depend on the employee’s role (members, managers). We calculate the mean job satisfaction and standard deviation in these three aspects and conduct the Student T-test. Results are presented in Table 5 and Figure 5. This part is in response to Q3 in Table 1.

Notes: * p< 0.05, ** p<0.01

Table 5. Statistic results of job satisfaction with creativity, job security, and social status 4.5

Figure 5 Waterfall and Scrum mean satisfaction bar plot (x represents the three aspects of job satisfaction, y represents the respondent’s mean satisfaction with 95% confidence interval)

• Creativity: H1 proposes higher satisfaction with creativity in Scrum. The result shows that the respondents’ satisfaction with creativity in Scrum is significantly higher than Waterfall (p<0.05). Therefore, H1 is supported.
• Job Security: H2 proposes that satisfaction with job security should be lower in Scrum than Waterfall. However, the respondents’ mean satisfaction with job security in Scrum is actually higher than Waterfall, according to the result. Therefore, H2 is not supported.
• Social Status: H3 proposes higher satisfaction with social status in Scrum than Waterfall. The respondents’ mean satisfaction with social status in Scrum is higher than Waterfall. However, the result is not significant (p=0.18 >0.05). Thus, H3 is not supported.

Role-Depended Job Satisfaction Aspects

As we stated before, the job satisfaction with authority and responsibility depends on the employee’s role (members, managers). Therefore, in this section, we analyze members and managers’ job satisfaction in the perspective of authority and responsibility. This part is in response to Q4 in Table 1.

Notes: * p< 0.05, ** p<0.01

Table 6. Statistic results of job satisfaction with authority and responsibility aggregated by roles

Figure 6 Scrum and Waterfall mean satisfaction by role with authority (x represents the two roles of project, y represents the respondents’ mean satisfaction with 95% Confidence Interval)

Figure 7 Scrum and Waterfall mean satisfaction by role with responsibility (x represents the two roles of project, y represents the respondents’ mean satisfaction with 95% Confidence Interval)

Figure 6 exhibits the mean satisfaction with authority aggregated by roles in the Waterfall and Scrum model. The results in Table 6 show that members feel slightly more satisfied with authority when using the Scrum. But the results are not significant (p=0.46 >0.05). Therefore, H4a is not supported. However, managers’ satisfaction level with authority is significantly lower in Scrum than Waterfall (p<0.05). Therefore, H4b is supported.

Figure 7 demonstrates the mean satisfaction with responsibility aggregated by roles in the Waterfall and Scrum model. The results show that members are more satisfied with responsibility in Scrum than Waterfall, as H5a proposed. However, the result is not significant (p=0.21 >0.05). Thus, H5a is not supported. And the managers’ satisfaction with responsibility is lower in Scrum than Waterfall, as H5b proposes. Nevertheless, the result is not significant (p=0.24 >0.05). Therefore, H5b is not supported as well.

Since H4b and H5b are all not supported by statistics results, it is still not clear whether Scrum is associated with higher satisfaction with authority and responsibility for members than Waterfall does.

Discussion

The Waterfall and Scrum are two different kinds of process models: the former is represented by a rigid and stable process sequence, and the latter is represented by an iterative and more flexible sequence of processes. After studying the conceptual differences between Waterfall and Scrum, we want to discuss some “mysteries” of the two models.

Higher Job Satisfaction in General Does Not Mean Higher Job Satisfaction in All Aspects

Melnik and Maurer (2006) indicated that agile models are related to higher job satisfaction than non-agile models. Since Scrum is an implementation of agile, we conclude that Scrum also relates to a higher job satisfaction. However, when we look into detailed aspects of job satisfaction, the relation may not stand. Out of the seven hypotheses proposing differences in the job satisfaction between the two models, only two are supported. Therefore, even though Scrum is favored by respondents and provides higher job satisfaction in general, the impact that Scrum has on satisfaction with responsibility, security, and social status are unclear.

Programmer-Oriented vs. Manager-Centric

Industry practitioners believe that agile is programmer-oriented. Therefore, we expect that members should have higher job satisfaction in role-depended aspects, such as authority and responsibility, in Scrum than Waterfall. And the conceptual analysis in this study also indicates that members of Scrum teams possess more authority and responsibility compared to Waterfall. However, results show that Scrum is not significantly related to higher job satisfaction with authority and responsibility for members. This is may be because the respondents’ Scrum experience is not very long (median is 1–2 years), and they haven’t gotten used to the authority and responsibility they obtained in Scrum. Additionally, Waterfall is associated with higher satisfaction with authority for managers, compared to Scrum. This supports the point that Scrum is not a manager-centric model.

Scrum Is Not Always “Perfect”; Waterfall Is Not “Dead”

Based on our research, Scrum is a more popular process model than Waterfall. In the software industry, Scrum is in the mainstream adoption phase (Salo & Abrahamsson, 2008; West et al., 2010). And some people from software industry even predict that agile will completely overtake Waterfall by the next several decades.

Although moving from a hierarchical approach to a flexible collaborative approach is the global trend in software corporations, Waterfall is still a very important process model in managing software projects. Waterfall provides the basis for most government software standards. In small software projects where requirements can be fully stated, Waterfall is still the most efficient way to proceed. Besides, Waterfall is optimal to develop some classes of software, for example, compilers, secure operating systems, and information systems (Boehm, 1988). In this study, Waterfall also presents a merit by providing higher satisfaction with authority for managers.

Moreover, outsourcing plays an important role in today’s software industry. It is common now that software companies outsource some function packages to third party contractors. Companies in industries other than software even offshore outsource their IT department to low-wage countries in order to cut cost. In the Waterfall model, software development teams can work by themselves once the requirements have been completely documented. Hence, it does not matter where the members of development team are located, thus provides the context for outsourcing. Unlike Waterfall, Scrum is a team-based process model that requires members to work in the same location in order to enhance the face-to-face communication efficiency. But this requirement also constrains Scrum from outsourcing, even though some researchers argue that with some adjustments the Scrum process could be used for distributed and even outsourced teams (Sauer, 2006; Sutherland, Viktorov, Blount, & Puntikov, 2007). However, the outsourcing they discussed is still in a very small range and has many restrictions.

What About the Applicability beyond the Software Domain?

The Waterfall model originates from the manufacturing and construction industries, where requirements of products or projects must be fully stated before the manufacture or construction process starts. Also, the development processes have to follow a certain order, otherwise they will lead to failure. Based on the iterative nature of the Scrum model, it is quite hard to extend the application to other industries. Researchers argue that construction projects can apply agile ideas to facilitate possible solutions to complex and uncertain requirements (Owen, Koskela, Henrich, & Codinhoto, 2006). However, the application is still limited in the pre-design and design phase. Therefore, the applicability of Scrum in other industry domains is still unknown.

Do Not Adopt Scrum Just Because It Is Popular

For some corporations, the motivations to adopt Scrum are not clear. Some industry practitioners even stated that they adopted Scrum because it is popular, because everyone else is using it. Even though industry reports and empirical studies are showing that Scrum is helpful in achieving better results for some corporations, we still need to fully understand the limitations and constraints, and be certain about why we need to switch to Scrum before adopting it.

Conclusion

Our research analyzed the conceptual differences between the Waterfall and Scrum model, and proposed relationships between process models and job satisfaction with seven hypotheses.

The limitations of this research are related to the empirical part. The current sample size is not very large. It only consists of 52 copies of completed and qualified questionnaires. This limits the use of different statistical procedures and the significance of the results. However, the results for the general satisfaction with both models are similar to other empirical studies, allowing us to assume that we were able to receive a representative sample.

The results of this study show that the general perception of Scrum is positive. Employees prefer to work with Scrum rather than Waterfall. And compared with Waterfall, Scrum is associated with higher satisfaction with creativity. However, among the seven hypotheses we proposed, only two hypotheses are supported with statistical significance at p<0.05. This means that even though some studies proved that agile is related to higher general job satisfaction, the relationship between Scrum and satisfaction with responsibility, job security, and social status is still not well understood. In addition, we find that managers are significantly more satisfied with authority in Waterfall than in Scrum. This also supports the point that Scrum is not a manager-centric model. Lastly, both Scrum and Waterfall have their own special home groundings in which one works the best, whereas the other has difficulties. Thus practitioners need to understand which model works best for them rather than follow others and adopt the popular one.

The results suggest some directions for future research. The satisfaction differences between the Waterfall and the Scrum model demonstrate the need to better understand the underlying process structures of projects. The process types and their sequences seem to play an important role for the project outcomes. We identified in this study the conceptual differences between the Scrum and the Waterfall model that could serve as a starting point to analyze contingencies of project process structures and help to develop managerial decision models for choosing the most appropriate structure under a given set of contingencies. This discussion would directly support the effort to develop a contingency theory for project management models.