Change Management: Critical success factors of product development in Agile

(1)

IN

DEGREE PROJECT INDUSTRIAL MANAGEMENT, SECOND CYCLE, 15 CREDITS

STOCKHOLM SWEDEN 2020,

Change Management: Critical success factors of product development in Agile

SAHAR SAGHAZADEH

KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF INDUSTRIAL ENGINEERING AND MANAGEMENT

(2)

(3)

i

Abstract

Agile has become a popular product development in IT services. The trend of moving from a product traditional development approach to Agile emphasizes the important of change management in Agile. This thesis answers, “what are the critical success factors for effective change management in Agile?”. This research question was formulated to produce a better understanding of change management, different types of change management such as incremental and transitional management and the critical success factors of change management processes in Agile.

To study the importance of critical success factors in a practical perspective, this research applied the quantitative method of a self-completion questionnaire to collect data from a selection of IT organizations in Stockholm, Sweden. The selection included various sizes of organizations. Large (+250 Employees), medium (50-249 Employees) and small (10-49 Employees). Since various responsibilities are involved in Agile development projects, the target groups included a range of positions; project manager, OPO (Agile Product Owner), Agile Scrum Master, Developer, and Tester.

This research found a set of twelve critical success factors which can be applied as a guideline on how to increase the effectiveness of change management processes in Agile. These factors are (1) Cementing the change, (2) Time management, (3) Communication (4) Initial success and motivation, (5) Project organization and responsibilities, (6) Helping people to help themselves, training, and resources, (7) Flexibility in the process, (8) Shared problem awareness, (9) Defining the vision and objective, (10) Comprehensive diagnosis, (11) Management coalition, and (12) Monitoring. Because change management is a fundamental and important part of movement to Agile, effectiveness is vital in increasing the project’s success. The success factors also have been also studied according transition management point of view. These twelve factors can increase the effectiveness of change management procedures from a traditional development approach to Agile. Furthermore, the ranking of the success has been studied to understand the difference proficiency point of views.

(4)

ii

(5)

iii

Acknowledgement

I would like to express my gratitude to my supervisor Sven Antvik for his valuable guidance and patience. Without his valuable feedback and guidance this thesis would not have been a success.

I also want to thank Dr. Tomas Jansson for the knowledge and suggestions.

I am deeply thankful to my examiner Dr. Jouni Korhonen for his interest in this study and for his helpful and valuable recommendations.

Finally, I would like to thank my family for supporting and motivating me during my studies.

Sahar Saghazadeh

(6)

iv

(7)

v

List of Figures

Figure 1:Deductive research approach process, the sequences of (Defining the Theory, presenting Hypothesis, collecting data regarding the research question, examine the hypothesis, revision the theory) (Saghazadeh,

2019) (Bryman, 2012, s. 24) ... 5

Figure 2:Diagram of “Waterfall deployment model”, a traditional linear development model that puts focus on the linear sequential processes (sequence follow: Requirement, Design, Build, verification, and Support) (Hughey, 2009) ... 12

Figure 3:schematic view of Incremental deployment model, a traditional development model that puts focus on an operational product in each increment (Wilkinson, 2018). ... 13

Figure 4:Shewhart cycle, Deming cycle, PDCA cycle: an iterative cycle of processes: Plan, Do, Study and Act. (sixsigmastudyguide) ... 14

Figure 5:Diagram of Agile development method: an iterative and incremental cycle of processes (Requirements, Design, Build, Verification and Support) which reflects the periodic changes in each time-boxed phrase (i.e. Sprint) (GAO, 2012, s. 10) ... 15

Figure 6:Schematic view of Scrum Agile method: an iterative and incremental cycle of processes. The project is divided to smaller pieces, the sequence of processes: Plan-Build-test-review and the result is a part the product which is shippable to the customer (Saghazadeh, 2019) (Stedman, 2014). ... 22

Figure 7:Scrum burndown chart: Scrum is an iterative and incremental cycle of processes. The burndown chart shows the amount of work that has been completed and the total work is remaining in a Sprint. “Sprint” is a timebox within that the teams complete a set of tasks of development project. The black line shows the total amount of work left in the Sprint. The ideal line shows the approximation of where the team should be, assuming the linear development method. If the black line is below or on the ideal line means the team is on track to complete the work by the end of the Sprint (TargetprocessInc., 2017) (Littlefield, 2016) (Rehkopf, 2018). ... 23

Figure 8:Scrum workflow: an iterative and incremental cycle of processes (Stedman, 2014) ... 25

Figure 9:An example of typical Kanban board and Kanban process: an iterative and incremental cycle of processes. (easyprojects, 2015) (stellarvelocity, 2016) (Heikkilä, Paasivaara, & Lassenius, 2016) ... 27

Figure 10:Schematic view of three-pillar sustainability concept which focus on Environmental, Economic and Social concepts. (Saghazadeh, 2019) (Singh, 2019) ... 32

Figure 11: William Bridges Transition Model includes three phases of transition (Ending, Neutral Zone and New Beginning) (Bridges Associates, 2019) ... 37

Figure 12: Size of the organization ... 46

Figure 13: Proficiency of respondents... 46

Figure 14: The Agile experience of respondents ... 47

Figure 15: The percentage of the expectation from Agile ... 47

Figure 16: The percentage of how the urgency for a change is noticed through the organization... 48

Figure 17: The percentage of How often organization ask for feedback about Agile ... 49

Figure 18: The percentage of who has authority to establish change management in the organization ... 50

Figure 19: The percentage of how the vision and objectives distribute in the organization... 50

(10)

viii

Figure 20: The percentage of Agile training in the organization ... 51

Figure 21: The percentage of how organizations provide job description ... 52

Figure 22: The availability of Time plan in the organization ... 52

Figure 23: The percentage of How often organization ask for feedback about Agile ... 53

Figure 24: frequency of face-to-face meeting with a member of management team in the organization ... 54

Figure 25: frequency of face-to-face meeting with Agile Product Owner ... 54

Figure 26: frequency of reviewing the project burndown chart ... 55

Figure 27: frequency of success notification in the organization ... 55

Figure 28: Percentage of flexibility for change development process ... 56

Figure 29: The percentage of organizations which provide a written rules and workflow about Agile development approach ... 56

(11)

ix

List of Tables

Table 1: Overall comparison between Traditional linear development and Agile method an iterative and incremental cycle of processes. (Estler, Nordio, Furia, & Meyer, 2012) (Moran, 2015, ss. 1-15) (Tizemach, 2016) (Bollapragada, 2013) (Morse, 2011) (Agile & Waterfall Methodologies – A Side-By-Side Comparison) 20

Table 2: A set of hypothesizes in this study ... 43

Table 3: The results from a crosstab analysis and chi square tests... 61

Table 4:mean scores of importance of each success factor ... 63

Table 5:The results of hypothesis testing ... 64

Table 6:The statistics of ranking scores ... 65

Table 7:Ranking of critical success factors from respondents ... 66

Table 8: The statistics of ranking scores for Developers and Testers ... 67

Table 9: The most critical success factors from developer and tester point of view ... 67

Table 10: The statistics of ranking scores for Scrum Masters ... 68

Table 11:The most critical success factors from Product Owner point of view ... 68

Table 12: The statistics of ranking scores for Product Owners ... 69

Table 13:The most critical success factors in Product Owner Point of view ... 70

Table 14:The statistics of ranking scores for Project Managers ... 70

Table 15:The most critical success factors from Project manager's point of view ... 71

(12)

x

(13)

Chapter 1. Introduction

1.1. Background

The prospect of choosing an area to base this research thesis on was not easy. Change management is a common subject in project management and a substantial amount of research within the field has already been completed so the subject was chosen based on the researcher’s previous knowledge and experience in IT environment.

IT market services, implementation technology and system requirements are changing at a gradually rate, therefore a different approach has an advantage over traditional one. Agile software manifest is a very popular software development approach among IT companies and considered to be an alternative for traditional development methods (Nerur, Mahapatra, &

Mangal, 2005, ss. 73-78).

Firstly, it is necessary to state what “Agile” means in this report. In Webster’s dictionary

“Agile” is defined as “having the faculty of quick motion in limps; apt or ready to move; brisk;

active” (Webster, 1913).

In the context of software development, which is the focus of this thesis, Agile is the alternative of “Scrum” and “Extreme Programming (XP)”.

“Scrum” is an agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrummage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement. Scrum employs real-time decision-making processes based on actual events and information. This requires well-trained and specialized teams capable of self- management, communication and decision making. The teams in the organization work together while constantly focusing on their common interests (Cobb, 2011, s. 3).

“Extreme Programming (XP)” is a software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices and gaining enough feedback to enable the team to tune the practices to their unique situation. In Extreme Programming, every contributor is an integral part of the “Whole Team”. The team forms around a business representative called the

“Customer”, who sits with the team and works with them daily (Cobb, 2011, s. 3).

(14)

The use of Agile varies from different organization perspectives, project management, development, and engineering. The researcher found Change management in Agile to be an interesting subject. Today organizations are encouraged to continuously adapt their business with the new technologies and development approaches. However, applying new technology poses challenges within the organizations and Agile is not an exception. Therefore, studying effective change management in Agile is a necessary requirement. The findings can be useful for IT development, which is the focus of this thesis, but also for other project area in the future.

This thesis takes a managerial perspective of change management because it is critical in implementing organizational change.

In this research the researcher provided a survey on change and identified the key factors of successful change management. Finally, she illustrated how to improve effective change management and has provided a set of critical success factors for successful change management in Agile.

1.2. Research Question and goals

“What are the critical success factors for effective change management in Agile?”.

The primary goal of this research is answering the research question. The scope covers aspects of the research question and provides a reliable result. The expected result of this study is a set of critical success factors used to achieve success in applying change management in Agile. To answer the research question, the researcher has worked on the following scope:

• Review current literature, explore the Agile development approach and the process of change management.

• Outline a list of critical success factors based on the finding of the literature review.

• Present and assess a case study to investigate the critical success factors of change management in Agile and rank the critical success factors.

1.3. Method

This research paper is designed through two research methods: a literature review and case study.

The literature review provides the reader with key aspects of previous research which has been developed on the topic of change management and Agile development methodology. The outcome of the literature review presents a hypothesis which answers the research question

(15)

(Cottrell, 2014, ss. 77-88). The questionnaire data provides a large amount of data for this thesis. In addition, the case study provides an in-depth study of experience in change management in Agile, analyses the hypothesis to answer the research question and lists the critical success factors of effective change management in Agile (Cottrell, 2014, ss. 151-156) .

1.4. Limitations

The followings are limitations of this study:

• Data collection from organizations in Stockholm could make it difficult to conduct the survey in other cities.

• Time limit and cost limit, consuming data collecting methods such as interview and observations.

• Conducting an anonymous survey, which is restricted to publish managemental and technological information of the organizations

(16)

(17)

Chapter 2. Methodology

The aim of the research is to explore successful change management in Agile. This chapter describes the research methodology that is used in this study. In this chapter the choice of research approach, research strategy and data collection methods are explained with reference to the research question. Finally, research validity is rationalized.

2.1. Research Approach

Research approach can be classified by two methods: “Deductive” and “Inductive”. The deductive approach is a top-down approach, which means that one or more theories can produce a hypothesis and data collection. Subsequently, the hypothesis is tested, and either confirmed or rejected. Finally, the theory itself is then confirmed or revised. The inductive approach is the opposite of the deductive approach in that it is a bottom-up approach with the findings instead inferred, thus theory is the outcome of this approach (Bryman, Alan; Bell, Emma, 2007, ss. 14- 18) (Phuenngam & Na Ranong, 2009, s. 25) (Cottrell, 2014, ss. 97-106).

To answer the research question, this research has been conducted based on deductive approach.

The following graph describes the process of the deduction research method used for this research in related to the research question.

Figure 1:Deductive research approach process, the sequences of (Defining the Theory, presenting Hypothesis, collecting data regarding the research question, examine the hypothesis, revision the theory) (Saghazadeh, 2019) (Bryman, 2012, s. 24)

As shown in Figure 1, the study starts with the “theory”. To answer the research question, the literature focuses on the review of existing theories and the scientific papers that are available in change management and Agile development methodology. The second step is presenting the hypothesis in related to the research question (Cottrell, 2014, ss. 97-106). The next step is gathering evidence that is related to the research question. Finally, the collected data is

(18)

examined then confirmed or rejected eventually presenting a list of success factors of effect change management in Agile (Phuenngam & Na Ranong, 2009, s. 25).

2.2. Research Strategy

There are two common research methods, qualitative and quantitative. The following presents a definition of these methods according to the book, “Business research methods” written by Bryman and Bell, 2003 (Phuenngam & Na Ranong, 2009, s. 25).

Quantitative methods require gathering numeric data. The results of the research often be presented in numbers with questionnaires a common form of data collection.

Qualitative methods do not concern with numbers – instead, they emphasize words rather than quantification in the collection and analysis of data. Usually, the data is collected by conducting interviews (Bryman, Alan; Bell, Emma, 2007, ss. 54, 79).

This research used quantitative research strategy in combination with the deductive research approach to answer the research question. Applying the quantitative research strategy and collecting data through questionnaires with several respondents helped the study generalize the findings and rank the set of factors.

2.3. Data Collection

Choosing a proper way of collecting data was an important factor when conducting this academic study. The information that was collected was categorized into primary and secondary data and based on who collected the data. To answer the research question, a self-completion questionnaire was used to collect primary data with the literature review used to collect secondary data. According to Bryman & Bell, collecting data from different resources helps improve the validity of the research (Bryman, Alan; Bell, Emma, 2007, ss. 73-74).

(19)

2.3.1. Self-completion questionnaire

A self-completion questionnaire was one of the most cost-effective ways of collecting data. The questionnaire was designed with a set of questions aimed to gather the specific data related on the research topic which answered the research question. The questionnaire then evaluated each success factor. Furthermore, by using a self-completion questionnaire the researcher could also collect a large amount of data.

However, other data collection methods such as interview and observations can be time- consuming and are not suitable for this thesis (Bryman, Alan; Bell, Emma, 2007, ss. 66-69).

2.3.2. Sample selection

Sample selection is important when conducting a survey. In this study, a sample selection was based on the country of origin, the size of the organization, and which positions should be addressed to answer the research question. Since Agile is a common methodology for software development, the researcher decided to collect data from IT companies that were active in software development. In addition, different sized companies were chosen based on the numbers of employees: small (10-49 employees), medium (50-259 employees) and Large (260+ employees). This helped examine the influence of an organization’s size.

Since both technical and managerial responsibilities were involved in the development transition to Agile, the target groups were a range of wide positions such as developers, Agile Scrum Masters, Agile Product Owners, and project managers. These wide target groups helped collect detailed information from different points of view to answer the research question. The research also considered IT companies in Stockholm as judgmental sampling which is a non- profit sampling. Since the researcher lives in Stockholm, it was difficult to conduct the research in other cities. The response rate of this survey was 46% (23 of 50 respondents replied).

2.3.3. Design of questionnaire

The questionnaire contained twenty-two questions which were divided into the following:

I. General Information

II. Critical success factors for change management in Agile III. Ranking of critical factors

To answer the research question, the first section collected the background data of the respondents. The second part contained different types of questions (such as multiple choice)

(20)

to examine each critical success factor. The third section applied a ranking scale to a set of critical success factors. Appendixes1 presents a sample of questionnaire (Phuenngam & Na Ranong, 2009, s. 26).

2.4. Data Analysis

This research study uses a quantitative method for gathering data to answer the research question. There are three different methods to analysis the quantitative data: Univariate analysis, Bivariate analysis, and Multivariate analysis. Univariate analysis method is applied for this study, as only behavior of one variable is investigated to answer the research question and list the critical success factors of change management in Agile (Phuenngam & Na Ranong, 2009, s. 27).

The number and percentages are provided though IBM SPSS. “SPSS” is a popular statistic software in social studies which includes full data management and reporting tools and provides detailed statistical capabilities (SPSS, 2012).

In this research two statistics reports: “Crosstab” and “Ch squire” are used to test the hypothesis.

“Crosstab” provides information to assess the relation between two variables and assesses the relation between the size of the organizations and each critical success factor. “Ch squire” test helps answer the question and show how much is likely between the observed distribution and the expected distribution (Aljandali, 2016, ss. 53-75).

2.5. Research validity and reliability

Reliability is key when referring to whether the results are stable. In this research, the method was carefully explained to the respondents, who were selected because of their responsibilities within Agile development projects. They were free to answer the questionnaire without stress which would have had negative effect on the reliability of research (Phuenngam & Na Ranong, 2009).

To improve the reliability of this study, the researcher is using Cronbach’s Alpha as a coefficient form of reliability and a value between 0 and 1 to measure the internal consistency.

If alpha (α) value is near 0 then the quantified answers are no reliable, and if alpha (α) is close to 1 the answers are very reliable (Phuenngam & Na Ranong, 2009, s. 27) (Cronbach, 1951).

The number of Cronbach's Alpha through Cronbach's Alpha model analysis is shown in Appendixes 2. In this study, the number of Cronbach's Alpha was 0.792 that is acceptable level therefore this research is reliable.

(21)

Validity is considered with “the integrity of the conclusions that are generated from a piece of research” (Bryman, Alan; Bell, Emma, 2007, s. 38). To improve the validity, the researcher collected data from different resources to improve the validity of the research (Bryman, Alan;

Bell, Emma, 2007, ss. 73-74). This research used the questionnaire in addition to the literature review to collect in-depth data to improve the validity of the research and answer the research question. Furthermore, in this research the empirical data has been analyzed by “IBM SPSS”

statistic computer software which is popular when analyzing the deductive data in social researches (SPSS, 2012).

(22)

(23)

Chapter 3. Literature

This study centers on the critical success factors of change management to Agile, this chapter provides a literature study on Agile development method and its differences with traditional development method and critical factors for effective change management to Agile.

3.1. Project management methods

“The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed (Iivari, Hirschheim & Klein, 2000) (Whitley & Introna, 1997). The almost similar meaning has a term project management framework, which represents operative set of rules, processes, methods and templates to be used during the project lifecycle (Whitley & Introna, 1997)” (Spundaka, 2014).

3.2. Traditional project management method

“The basic idea behind the traditional, rational, and normative approach is that projects are relatively simple, predictable and linear with clearly defined boundaries which makes it easy to plan in detail and follow that plan without much changes. (Andersen, 2006) (DeCarlo, 2004) (Collyer, Warren, Hemsley, & Stevens, 2010) (Cicmil, Richardson, Crawford , & Cooke-Da, 2009) (Boehm & Turner, 2004) (Leffingwell, 2007) (Saynisch, 2010) (Shenhar, Levy, & Dvir, 1997) (Rose, 2010) (Williams, 2005)” (Spundaka, 2014).

“The basic goal of the traditional project management approach is optimization and efficiency in following initial detailed project plan, or, having said in usual way, to finalize project within planned time, budget, and scope. (DeCarlo, 2004) (Rose, 2010) (Shenhar, Levy, & Dvir, 1997)”

(Spundaka, 2014). Traditional project management works well when the goal and solution of the project is easy to identify, with the scope and deliverables clear (Rose, 2010) (Mrsic, 2017).

There are two main models for traditional project management, “Linear method” and

“Incremental method” (Wysocki R. K., 7th Edition, Dec 2013).

(24)

Figure 2:Diagram of “Waterfall deployment model”, a traditional linear development model that puts focus on the linear sequential processes (sequence follow: Requirement, Design, Build, verification, and Support) (Hughey, 2009)

As Figure 2 shows, in a linear traditional project management method, the specification of requirements, design, build, verification, and support are accrued one after another. In a linear project management life cycle, each process of project is done just once and there is no feedback loop (Ismail, 2013). The linear method has quite complete scope, goals and requirements. In this method you are expecting a very few involvements of the clients, scope change requests, little uncertainty and low risk (Wysocki R. , 2015). And you can schedule everything in advance and the members of development team don’t need to be co-located. However, the linear method must follow a fixed sequence of processes, doesn’t well adapt to change, takes long time before any products are produced (Wysocki R. K., 7th Edition, Dec 2013).

The second form of traditional project management is Incremental development method which is developed to overcome the weakness of the linear development model (Abdullahi &

Ogwueleka , 2017). The concept of incremental approach is delivering the multiple independent modules. This model contains of a series of independent increments that you monitor and complete. And when you finished the last increment, you completed the entire project.

(25)

Figure 3:schematic view of Incremental deployment model, a traditional development model that puts focus on an operational product in each increment (Wilkinson, 2018).

As Figure 3 shows, the workflow of incremental model is a linear approach between the increments. This means after the completion of one phase of deployment, the next phase will be started as a sequence follow: (Requirement, Design, Build, verification, and Support) and each increment delivers an operational product as part of desired functionality which can be used by the client. The highest priority requirements are delivered in the earlier increments. The earlier increments act as prototype to help to obtain requirements for future increments (Wilkinson, 2018). The incremental model is more focused on customer business values rather than the linear model and enables the project manager to better schedule the limited resources.

However, incremental model must follow a defined set of processes, needs handover documentation between increments and takes more time than the linear model (Wysocki R. K., 7th Edition, Dec 2013). “Agile” is a development model which is based on Incremental development model. However, it is more flexible to change and get the customers involved in the development process (Abdullahi & Ogwueleka , 2017). The following chapter describes Agile development method.

(26)

3.3. Agile project management method

“Agile” is the latest the buzzword in the software development area, but it is important to highlight what Agile means. Many people do not fully understand the implications of what it takes to develop an effective agile development process (Cobb, 2011, s. 3). As stated in 1.1, in Webster’s dictionary “Agile” adjective is defined “having the faculty of quick motion in limps;

apt or ready to move; brisk; active” (Webster, 1913).

In Business context a general meaning of the word “agility” is deﬁned as the following:

▪ the ability to create and respond to change to proﬁt in an unstable business environment.

▪ A very fast response to sudden market changes, by intensive customer interaction

▪ Use of incremental, and iterative delivery to converge on an optimal customer solution

▪ Maximizing the business value with right-sized, just enough processes and documentation (Cobb, 2011, s. 4) (Rico, 2010, ss. 37-40).

As defined in 1.1, in the context of software development which is the focus of this thesis, Agile is the alternative word of “Scrum” and “Extreme Programming (XP)” which are two software development approaches.

Further detailed information on Agile developing models is presented in the following.

Figure 4:Shewhart cycle, Deming cycle, PDCA cycle: an iterative cycle of processes: Plan, Do, Study and Act. (sixsigmastudyguide)

(27)

Agile is a phenomenon traced back to “iterative and incremental” process which grew from the work of Walter Shewhart in 1920s . Shewhart introduced a series of short “plan-do-study-act”

(PDSA) cycles for quality improvement. Figure 4 shows an iterative PDSA process. Firstly, you plan the details of the project: what is needed, when and by whom the project is going to be done. The next step is carrying out the plan which then leads to an analysis of the results and performance. Because Shewhart once worked with W. Edwards Deming on the iterative process, it is also referred to as the “Shewhart cycle” or “Deming cycle”.

Figure 5:Diagram of Agile development method: an iterative and incremental cycle of processes (Requirements, Design, Build, Verification and Support) which reflects the periodic changes in each time- boxed phrase (i.e. Sprint) (GAO, 2012, s. 10)

The first use of incremental and iterative processes was in hardware project during the development of “X-15” hypersonic jet in 1959. The project was the first manned rocket to break the atmosphere of earth. “Five major aircraft were involved in the X- 15 flight research program. The three X- 15s were designated X-15-1, X-15-2, and X-15-3. Early in the test program the first two X-15s were essentially identical in configuration; the third aircraft was completed with different electronic and flight control systems. When the second aircraft was extensively modified after an accident midway through the test program, it became the X-15A- 2. The two carrier aircraft were an NB-52A and an NB-52B; they were essentially

(28)

interchangeable.” (Jenkins, 2000, s. 45) According to W.D. Kay, “a major contributor to the X-15's success over the long run was its emphasis on incremental development and its use in highly specialized scientific and technical research” (Kay, 1998) (Dana, 1987). For the original X-15, the typical increment of speed increase was about half a Mach number¹. With this increment it was easy to handle the heating damage that occurred in the original speed expansion phase” (Jenkins, 2000, s. 81).

In the early 1970s, Tom Gibb helped create “Evolutionary project management” which evolved into competitive engineering. During 1990s, some lightweight software development methods include only a few development rules were grown in react to the planned and micro-managed methods (Larman & R. Basili, 2003).

In February 2001, a group of software developers gathered in Snowbird city to share ideas approaches in Software development. They suggested “Agile” as an umbrella term which applied to a collection of development methodologies, four main values, and twelve principles defined as “Manifesto for Agile Software Development”. Shortly after the conference, “Agile Alliance” formed and continued inspiring developers to share their experiences and ideas of Agile development (Beck, o.a., 2001).

The Agile values: (Beck, o.a., 2001)

1. “Individuals and Interactions Over Processes and Tools”

Agile is a people-focused environment and focuses on ability and innovation to solve problems.

2. “Working Software Over Comprehensive Documentation”

Agile does not remove documentation, but instead simplifies it by using a form that gives the developer what is needed to complete the work without getting stuck on details.

3. “Customer Collaboration Over Contract Negotiation”

1 Mach Number: The ratio of the speed of the aircraft to the speed of sound in the gas determines the magnitude of many of the compressibility effects.

Because of the importance of this speed ratio, aerodynamicists have designated it with a special parameter called the Mach number in honor of Ernst Mach, a late 19th century physicist who studied gas dynamics. (NASA, 2018)

(29)

Agile describes the customer who is engaged and collaborates during the development process, so that the development meets the customers’ needs.

4. “Responding to change over following a plan”

Agile, unlike traditional software development, does not regard change as an expense but rather sees the changes as an improvement of a project. Agile allows the team to modify the process for it to fit.

The Agile principles: (Beck, o.a., 2001)

1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. “

2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”

3. “Deliver working software frequently from few weeks to few months, with the preference to the shorter timescale”

4. “Business people and developers work together daily through the project”

5. “Build projects around motivated individuals. Give them the environment and support their needs and trust them to get the job done.”

6. “The most efficient and effective method of conveying information through face-to-face conversation.”

7. “Working software is the primary measure of progress”

Software is completed once it is tested and accepted by the final user. In Agile development the final user adds to the project team and is motivated to test and verify the delivered product immediately.

8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

9. “Continuous attention to technical excellence and good design enhances agility”

10. “Simplicity--the art of maximizing the amount of work not done--is essential.”

It is important to always search for unused subjects and indicate those out of the work to reduce the waste.

11. “The best architectures, requirements, and design emerge from self-organizing teams”

(30)

It is important that a person in team is cross-trained with different skills. It is no necessary to be equally trained in all needed subjects.

12. “At regular intervals, the team reflects on how to become more effective and adjust their behavior accordingly”

It is important that the agile team always reviews what has been done and what is needed to be done in the next Sprint. By adding or removing the tasks, the project will gradually progress and become effective.

The Agile development concepts:

The following presents important concepts in Agile development with the focus of IT:

• “A methodology”

Agile development is a methodology, it is not a tool, it is not an exact writing requirement, not an exact way of communication while, it is a whole methodology. Agile development is a type of project management. Agile is a project methodology. It is a way of executing software development project management as a team.

• “Iterative”

As Figure 5 shows Agile is iterative method. This means that Agile works entire cycle of software development project (requirement, design, build, verification, and support) for a while Then Agile can revise all the plans, do the changes, and start the development cycle again.

Those are usually called Sprints or Iterations which might be a week or two weeks. This method is total opposite to what is shown in Figure 2 Waterfall technique, which first some gigantic specifications of project are written, and everybody works away on it and then get it signed by client and build it to the blueprints like high-rise buildings. When the blueprints done, it is unchangeable. While in Agile technique, the plan revised constantly, and the iteration is fitted to that.

• “Streamlined”

In Agile development, Agile teams really prefer to get to work, have quick meetings and short documentations instead of many milestones and huge documents. Thus, Agile is very streamlined.

• “Time-boxed”

(31)

Agile is time-boxed which means the work is planned by time instead of by feature. In traditional projects, the development teams try to do the features A, B, C in order, in a specific time e.g. three weeks. While in Agile, they work three weeks of development and try to develop features A, B, C. Agile teams rigid on time not on feature. If half way through and they get all done, it is good to add new feature D and keep working because they plan three weeks of work.

• “Collaborative”

Agile is huge collaborative. Culture of collaboration make able the Agile teams to make their own decisions about their works, their abilities, and their commitments together instead of relying on a single person to make these decisions. By bringing the development team together, they can find the information that maybe hidden in their organization. Of course, collaboration doesn’t belong solely to the Agile environment, but it is critical to make Agile success. That’s because collaboration feeds “transparency” which creates “focus” and most importantly

“alignment”. “Alignment” is central for Agile team, giving them the ability to prioritize actions to consistently deliver the highest value. Agile collaboration centered on well facilitated dialog that ensures all voices in the room are heard and valued and creates a group that works together to a constructive conflict to build trust and safety. This trust leads to the most sustainable actionable decisions from the team level to the program level in to your organization.

• Human Motivation

Some studies have been conducted to understand the contemporary theory on human motivation and creativity in Agile management projects. In 2015, Dr. Tomas Johansson from Karlstad university, Sweden, applied Progress principles (Teresa M. Amabile, Steven J. Kramer, 2011), as the theoretical lens in an evaluation of Scrum method and presented the findings from a work-in-progress on agile praxis. The results showed that applying motivation theory may be useful approach to the developing knowledge of how agile practices contribute to efficiency and flexibility in many types of projects (Jansson, 2015, ss. 138-169)

3.4. Difference between Agile and Traditional project management method

Traditional project management methods involve very restricted planning and control. The traditional development approaches are plan driven methods with the fixed requirements, so that the plan can be created through cost and time (Sliger, 2012). This model is usually viewed as Waterfall method. Traditional project management methods are limited to stay on sequence.

(32)

It is usually difficult for the customers to fully state their requirements in the early stage of the project (Hass, 2007). On the other hand, Agile is a value driven method and is controlled through examination and adaption (Sliger, 2012). The following makes a comparison between Agile and waterfall as traditional development method through different perspectives.

Figure 2 and Figure 5 show schematic views of Traditional method (e.g. Waterfall) and Agile development method. As it shown in Figure 2, waterfall development diagram is a sequential process. When each stage of development process is completed then the developer moves to the next stage and cannot go back to the previous stage and change it. In the waterfall approach the project greatly relies on the defined requirements, if a requirement is changed the project should be started from the beginning and go through all the stages again. However as shown in Figure 5, the Agile development approach is an incremental process. The developers begin the project with a simple design and start work in weekly or monthly Sprints. Then they build a unit of the project and get the feedback of customers to be included into the design before the next Sprint starts. The following table provides an overall assessment between Agile and traditional method.

Traditional approach Agile approach

Highly structured Flexible

Hierarchical Structured, Commanding and controlling

Self-organizing

Detailed planning Fluid planning and Transparency

Focus on processes Less focus on formal processes

View changes as cost Welcome to changes, continues improvements on products and processes

Managers direct individuals to the activities Cross-functional teams

Deliver values at the end Regular delivery of products

Table 1: Overall comparison between Traditional linear development and Agile method an iterative and incremental cycle of processes. (Estler, Nordio, Furia, & Meyer, 2012) (Moran, 2015, ss. 1-15) (Tizemach, 2016) (Bollapragada, 2013) (Morse, 2011) (Agile & Waterfall Methodologies – A Side-By-Side Comparison)

(33)

Agile is useful when:

• The requirements of the project are constantly changing.

• The scope of the project is always changing. For instance, stakeholders that constantly add to the project.

• There are enough resources dedicated to the project.

• The customer can provide continues feedback on our delivery of products in a short cycle of time.

• We are flexible when we can deliver of products.

• We can streamline documentation and reduce time.

Traditional project management approach is useful when:

• The resources are distributed and there are some resources that are offshored.

• We have calendar restrictions, fixed timeline, and due dates.

• The project is a new technology, a new solution is implementing in the organization and the people who come to the project do not have the level of experience to be able to work rapidly or make decisions and to make the right domain of experience to the project (Rose, 2010, s. 84).

3.5. Agile methods

There are many Agile methods. This report describes some of the most common: Scrum, Kanban, Lean and XP (gov.uk, 2016). The following presents a general description and the pros and cons of each methodology (A. Qumer, B. Henderson-Sellers, 2008).

3.5.1. Scrum

“Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrummage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement. Scrum employs real-time decision-making processes based on actual events and information. This requires well-trained and specialized teams capable of self- management, communication and decision making. The teams in the organization work together while constantly focusing on their common interests.” (Cobb, 2011, s. 3)

(34)

Figure 6:Schematic view of Scrum Agile method: an iterative and incremental cycle of processes. The project is divided to smaller pieces, the sequence of processes: Plan-Build-test-review and the result is a part the product which is shippable to the customer (Saghazadeh, 2019) (Stedman, 2014).

As Figure 6 shows, the Scrum development process has been broken into smaller pieces. Firstly, a plan is devised which build a minimum feature set. Secondly, the plan is then built. Thirdly, it is rested and reviewed and then ready to ship.

The process usually accrues in a period of 1-3 weeks. This is repeated in the same motion, reducing the time from planning to development and to testing. Each time through the planning process, enough is planned to complete the next incremental release. This results in several incremental releases which are called ‘Sprints’.

A ‘Sprint’ usually 1-3 weeks. The ‘Sprints’ are repeated until the product or feature is completed. Sometimes product can be shipped after the second Sprint, or the third, or the forth and so forth (Stedman, 2014).

Scrum Roles:

In Scrum there are three key roles that are going to be needed for the method to work well:

Product Owner

This is the person responsible for finding the features that are needed in the products.

The Product Owner has the initial ideas that are turned into the products.

(35)

Scrum Master

The Scrum Master is the servant leader to the team, responsible for protecting the team and the process, running the meeting, and keeping things going.

Team

The team can be made of developers, testers, writers, and anyone else that helps in building the products. Team members often play different roles. For instance, developers often culminate in doing tests to get the product finished

Scrum Artifacts:

There are three artifacts or documents that are used in Scrum.

Product Backlog

Product Backlog is where the Product Owners create a prioritized list of features known as “User Stories”. This list evolves and changes priority with every Sprint. User stories are a way of describing a feature set that follows this format: As a [User], I need [Something], so that [Reason]. This way of phrasing a user story allows the Product Owner to specify and write all the details for the team to estimate the size of the task (Stedman, 2014).

Sprint Backlog

The highest priority user stories are the “Sprint Backlog”. This is estimated for size and committed to for the next Sprint.

Figure 7:Scrum burndown chart: Scrum is an iterative and incremental cycle of processes. The burndown chart shows the amount of work that has been completed and the total work is remaining in a Sprint.

“Sprint” is a timebox within that the teams complete a set of tasks of development project. The black line shows the total amount of work left in the Sprint. The ideal line shows the approximation of where the team should be, assuming the linear development method. If the black line is below or on the ideal line means the

(36)

team is on track to complete the work by the end of the Sprint (TargetprocessInc., 2017) (Littlefield, 2016) (Rehkopf, 2018).

Burndown Chart

The “Burndown Chart” shows the progress during the Sprint on the completion of tasks on the Sprint backlog. As it shown in Figure 7, the Scrum burndown chart should be at Zero points as the work has been completed.

“The actual progress line shows how much work remains for any given moment in time (remaining work). At the starting point, it shows the initial scope of work. Then, day by day, new points are added to the line on the right. When work is completed or removed from the scope, there is less time remaining, and the line goes down. If there is no progress, time remaining stays unchanged, and the line becomes flat. When some work is added to the scope, time remaining is increased, and the line goes up. The chart keeps track of all changes. Ideally, all the tasks are supposed to be completed, and the line then reaches the zero point. However, in the non-ideal world, you can run out of time too soon, and some work would still be incomplete at the finish line.” (TargetprocessInc., 2017).

Scrum Ceremonies:

There are three ceremonies as meetings or discussions to makeup Scrum.

Sprint Planning

Sprint Planning is when the Product Owner, Scrum Master and team meet to discuss the User Stories and estimate the relative sizes.

Daily Scrum

Daily Scrum is a brief standup meeting where the team discusses what they have completed since the previous meeting. They also discuss what they are working on and anything that might be blocked or needed.

Sprint Review and Retrospective

Sprint review and Retrospective occur at the end of Sprint. This is where the team demonstrates their completion to the Product Owner. The team discusses what they can do to improve the processes going forward.

(37)

Product Backlog

Sprint Planning

Sprint

Backlog Sprint

Potentially Shippable

Product

Sprint Review

Figure 8:Scrum workflow: an iterative and incremental cycle of processes (Stedman, 2014)

Scrum Workflow:

Figure 8 shows the Scrum workflow. Scrum workflow starts with a Product Backlog, which is where the Product Owner lists the ideas and features that could go into the product. The Product Owner prioritizes the list and brings the top items to the team. Sprint Planning is where the team, Product Owner and Scrum Master discuss about the top priority User Stories to determine what can go to the next Sprint. The output of the Sprit Planning meeting is the Sprint Backlog.

This is a list of User Stories that have been committed for the next Sprint. The entire team and Product Owner have a solid understanding of what each of the Use Stories involve based on the discussions of the Sprint Planning meetings. The Sprint is a one to three timebox where the work has been committed in the Sprint Backlog through completion. During the Sprint the Daily Scrum occurs as the standup meeting within the team discusses what they have completed and what they are working on as well as any blocked item. The outcome of the Sprint is a potentially shippable product. Potentially shippable product means that the Product Owner can decide if this is ready to ship or any additional feature is needed before the ship. At the end of the Sprint, the Sprint review, and Sprint Retrospective occurs. Sprint review is where the team shows cases to the Product Owner and the Retrospective is where the team works on what they can do to improve the process. The Workflow for each Sprint is then repeated (Azanha, Terra Argoud, de Camargo Junior, & Domingos Antoniolli, 2016) (Zhi-gen, Quan, & Xi, 2009) (Stedman, 2014).

Advantages:

• Improve communication between the teams who work in the project.

• The problems are transparent.

• Many meetings improve the visibility of the project.

• Provide feedback from customers and stakeholders.

• Easy to manage for large projects.

(38)

Disadvantages:

• Scrum depends on the team members, leaving a team member during the project can be a challenge.

• Successful Scrum needs to have experienced people in the team (Chandana, 2017).

3.5.2. Kanban

Kanban is a Japanese term meaning ‘billboard' or ‘sign’. Kanban was developed by in the 1940s by Toyota, however it can apply to different industries such as construction, architecture, software development and time management. Kanban is usually based on a system of cards arranged on a board. The philosophy behind the whole approach is to optimize the collaboration between every party involved in the project and eliminate work in progress. Toyota do not waste their resources. In the Toyota production system each part is produced and delivered only when it is necessary. They avoid overproduction and follow just-in-time concept: producing only what is needed, and the amount needed. Kanban acts to organize backlog, so the tasks are prioritized base on the relevant information. More importantly it restricts the amounts of activities in progress, so a fix number of tasks is performed simultaneously. This way, every team member can focus on their task and only get to the next one when the previous one is complete. The Kanban board is organized in multiple columns. Each column represents a level of production like development, testing, or deployment. In the simplest version, a Kanban board can have “To Do”, “In Progress” and “Done” with cards containing tasks moving along the board, the top ones are the top priority tasks. This way all the work is visualized, and it is easy to see any problems that may arise (easyprojects, 2015). After the Kanban board has been created, all the necessary contributors are invited to participate on the board. This creates a small but dynamic working group. Depending on the nature of your business you might invite engineers, designers, and any other necessary employees. In small company the Product Owner might be a business owner, in a large organization it might be a project manager. Generally, it is the role of the Product Owner to maintain a list of work items that need to be accomplished to complete a project. project. In Kanban, it is representative on the board with “Tasks” or cards. They are also sometimes called “User Stories” because it describes work in sequential by size points to help the Product Owner stay organized.

(39)

Figure 9:An example of typical Kanban board and Kanban process: an iterative and incremental cycle of processes. (easyprojects, 2015) (stellarvelocity, 2016) (Heikkilä, Paasivaara, & Lassenius, 2016)

Figure 9 shows an example of typical Kanban board and a Kanban process flow:

Step 1: As shown in Figure 9, a typical Kanban board often contains a “Backlog”. A Backlog is a sorted and prioritized list of tasks that are not yet ready to be worked. In the first step of Kanban flow the tasks are sorted and prioritized in the Backlog. In this example Task A has the highest priority and Task B and C are the next levels of priorities.

Step 2: As work becomes ready for the team, the Product Owner moves the task from the backlog to the column. Once a card is moved in “To DO” column, it is ready to be worked by the team. In a Kanban system the top cards are the most important. As a result, there is no confusion as to which task needs to be worked next.

Step 3: As work begins the card pulled out of the “To DO” column is placed in “In Progress”

column. During this journey, the board participants can add notes, change ownership, and invite others to participate. This helps everyone on the board know the plan at any given time.

(40)

Step 4: One by one cards are moved from the backlog on to the board. Team members continue to pull cards from one column to the next and add items to “Completed”.

Step 5: When a Backlog becomes empty and all the cards are in the “Completed” column, the project is done (stellarvelocity, 2016) (Heikkilä, Paasivaara, & Lassenius, 2016).

Advantages: (Leopold & Kaltenecker, 2015) (Hristovski, 2017)

• Reduce the waste.

The components are created only when they are needed

• Reduce the total cost of the project.

Kanban reduces the cost of waste, wait times, overhead

• Smooth flow from start to completion without unnecessary slowdown or stoppage

Disadvantages (Leopold & Kaltenecker, 2015) (Hristovski, 2017)

• Need up-to-date Kanban board, out-of-date board can lead problems in the project progress.

• No timeframe for development phase.

3.5.3. Lean

Lean is a methodology which is used for processing and improvement.

Lean Principles: (TecoEnergyInc, 2016) (Eaton, 2013, ss. 23-55)

• Define value

The first principle is specifying value in the eyes of customers. Focus on what the customer wants and align the process to deliver that. Ensure the customer’s driven measurements are in place.

• Identify value streams and eliminate waste

To follow the process and eliminate the barriers that slow down the repeat the flow.

Those barriers are waste.

• Create a smooth flow

To create and maintain a consistent flow of valuable steps throughout the whole value stream.

• Continuously improve and persuade of perfection

To aim for perfection and improvement on the processes and eliminate the layers of waste as they get built.

(41)

• Establish a pull system

To understand all aspects of the customer demands. To not create value flow in advance.

The customer needs to state the scope of the work. It is important to meet the time frame for the customer, do not be too early and do not be too late.

Advantages:

• Eliminate the waist and improve the efficiency of the project.

• Create a motivated team and improve the team ability to make decisions (Eaton, 2013).

Disadvantages

• Successful projects need experience and a dedicated team who are able to work in environment with open instructions (Eaton, 2013).

3.5.4. Extreme Programming (XP)

“Extreme Programming (XP) is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirement” (Beck, 1999, ss. 1- 10).

Extreme Programming (XP) method is:

• Lightweight: Few rules and practices which are easy to follow (Charvat, 2002).

• Humanistic: Focusses on people, developers and customers are the center of the software development process.

• Discipline: Includes rules and practices that are needed to follow.

• Software development: Software development is the key point of the whole method.

Extreme Programming consists of: (STARVideos, 2015) (Wohlin, 2012)

• Pair Programming: Two people who work using one computer. There are two roles:

The ‘Navigator’ and the ‘Observer’. Pair Programming, if done well, results in less mistakes, cost of business and dual learning. The new ideas are incurved, resulting in better codes.

• Code Review: To continue the process of improvement used in creating more efficient and clean code. The code is usually well documented, which makes it easier for others to carry on the work. Code review usually includes a Review team who examine the program that has been coded. This results in the programmer becoming aware of bad habits.

(42)

• Unit Testing: Unit testing is a testing method for each unit and the smallest testable part such as functions and procedures. It helps identify failure in the logic of the per code produced. The developer writes the code that is the easiest to test.

• Integration Testing: This is the phase of software testing where individual modules are combined and tested as a group. In the first part, the software is completed and tested.

The second part is then completed.

• Courage: This occurs to play when an important decision needs to be made. The team usually takes the responsibility by disregarding parts of the code that are not useful.

XP Workflow:

Step1: Programmers review user stories to determine the project’s requirements, priorities, and scope.

Step2: User stories are implemented in a series of iteration cycles of planning, designing, coding, and testing.

Step3: Once implemented, a user story is released (like a prototype) for testing and modification if needed (Wohlin, 2012).

Advantages:

• It helps save time and focuses on timely delivery.

• Simplicity

• Small number of documentation which helps companies save time and cost.

• Solves problem inside the teams (Maniuk, 2016).

Disadvantages:

• Focusses on code rather than design.

• Lack of documentation which causes fault in the future (Maniuk, 2016).

3.6. Agile in sustainability engineering

As mentioned in chapter 1, the use of Agile development method varies from different organization perspectives, project management, development, and engineering. The market instability and increased products variety and complexity require agility, adaptability, reaction (Hoda A. ElMaraghy, Hoda A. ElMaraghy , 2013). Agile manufacturing has been identified to respond to the continuous changes. Agile systems from raw materials to energy, from information to engineered products, manufacturing systems are open and flexible systems. This

Change Management: Critical success factors of product development in Agile

Change Management: Critical success factors of product development in Agile

SAHAR SAGHAZADEH

Abstract

Acknowledgement

Table of Contents

List of Figures

List of Tables

Chapter 1. Introduction

1.1. Background

1.2. Research Question and goals

1.3. Method

1.4. Limitations

Chapter 2. Methodology

2.1. Research Approach

2.2. Research Strategy

2.3. Data Collection

2.3.1. Self-completion questionnaire

2.3.2. Sample selection

2.3.3. Design of questionnaire

2.4. Data Analysis

2.5. Research validity and reliability

Chapter 3. Literature

3.1. Project management methods

3.2. Traditional project management method

3.3. Agile project management method

3.4. Difference between Agile and Traditional project management method

3.5. Agile methods

3.5.2. Kanban

3.6. Agile in sustainability engineering