Keywords

1 Introduction

Scrum is regarded as one of the most under researched Agile methodologies [1], and the majority of research literature in this field is found to be qualitative in nature [2]. This paper focuses on quantitatively analyzing the Scrum framework for constructs and factors that are hypothesized to have a significant relationship with Scrum adoption.

A previous paper on Scrum adoption challenges focused on developing a model that can be used to test and evaluate challenges to Scrum adoption [3]. The previous paper also describes the nineteen factors that are tested in our hypotheses. To test and evaluate these adoption challenges a narrative review was conducted on the existing Agile and Scrum adoption challenges experienced globally and by practitioners in South Africa (SA) in particular. The narrative review was used to extract and synthesize the challenges. The synthesized challenges were used as the independent variables of the model. The first iteration of the Conceptual Framework (CF) is known as the Scrum Adoption Challenges Detection Model (SACDM). This CF is a custom model adapted from the Diffusion of Innovation (DOI) theory and a study of the adoption of new technology by Sultan & Chan [12].

A previous paper entitled “Factors that contribute significantly to Scrum adoption” [36] described the process behind the three iterations of the CF. The online survey questionnaire serving as a Likert-type scale, gathered response data through 78 questionnaire items. A set of 207 valid responses to this survey was used to perform Exploratory Factor Analysis (EFA) and Cronbach’s alpha analysis, which confirmed the validity and reliability of the questionnaire as the measuring instrument. The results from the correlational and Multiple Linear Regression (MLR) statistics were used to identify factors that have a significant linear relationship with Scrum adoption.

From these responses we were able to test the 19 hypotheses, and discuss the findings for each of the predicted statements.

1.1 Research Hypotheses

We collected and analyzed data to test whether the following hypotheses for the nineteen factors, could be accepted:

  • H1 - Escalation of Commitment: There is a significant linear (negative correlation) relationship between Escalation of Commitment and Scrum adoption.

  • H2 - Experience: There is a significant linear (positive correlation) relationship between Experience and Scrum adoption.

  • H3 - Over-Engineering: There is a significant linear (negative correlation) relationship between Over-Engineering and Scrum adoption.

  • H4 - Communication: There is a significant linear (positive correlation) relationship between Communication and Scrum adoption.

  • H5 - Teamwork: There is a significant linear (positive correlation) relationship between Teamwork and Scrum adoption.

  • H6 - Specialization: There is a significant linear (negative correlation) relationship between Specialization and Scrum adoption.

  • H7 - Sprint Management: There is a significant linear (positive correlation) relationship between Sprint Management and Scrum adoption.

  • H8 - Change Resistance: There is a significant linear (negative correlation) relationship between Change Resistance and Scrum adoption.

  • H9 - Training: There is a significant linear (positive correlation) relationship between Training and Scrum adoption.

  • H10 - Recognition: There is a significant linear (positive correlation) relationship between Recognition and Scrum adoption.

  • H11 - Quality: There is a significant linear (positive correlation) relationship between Quality and Scrum adoption.

  • H12 - Resources: There is a significant linear (positive correlation) relationship between Resources and Scrum adoption.

  • H13 - Collaboration: There is a significant linear (positive correlation) relationship between Collaboration and Scrum adoption.

  • H14 - Management Support: There is a significant linear (positive correlation) relationship between Management Support and Scrum adoption.

  • H15 - Organizational Culture: There is a significant linear (positive correlation) relationship between Organizational Culture and Scrum adoption.

  • H16 - Organizational Structure: There is a significant linear (negative correlation) relationship between Organizational Structure and Scrum adoption.

  • H17 - Relative Advantage: There is a significant linear (positive correlation) relationship between Relative Advantage and Scrum adoption.

  • H18 - Complexity: There is a significant linear (negative correlation) relationship between Complexity and Scrum adoption.

  • H19 - Compatibility: There is a significant linear (positive correlation) relationship between Compatibility and Scrum adoption.

1.2 Research Limitations

There is no restriction to the geolocation of the responses within SA. However, the majority of SA’s organizations and Scrum practitioners are in the provinces of Gauteng and the Western Cape. Another limitation of this study is the lack of a systematic review used to extract and synthesis adoption challenges. The narrative review results in the data being unreproducible. This study investigates Scrum adoption from the perspective of the individual Scrum practitioner perceptions, which further limits the influence of these findings on the organization’s or team’s decision to adopt Scrum. The last limitation is in the small sample size, which impact the generalizability of the research outcomes.

1.3 Research Scope

Excluded from this research, are adoption research of other Agile software development methodologies, as well as non-agile methodologies. No research was conducted outside the borders of the SA software organization, since the focus of interest is specific to the adoption factors by Scrum practitioners working in SA organizations. Within SA borders, there was no data collection from most of the nine provinces since the use of Scrum or similar methodologies occurs in provinces where such project development is most prevalent. Data collection hence mainly derived from the Gauteng and Western Cape provinces.

Implementation challenges were excluded since these challenges were considered to be beyond the scope of this research. A qualitative methodology was not used even though the respondents’ opinions were recorded. The reason for this decision was that the research focus was not on the semantics of the questionnaire responses.

1.4 Research Significance

This paper aims to make the following research contributions on Scrum adoption:

  • The use of constructs at the individual, team, organization, and technology level to identify factors that contribute significantly to Scrum adoption.

  • Based on the empirical findings, provide suggestions for future research.

The remainder of this paper comprises the following sections: Sect. 2 provides background to the topic; Sect. 3 presents the research methodology including the statistical analysis techniques used to analyze and validate the data collection instrument. The results of data collection are presented in Sect. 4 and a discussion of the research findings is provided in Sect. 5. Section 6 concludes the paper and provides recommendations for extending this work.

2 Background

2.1 Software Development Methodologies

Migrating from non-agile to Agile methodologies poses many challenges. Some of these challenges are changes in management style, communication methods, and process changes within organizations [11].

Before discussing the Agile challenges presented in current literature, a non-exhaustive list of Agile methodologies used in practice, are briefly described. These methodologies provide some contextual background for Scrum.

Adaptive Software Development.

Adaptive Software Development (ASD) was introduced by Jim Highsmith and it provides a technique to increase the success rate of developing complete, customer approved complex software and systems [18]. The cornerstones of the methodology are collaboration and team self-organization, as is evident in ASD’s adaptive life cycle. The three phases of the life cycle are speculation, collaboration and learning.

Dynamic Systems Development Method.

The Dynamic Systems Development Method (DSDM) is an Agile software development approach that does not focus primarily on system writing but instead, has a more abstract software development focus [19]. DSDM is considered to be an incremental method and is often compared to the Rapid Application Development (RAD) model which emphasizes a short development cycle [18]. DSDM follows what is termed the 80% rule, where 80% of the system is developed in 20% of the time and generating only the work required for each increment to be able to proceed to the next increment. The DSDM methodology includes steps for feasibility, business study, functional model iteration, and implementation.

Extreme Programming.

Extreme Programming (XP) has been a widely adopted Agile software development method, and was first publicized by Kent Beck [18]. The key practices of XP are the following:

  • A team of five to ten programmers work at one location with customer representation on-site.

  • Development occurs in frequent builds or iterations, which may or may not be releasable, and delivers incremental functionality.

  • Requirements are specified as user stories, each being a chunk of new functionality that the user requires.

  • Programmers work in pairs, follow strict coding standards, and perform their unit testing.

  • Customers participate in acceptance testing.

  • Requirements, architecture, and design emerge over the course of the project.

XP is prescriptive in scope and customers are often readily available on-site for communication and collaboration purposes. The learning outcomes by paired programmers are invaluable, as the one developer that is not programming guides the one who is programming and this results in higher software quality in a shorter time interval [20].

Feature-Driven Development.

Originally conceived by Peter Coad and his colleagues, Feature-Driven Development (FDD) is an Agile method for object-oriented software engineering [18]. “A feature is a small, client-valued function expressed in the form: <action><result> <object> with the appropriate prepositions between the action, result, or object” [21]. FDD places greater emphasis on project management than most of the other Agile methodologies, with ad hoc project management becoming inadequate as the project grows in size. FDD defines six milestones during the design and build of a feature to improve the likelihood of success of scheduled software increments [18]. The milestones for each feature are the following:

  • Domain walkthrough.

  • Design.

  • Design inspection.

  • Code.

  • Code inspection.

  • Promote to build.

Lean Software Development.

Lean Software Development (LSD) is not an Agile methodology but rather a set of tools and principles that “make the software projects leaner” [19]. LSD draws its origins from the vehicle manufacturing industry, where productivity is measured by maximum reduction in unnecessary resource use, rather than increased throughput. Koch [19] explains that LSD is characterized by seven lean principles. LSD’s principles are further expanded into 22 lean software development tools.

2.2 Scrum Defined

We present a description of Scrum because of its significance in the development of the CF. The quantitative analysis performed on the developed custom model includes factors such as Relative Advantage, Complexity, Compatibility, Sprint Management, and Teamwork. The significance of the relationship between these factors and Scrum are moreover influenced by the Scrum practitioner’s use and understanding of Scrum.

Scrum is one of many Agile software development methodologies available. This methodology has seen exponential growth in its application over the past decade [7]. As a framework, Scrum allows organizations to improve on their project delivery objectives [17]. The Scrum guide written by Ken Schwaber and Jeff Sutherland describes this framework as lightweight, simple to understand, but extremely difficult to master [8]. Scrum embodies iterative and incremental development, and the framework comprises six artifacts, five roles, and four predominant activities [8]. The Scrum process as depicted in Fig. 1, displays some of the artifacts and activities involved in the Scrum process.

Fig. 1.
figure 1

A depiction of the components of the Scrum process.

Full size image

The following lists the items within each of the three components of artifacts, roles, and activities that make up the Scrum process:

The six Scrum artifacts are:

  • Product Backlog: The list of product items requested by the customer; for whom the software development team needs to complete. The managing of the product backlog is the responsibility of the product owner [22].

  • User Stories: A user story is the increment of value to the customer written on a card. The product backlog is a collection of user stories [22, 23]. See Heikkila and others [22] for a detailed explanation of how product requirements are broken down into smaller and more manageable user stories and tasks, from the features and epics.

  • Backlog Sizing: The size generation of the product backlog.

  • Sprint Backlog: The amount of work that needs to be completed by the development team within the current sprint (the sprint is usually 30 days in length). The sprint backlog is a subset of the product backlog [23].

  • Burndown Chart: Displays how the remaining work of the sprint task completion is progressing in graphical format.

  • Acceptance Criteria: Seen as a secondary artifact, which provides the developer with steps to follow before a story is considered done. The acceptance criteria are created with the assistance of the product owner.

Scrum roles can be broken up into five categories as listed below:

  • Scrum Master: This person is responsible for ensuring that the entire Scrum process team are kept informed of, and adheres to the Scrum practices. This position is seen as the Scrum mentor and its role is to also be the intermediary between the development team and the customer. The Scrum master provides the development team with the administrative support of Scrum, although a member of the development team often fills this position [24].

  • Product Owner: The product owner is responsible for the product backlog and ensuring that the development team fulfils the requirements of the customer [22].

  • Customer: This role is that of the organization or individual for whom the product is developed.

  • Development Team: Usually a group of 5 to 9 members (although subgroups of these numbers may exist in large organizations with multi projects) from various professions such as developers, testers, business analysts, designers, and DevOps engineers [25]. The team is responsible for ensuring that the product backlog shrinks in size as the number of sprints increases.

  • Other Stakeholders: These are individuals such as the project managers, directors, and sponsors who do not actively contribute towards the Scrum process. Customers are often included as other stakeholders [23].

The four activities that most Scrum teams and Scrum organizations deploy are sprint planning, daily stand-ups (Scrums), sprint reviews and sprint retrospectives. Other activities are not mentioned here, including activities that are specific to an organization and the Scrum team.

  • Sprint Planning: This is the major four-hour long meeting which includes many of the Scrum roles. The length of the meeting might vary based on organizational preferences. The roles that must be present are the Scrum master, product owner and development team. The meeting will determine which stories to include into the next sprint and which to exclude. The sprint usually lasts for 30 days. However, this can be amended to suit the organization. What is included or excluded in the Sprint is decided between the product owner and the development team, with greater influence coming from the latter.

  • Daily Stand-ups (Scrums): The Scrum is a brief fifteen-minute meeting for the development team and the Scrum master. The daily stand-up time of commencement during the day is irrelevant; however, it usually takes place as the first activity in the morning. Matters discussed by each member of the development team are [24]:

  1. 1.

    What have you done since yesterday?

  2. 2.

    What are you planning to do today?

  3. 3.

    What obstacles are preventing you from achieving your goal?

  • Sprint Review: The review happens at the end of the sprint and gives the opportunity for the development team to present the work of the completed sprint to the customer and other stakeholders. The completed sprint is presented in the form of a demo, and the customer provides feedback.

  • Sprint Retrospectives: Retrospectives is a time-boxed meeting for the development team and the Scrum master, to discuss ways in which the last sprint can be improved.

2.3 Adoption Challenges

The introduction of new methodologies typically poses challenges for individuals and organizations who make use of them [9]. The adoption of Agile methodologies creates additional challenges such as management style, software development process, and software developer resistance [2].

The challenges in the context of this paper is taken from a previous paper entitled “Scrum Adoption Challenges Detection Model (SACDM)” [3]. These challenges were derived from Agile, Scrum, software development methodology, and information systems literature. These challenges are encountered both within SA and globally elsewhere.

Due to Scrum research being primarily qualitative in nature [10], other Agile methodology challenges were considered as well in order to attain a more comprehensive model. Common issues such as lack of experience, the organizational culture, and lack of communication have been identified during the narrative review.

2.4 Theoretical Framework

Research by Chan and Thong [11], and Mohan and Ahlemann [9] explain that previous information technology adoption studies focused on the technical aspects of the innovation. These studies made use of technology adoption models, such as Technology Adoption Model (TAM). However, with complex Agile methodologies such as Scrum where collaboration between individuals within teams and organizations are important, a more inclusive model was required. The mixture of factors that affect adoption led to the selection the DOI theory as the theoretical lens for the Conceptual Framework (CF) [13].

The DOI theory is used in both organizational and individual adoption studies, with the DOI model composed of five characteristics of innovation. The five characteristics of innovation are Compatibility, Complexity, Observability, Relative Advantage, and Trialability [13].

In our custom model, as shown in Fig. 2, Compatibility, Complexity, and Relative Advantage are the three characteristics of innovation that have been retained. This decision was based on the strength of the relationship between these three characteristics and adoption behavior as identified in innovation studies [14].

Fig. 2.
figure 2

Scrum Adoption Challenges Conceptual Framework (SACCF) [36].

Full size image

3 Methodology

3.1 Research Design

The research design starts with a narrative review and the results from a survey questionnaire. This review was conducted due to the lack of quantitative literature on Scrum adoption. However, the factors of the CF were extracted and synthesized from the review of Scrum and Agile adoption challenges.

The quantitative survey design effectively operationalized the factors identified through the review as the independent variables, and Scrum adoption as the dependent variable. The online survey was used as the scale to measure the opinions of the Scrum practitioners in SA organizations [16].

The validity of the scale was tested using a pilot study, and the application of Exploratory Factor Analysis (EFA), Bartlett’s test for Sphericity, and Kaiser-Meyer-Olkin (KMO). Bartlett’s test for Sphericity, EFA, and KMO are discussed in the data analysis subsection. For reliability, the Cronbach’s coefficient alpha was used to measure internal consistency of the scale [16].

3.2 Population and Sample

Units of Analysis.

The population in this paper refers to the activities, cases, events, objects, phenomena, and subjects used for sampling [26]. The sample group (n = 207) is from the population consisting of all Scrum practitioners in SA organizations. To clarify further, Scrum practitioners in the context of this paper refers to any professional employed within a SA organization who is using Scrum while being involved in the Software Development Life Cycle (SDLC). Professionals include developers, testers, management, clients, Scrum masters, and product owners. A SA organization is any organization located within South Africa that have individuals or teams that practice Scrum as an Agile methodology.

Sampling Method.

With reference to sampling, Floyd and Fowler [27] list five essential characteristics of a suitable sampling method:

  • Deciding to select a probability or non-probability sample.

  • The sample frame, and its generalization.

  • The sample size.

  • The sample design, and its implementation strategy.

  • The response rates.

With above in mind, the sampling types that were considered for inclusion were, self-selection sampling, purposive sampling, and quota sampling. It was decided to conduct the survey using a non-probability, self-selection sampling method mainly because (a) it takes less time to complete in comparison with other methods, and (b) it presents a greater chance to obtain a more considerable number of responses.

3.3 Measuring Instrument

Survey Questionnaire.

A sound survey questionnaire is defined to be one that complies with the following pertinent criteria:

  • Questions are relevant and well-structured.

  • The questionnaire is evaluated by means of a pilot study.

  • The required response data is elicited from the sample.

The end goal of a good questionnaire is to determine what the sample’s biographical details, attitudes, behavior, opinions, beliefs and convictions are toward independent variables [16]. Since the questionnaire was self-administered, it was of greater importance that the questions in the questionnaire were unambiguous, clear, understandable and straightforward [28]. The questionnaire also included ordinal measurements for ranking.

The rationale for using a questionnaire as a survey instrument can be summarized as follows:

  • Inexpensive to administer.

  • Less time-consuming to manage.

  • Offers greater anonymity than other, e.g., face-to-face methods.

  • A greater number of respondents are reachable.

  • Data can be pre-coded.

Attitude Scales.

One of the main aspects that the questionnaire focused on, was the attitude of the practitioner. “Attitude” for the purpose of this study is taken to be a particular mindset or disposition towards a particular issue, the issue being the so-called attitudinal object. Examples of an attitudinal object are, political issues, a single individual, a group of people or a custom [16]. The measuring scale for attitudinal aspects toward Scrum is the Likert-type scale. This scale is most popular due to its ease of compilation [16]. A seven-point Likert-type scale was used to measure the respondent’s attitude toward adoption challenges of Scrum. The designed scale is as follows:

  • 7 = Strongly agree

  • 6 = Agree

  • 5 = Agree somewhat

  • 4 = Neither agree nor disagree

  • 3 = Disagree somewhat

  • 2 = Disagree

  • 1 = Strongly disagree

The rationale for using this scale is to obtain an indication of the respondent’s attitude in terms of the relationship of the independent variable with Scrum. The correlational relationship between the independent variables and the dependent variable, is evaluated by the analysis subsequently performed on the collected data.

3.4 Data Analysis

Exploratory Factor Analysis (EFA) is a statistical method used to describe the variability of observed variables in terms of unobserved constructs [4]. The validation of the questionnaire items against the initial 19 factors in the SACCF required a first and second order EFA to be conducted. In the first order EFA we considered the 78 survey questionnaire items to construct the newly validated 14 factors. These factors were subjected to a second order EFA in order to develop the four constructs.

The validity analysis proceeded by generating the first order EFA scores, and once these scores were summarized, the second order EFA followed. To test the sampling adequacy, the KMO measure of sampling adequacy was used. The KMO value obtained was 0.88. The Bartlett’s test for Sphericity was conducted to determine if it was useful to conduct factor analysis. The Bartlett’s test for Sphericity significance level was determined to be 0.00. These test results indicated that it was justifiable to conduct the EFA on the dataset.

In order to determine the number of factors derived from the individual statements, Eigenvalues greater than or near one, and the Scree plot were used. The constructs’ cumulative percentage was 75.8%.

The Principal Axis Factoring (PAF) extraction method with oblique rotation was used to seek a parsimonious representation for the common variance (correlation) between variables by latent factors. The oblique rotation implemented the Oblimin with Kaiser Normalization method since it was required to explore the correlations between the factors.

In summary, of the 78 questionnaire items, 14 factors were retained for rotation due to their Eigenvalues being greater than or near one. The first 14 factors as a collective accounted for 75.8% of the total variance.

Because of the factor loading cut-off criteria of 0.40, a total of 12 items were found to load on the first factor, and these were subsequently labelled “Organizational Behavior”. Eight items loaded on the second factor, labelled “Sprint Management”. Nine items loaded on the third factor, labelled “Relative Advantage”. Four items loaded on the fourth, fifth, sixth, and the seventh factor respectively, labelled “Experience”, “Training”, “Specialization”, and “Recognition”. Seven items loaded on the eighth factor, labelled “Customer Collaboration”. Three items loaded on the ninth factor, labelled “Compatibility”. Five items loaded on the tenth factor, labelled “Over-Engineering”. Three items loaded on the eleventh and twelfth factor respectively, labelled “Escalation of Commitment”, and “Complexity”. Eight items loaded on the thirteenth factor, labelled “Teamwork”, and four items loaded on the fourteenth factor labelled “Resource Management”. Table 1 shows the mapping of the initial 19 CF factors to the validated 14 factors.

Table 1. Mapping of the initial 19 factors to the validated 14 factors [36].
Full size table

The second order EFA was conducted on the 14 factors derived from the first order EFA output. The PAF extraction method and the Oblimin with Kaiser Normalization (oblique) rotation method were used to calculate the scores. The second order EFA generated the KMO measure of sampling adequacy test result of 0.78 and a Bartlett’s test for Sphericity significance level of 0.00 which made it viable to conduct an EFA. The Eigenvalues generated from the PAF extraction method resulted in 4 constructs, with the Eigenvalues greater than or near 1 and the Scree plot identifying the valid constructs. The cumulative percentage explained by the four constructs is 67.8%.

In summary, the second order EFA was applied to the 14 factors calculated in the first order EFA. The PAF method was used to extract the factors, followed by the Oblimin with Kaiser Normalization (oblique) rotation method. Of the 14 input factors, only four factors were retained for rotation, because of their Eigenvalue being greater than or near one. The first four factors as a collective accounted for 67.8% of the cumulative variance. These four factors are consequently referred to as the four constructs of the SACCF.

4 Results

The previous section described the methodology used to derive to the validated factors and constructs of the CF. A statistical analysis of the results derived with this methodology, is presented in this section.

4.1 Statistical Techniques that Answer the Hypotheses

Testing the Fourteen First Order Factor Relationship Strength.

Correlation analysis was used to test for the relationship strength among the different factors. The Spearman correlation analysis was conducted on all the factors as opposed to a Pearson correlation analysis, due to the skewness of the data discovered during the normality tests. The Spearman correlation analysis revealed statistically significant correlations for the relationships between Scrum Adoption and all the factors at the 0.01 level, except for Teamwork which was significant at the 0.05 level (p = 0.018), and Over-Engineering with no significance (p = 0.514), as shown in Table 2.

Table 2. Correlations among all the factors used in the study [36].
Full size table

Testing the Four Second Order Factor Relationship Strength.

A Spearman correlation matrix was used to test the relationship strength among the four constructs, as well as between the four constructs and the dependent variable. Once again, Spearman correlation analysis was selected, instead of a Pearson correlation analysis, due to the skewness of the data indicated by the normality tests. This analysis revealed statistically significant correlations between Scrum Adoption and the four constructs at the 0.01 level as shown in Table 3.

Table 3. Correlations between the four constructs and Scrum adoption [36].
Full size table

Testing the Statistical Significance of the Factor Relationship.

All the normality assumptions were met when a regression analysis was conducted on the 14 factors. Tolerance values were above .01, and all the Variance Inflation Factor (VIF) values were below 10, and the assumption of non-multicollinearity was met. The Durbin-Watson statistic fell within an expected range, which suggested that the assumption of no autocorrelation of residuals was met. The assumptions of linearity and homoscedasticity were also met, since the scatterplot of standardized residual and standardized predicted value did not curve or funnel out. The normal probability plot of the residuals was approximately linear, which suggests that the assumption of normality of residuals was also met.

Of the 14 factors, MLR was conducted to examine whether Over-Engineering, Relative Advantage, Recognition, Experience, Teamwork, Specialization, Escalation of Commitment, Compatibility, Resource Management, Customer Collaboration, Complexity, Training, Sprint Management, and Organizational Behavior impact on Scrum Adoption. The overall model (predictors: Over-Engineering, Relative Advantage, Recognition, Experience, Teamwork, Specialization, Escalation of Commitment, Compatibility, Resource Management, Customer Collaboration, Complexity, Training, Sprint Management, Organizational Behavior) explained 52.9% of the variance of Scrum Adoption, which was determined to be statistically significant (F(14, 206) = 15.40, p < 0.0001).

An inspection of the individual predictors of the overall model revealed that Relative Advantage (β = 0.688, p < 0.0001), Sprint Management (β = 0.109, p < 0.05), and Complexity (β = 0.041, p < 0.05) are significant predictors of Scrum Adoption (as shown in Table 4). Higher levels of Relative Advantage are associated with higher levels of Scrum Adoption; higher levels of Sprint Management are associated with higher levels of Scrum Adoption, and higher levels of Complexity are associated with lower levels of Scrum Adoption.

Table 4. Regression coefficients of the 14 factors [36].
Full size table

For the four constructs, MLR was conducted to examine whether Individual Factors, Technology Factors, Team Factors, and Organization Factors impact on Scrum Adoption. The overall model explained 33.40% of the variance in Scrum Adoption, which was shown to be statistically significant (F(4, 206) = 25.34, p < 0.0001). An inspection of the individual predictors revealed that Technology Factors (b = 0.580, p < 0.0001) and Team Factors (b = 0.126, p < 0.05) are significant predictors of Scrum Adoption (see Table 5). Higher levels of Technology Factors are associated with higher levels of Scrum Adoption, and higher levels of Team Factors are associated with higher levels of Scrum Adoption.

Table 5. Regression coefficients of the four constructs [36].
Full size table

5 Discussion of Findings

5.1 The Conceptual Framework Factor Loadings Affecting the Hypotheses Testing

It is important to note that initially, the SACCF had 19 factors (independent variables). However, during the validation of the scale, the Exploratory Factor Analysis (EFA) applied to the questionnaire items extracted 14 factors. The loading of the questionnaire items to new factors meant that the initial predicted model had to be evaluated. The questionnaire items with its commonalities and corresponding factor loadings were studied and it was found that the initial 19 independent variables loaded correctly into the 14 factors. The new factor loadings, therefore, made logical sense. In Table 1, as discussed in Sect. 3, the 19 hypothesized factors are mapped to the newly validated 14 factors.

While most of the mappings in Table 1 is self-explanatory, it is necessary to give an explanation of the four factors that have more than one independent variable.

These four factors are:

  • Organizational Behavior

  • Sprint Management

  • Customer Collaboration

  • Teamwork

The term Organization Behavior (OB) is defined as the actions and attitudes of individuals that work within an organization. OB is an indication of human behavior within the organizational environment, how human behavior interacts with the organization, and the organization itself [5]. George et al. [5], also states that the manner in which managers manage others is significantly affected by OB. Given this perspective of OB, it is reasonable to load Organizational Structure, Management Support, and Organizational Culture as a single factor under the heading OB.

The loading of Sprint Management and Change Resistance into a single factor is also logically sensible since firstly, Sprint Management is a time-boxed activity. Scrum practitioners would be performing their tasks within a Scrum sprint under most circumstances although it is recognized that this may not be the case for every task performed. Consequently, if a team is resisting change, it would manifest when the change is requested or performed during the Scrum sprint. Secondly, the fourth value of Agile development, being “responding to change over following a plan”, it is therefore appropriate that Sprint Management and Change Resistance loaded as the Sprint Management factor, since Change Resistance occurs by default, within the Sprint Management cycle [6].

The loading of Collaboration and Quality into the Customer Collaboration factor was unsurprising since Customer Collaboration entails working closely with the client in order to deliver a requested output at the expected quality. The last merged factor loading was Teamwork which consists of Teamwork and Communication. This factor loading was also a simple decision and with hindsight, these two factors had to be grouped together from the outset. The reason for this is because Teamwork requires individuals to work together to complete tasks, and communication is a critical component to complete sprint tasks within the team. It is important to note that the Resources factor has been renamed to Resource Management because resource shortage or surplus is a management related concern.

Figure 3 displays the third and final iteration of the CF. The hypothesized relationships between the independent variables and the dependent variable are shown in the parenthesis. As is evident from the diagram, the conceptual model is much more refined than the previous iterations. The Specialization factor which was previously under the team construct is now under the individual construct, and Over-Engineering which was an individual factor is now a team factor. The reason for these realignments is because Specialization or specialized skills can be narrowed down to the individual level. Over-Engineering, if encountered and allowed within a Scrum team environment, means that the team was not vigilant enough during their communication sessions to identify when an individual was doing more than what was required.

Fig. 3.
figure 3

Final iteration of the conceptual framework [36].

Full size image

While the authors are pleased with the validated CF factors and constructs, the effect it has on the evaluation of the initial hypotheses is of concern. The authors, however, believe that while the factors have changed from 19 to 14, it should not affect the hypotheses testing. The reason why the authors believe this to be the case was evident in Table 1. In the table, the reader will note that none of the initial 19 factors are removed from the SACCF. Those that are no longer a discrete factor have merged with other factors. However, based on the factor loadings and the opinion of the authors, these merged factors make sense. As a result, the authors strongly feel that the initial 19 hypotheses can be tested as individual hypotheses. However, the reader should note that some of the initial factors are loaded into a new factor as mentioned above.

5.2 Answering the Research Hypotheses

We discuss the statistical results and whether the hypotheses, as stated in Sect. 1, can be accepted or rejected. This subsection focuses on the outcomes of the 19 hypothesized statements, and a discussion of the individual findings.

Escalation of Commitment.

Escalation of Commitment was hypothesized to have a significant linear (negative correlation) relationship with Scrum adoption. While the research by Stray et al. [29] indicates the alarming effect of this factor on software project outcomes, with up to 40% of projects experiencing it, the regression results indicate no significant correlation with Scrum adoption. The coefficients from the MLR dictates that not only is there no significance with Scrum adoption, but the directionality of the relationship is positive. The hypothesis, that there is a significant linear (negative correlation) relationship between Escalation of Commitment and Scrum adoption, can thus be rejected.

Experience.

The lack of experience was included as a potential barrier to Scrum adoption based on the literature of Agile challenges [30]. Mastery of skills contributes to the performance of individuals [31], which we believe, would allow the Scrum practitioner to experience a lesser challenge in understanding and adopting a project management framework such as Scrum. While there is a weak correlation with Scrum adoption, there is no significant linear relationship. The hypothesis that there is a significant linear (positive correlation) relationship between experience and Scrum adoption, can hence be rejected.

Over-Engineering.

Over-Engineered solutions, as defined in the literature, is often due to lack of communication, and limited domain knowledge by the team executing the task [32]. It should be noted that Over-Engineering as a factor, has moved to the team construct from the individual construct of the SACCF. From the results, it can be concluded that Over-Engineering has no correlational and no significant linear relationship with Scrum adoption. It is the only factor to exhibit such a characteristic. The hypothesis that there is a significant linear (negative correlation) relationship between Over-Engineering and Scrum adoption, can hence be rejected.

Communication.

Our view is that Communication is arguably one of the most crucial skills to have as an individual, team or organization. The results in Sect. 4 suggested that although Communication is a prominent adoption challenge, it is not statistically significant with Scrum adoption. While Communication has been loaded into the Teamwork factor as mentioned, we can still conclude, based on the research results, that Communication does not have a significant linear (positive correlation) relationship with Scrum adoption. Communication, therefore, has a very weak correlation with Scrum adoption (at the 0.05 level).

Teamwork.

Our view is that working together to complete tasks, and achieving a common goal is what most organizations should be striving. In our opinion, a greater level of team cohesion increases the probability of successful project outcomes. It was anticipated that the Teamwork factor, which was a factor loading of the initial Teamwork and Communication factors, would have had a significant linear relationship with Scrum adoption. The reason for this view was simply because Teamwork and Communication are regarded as essential aspects of any Agile method [10]. It was surprising to note that Teamwork has no significant correlation and no notable significant linear relationship, with a p-value of 0.781. We can therefore reject the hypothesis as there is no significant linear (positive correlation) relationship between Teamwork and Scrum adoption.

Specialization.

As mentioned earlier, due to the questionnaire item factor loadings, Specialization has been grouped under the individual factors construct. With hindsight, we completely agree with this change, as skill levels can and should be evaluated at the individual level, allowing for a more refined analysis of the factor. The reason for the inclusion of Specialization as a Scrum adoption challenge is that specialist roles in the Scrum team could hinder the successful completion of a Scrum sprint due to a lack of overlapping skills [33]. The correlation between Specialization and Scrum adoption is significant at the 0.01 level. However, the linear relationship is far from significant. We can therefore reject the hypothesis as there is no significant linear (negative correlation) relationship between Specialization and Scrum adoption.

Sprint Management.

This factor is part of the Team construct and is generally considered an essential aspect of the sprint cycle. It is of the utmost importance that a professional Scrum practitioner in the form of a Scrum Master is appointed within organizations to facilitate the Scrum framework and sprint process. A mismanaged sprint can lead to other problems for the Scrum team [34]. The authors believe that Sprint Management should play an essential role in Scrum adoption by Scrum practitioners. Based on the research findings, Sprint Management has a significant correlation with adoption at the 0.01 level. A significant linear relationship with adoption was recorded, with a p-value < 0.05 and the t-statistic of 2.24. What this means is that an increase in Sprint Management relates to an increase in Scrum adoption. We accept the hypothesis of a significant linear (positive correlation) relationship between Sprint Management and Scrum adoption.

Change Resistance.

Change resistance, as mentioned earlier, has loaded with Sprint Management. Our opinion is that this newly loaded factor is sensible since a change affecting the Scrum team usually affects their sprint planning and management. However, because of the new factor loading, it is not definitive as to whether Change Resistance on its own has a significant linear relationship with Scrum adoption. The narrative review suggests that change resistance is a re-occurring adoption challenge experienced both globally and within SA [3]. Because Change Resistance carries equal weighting under the newly loaded Sprint Management factor one can accept that Change Resistance contributes significantly to Scrum adoption. The hypothesis that there is a significant linear (negative correlation) relationship between Change Resistance and Scrum adoption, is acceptable. An increase in Change Resistance results in a decrease in Scrum adoption.

Training.

Our view is that Training is essential for developing and up-skilling employees of an organization. The narrative review of global Agile adoption challenges demonstrated that Training, knowledge and learning, are indeed challenges to overcome. Within SA, Training was noted to be an insignificant challenge [3]. Our view is that Training could contribute to the adoption of Scrum, since Training can be regarded as a method of decreasing the challenges encountered during task completion. The results indicate that while Training has a weak significant correlation with Scrum adoption (at the 0.01 level), it does not have a significant relationship with adoption. The hypothesis being that there is a significant linear (positive correlation) relationship between Training and Scrum adoption, is rejected.

Recognition.

This factor is under the Organizational construct (see Fig. 2). Our view is that the lack of Recognition for an individual affects their willingness (or disposition) to attempt and complete tasks. The lack of Recognition has been shown to affect the productivity levels of the individual [35]. We believe that a lack of individual Recognition affects the individual’s willingness to adopt any innovation, not just Scrum, especially if the individual is not interested in the innovation. Based on the empirical findings, Recognition has a weak correlation with adoption (significant at the 0.01 level), as well as having no significant linear relationship. We reject the hypothesis because there is no significant linear (positive correlation) relationship between Recognition and Scrum adoption.

Quality.

Quality refers to the quality of software delivered to meet client and business expectations [3]. Since the client is the receiver of the level of Quality produced, it is loaded with Collaboration to form the Customer Collaboration factor. In our opinion, the quality delivered during the project milestones can determine whether the project succeeds or fails. The narrative review identified Quality as an infrequent adoption challenge. Software quality, on the other hand, is a prominent global Scrum adoption benefit [3], suggesting that quality of software is a result of Scrum adoption. The results indicate that there is a significant correlation between Customer Collaboration and Scrum adoption. Of interest, is that Customer Collaboration is just below the p < 0.05 significance level, with a p-value = 0.059. More research on Customer Collaboration as an independent variable of Scrum and Agile adoption, would be helpful in order to confirm any consistency with the finding of this study. We can reject the hypothesis as there is no significant linear (positive correlation) relationship between Quality and Scrum adoption.

Resources.

An organization requires Resources in order to generate products and services. Without a sufficient supply of Resources, for example, a lack of capital, lack of strategic direction, and inadequate resource management the organization might incur losses and setbacks. The narrative review identified a lack of documentation, budget constraints, high management overheads, and lack of infrastructure and tools as resource challenges for Scrum and Agile adoption [3]. During the second iteration of the SACCF the Resources factor has been renamed to Resource Management although the definition remains the same, as mentioned earlier. Based on the results, Resource Management was found to have no significant linear relationship although its correlation was significant. This result is unsurprising as it is difficult to conclude that poor Resource Management on its own will be pivotal in an individual to reject a framework such as Scrum. This hypothesis is rejected as there is no significant linear relationship between Resources and Scrum adoption.

Collaboration.

The research findings for Customer Collaboration is no different to most of the factors discussed thus far. As mentioned under the Quality factor, Customer Collaboration, which includes Quality, is below the significant linear relationship threshold by a narrow margin, and it would be useful to conduct a deeper evaluation of this factor. The narrative review identified Customer Collaboration and lack of business, customer, and product owner involvement during Agile adoption as some of the biggest challenges experienced globally [3]. However, results obtained in this study indicate that Collaboration has no significant linear (positive correlation) relationship with Scrum adoption.

Management Support.

The definition for Organizational Behavior (OB) was provided earlier in this section. Sultan and Chan [12] states that Management Support has a direct effect on innovation adoption. While not all innovations are equal, for example, Scrum requires Customer Collaboration, iterative and incremental development, while object-oriented programming as an innovation might not. We hence recognize that the statement by Sultan and Chan [12] might not necessarily hold in particular for the Scrum adoption results presented in this paper. As a newly loaded factor with Organizational Structure and Organization Culture, Management Support has an insignificant relationship with adoption. Our impression was that OB would have manifested a significant relationship should be re-evaluated in further Scrum adoption studies, perhaps with a larger population sample size. The hypothesis is rejected, since no significant linear (positive correlation) relationship between Management Support and Scrum adoption was evident in the results of this study.

Organizational Culture.

The authors appreciate the importance of an Organizational Culture that promotes innovative thinking, as innovation adoption and implementation often depends on the culture of the organization [9]. Organizational Culture identified as one of the most common Scrum and Agile adoption challenges [3]; however, as mentioned by Hoda and others [15], literature on the influence of Organizational Culture on Scrum teams is limited. Although OB has a significant correlation with Scrum adoption, it has no relationship of linear significance. The reason for this lack of linear significance may be because teams implement Scrum even when culture is problematic, and teams continue to adopt Scrum regardless of the prevalence of such challenges within the organization. The hypothesis that there is a significant linear (positive correlation) relationship between Organizational Culture and Scrum adoption is therefore rejected.

Organizational Structure.

We predicted that the lack of a hierarchical Organizational Structure improves the innovation adoption rate. This sentiment is aligned with findings in literature such as by Sultan and Chan [12]. However, when we consider the research findings for Scrum as innovation, the correlation significance at the 0.01 level is weak, and the MLR significance is virtually non-existent (p = 0.998). The hypothesis that there is a significant linear (negative correlation) relationship between Organizational Structure and Scrum adoption, is hence, rejected.

Relative Advantage.

Relative Advantage as discussed in Sect. 2 is one of the five innovation characteristics of the DOI theory. Rogers [13] noted that Relative Advantage and Compatibility are the two characteristics of innovation which contribute the most toward adoption. We concur that Relative Advantage is an essential contributor to innovation adoption, as suggested and it was reassuring to discover that the research results supported our sentiment. The value of this finding is that it strengthens the rationale to include Relative Advantage in other innovation adoption studies. Relative Advantage has a moderate to strong correlation with adoption, significant at the 0.01 level. The coefficients taken from the regression model indicate a significant linear relationship (p < 0.001) with a t-statistic of 10.168. We can, therefore, accept the hypothesis by stating that there is a significant linear (positive correlation) relationship between Relative Advantage and Scrum adoption. An increase in Relative Advantage results in an increase in Scrum adoption.

Complexity.

While Complexity, according to Kishore and McLean [14], is not one of two characteristics which contribute the most toward innovation adoption, it exhibits a relatively consistent relationship with adoption. We agree that Complexity affects an individual’s decision to adopt and implement innovation. Our findings indicate that, the correlation with Scrum adoption is significant at the 0.01 level, with a linear relationship at the 0.05 significance level with a t-statistic of −2.061. We can, therefore, accept the hypothesis by stating that there is a significant linear (negative correlation) relationship between Complexity and Scrum adoption. An increase in Complexity results in a decrease in Scrum adoption.

Compatibility.

Compatibility is said to be the other most important contributor, besides Relative Advantage, to innovation adoption [13]. However, research also indicates that the five characteristics of innovation adoption have characteristics of flexibility [12]. This suggests that the significance of Compatibility is dependent on several factors, including conditions such as the individual’s stage of adoption, the individual’s experience, and the type of innovation adopted. Although Compatibility has been shown to have a consistent relationship with adoption in other innovation research, our findings differ. The idea that these results might be due to poorly constructed questions related to the Compatibility factor was considered. However, a re-examination of the clarity and construction of the relevant questions, does not indicate that this statement holds. A possible explanation for the inconsistency of our findings with the literature, is that the decision to adopt Scrum often does not depend on the individual but the team or organization. This notion suggests that although the individual does not perceive Scrum to be compatible with them, they still end up adopting it. Compatibility has a moderate correlation with Scrum adoption (p < 0.01) with an insignificant linear relationship with p = 0.141. We reject the hypothesis since no significant linear (positive correlation) relationship between Compatibility and Scrum adoption is evident.

In summary, four of the initial 19 factors were identified as having a significant linear relationship with Scrum adoption. These four factors are Relative Advantage, Complexity, Change Resistance, and Sprint Management. The factor that came close to having a significant relationship with Scrum adoption was Customer Collaboration with p = 0.059. Because of the new factor loadings, both Sprint Management and Change Resistance loaded onto Sprint Management, as noted earlier. Figure 4 shows a parsimonious model of all the significant factors and their hypothesized relationship with Scrum adoption in parenthesis.

Fig. 4.
figure 4

Scrum adoption parsimonious model.

Full size image

6 Conclusion

This paper aimed to contribute to the field of Scrum adoption by conducting quantitative analysis to test the hypotheses predicting constructs and factors of significance with Scrum. The findings in a previous paper [36] confirmed the validity and reliability of the CF.

The results of the validity and reliability of the CF allowed us to continue with a statistical analysis of the questionnaire responses. The results obtained after applying Spearman correlation analysis and MLR, revealed that three of the 14 factors have a statistically significant relationship with Scrum adoption. These three factors are Sprint Management, Complexity, and Relative Advantage. This contribution is of significance both to Scrum adoption research and to the greater body of knowledge on Agile methodologies.

6.1 Recommendations

The findings from this paper adds value to organizations practicing Scrum. The literature and this paper confirm the importance of the innovation’s technical characteristics, namely, Relative Advantage and Complexity. In this paper, however, we also report new insights into Scrum adoption and its challenges as perceived by the individual Scrum practitioner. Based on the empirical findings, the following recommendations are made:

  • Organizations that are in the adoption stage of Scrum should consider the findings in this paper, particularly the identification of Sprint Management as having a significant linear relationship with Scrum adoption.

  • Organizations should look to increase their Scrum adoption success prospects by implementing strategies that also consider significant factors.

6.2 Further Research

Given the limited scope of this study, additional research on the topic in the following areas would contribute further knowledge to this topic:

  • A systematic review of the Scrum adoption challenges experienced by Scrum practitioners to support (or debunk) the validity and reliability of the Scrum challenges and factors included in the CF.

  • While we confirmed factors of significance influencing Scrum adoption through the SACCF, additional research that make use of a much larger sample, would improve the generalizability of the findings.