Agile Application of the Project Processwithin Software Development: An investigation of the Agile project process, includingchallenges in practical application

Agile Application of the Project Process within Software Development

- An investigation of the Agile project process, including challenges in practical application

KRISTINA ERNSELL

Master of Science Thesis

Stockholm, Sweden 2014

Agil Tillämpning av Projektprocessen inom Mjukvaruutveckling

- En undersökning av den Agila projektprocessen, inklusive utmaningar vid praktisk tillämpning

KRISTINA ERNSELL

Examensarbete

Stockholm, Sverige 2014

Agil Tillämpning av Projektprocessen inom Mjukvaruutveckling

- En undersökning av den Agila projektprocessen, inklusive utmaningar vid praktisk tillämpning

av

Kristina Ernsell

Examensarbete INDEK 2014:41 KTH Industriell teknik och management

Industriell ekonomi och organisation

SE-100 44 STOCKHOLM

Agile Application of the Project Process within Software Development

- An investigation of the Agile project process, including challenges in practical application

Kristina Ernsell

Master of Science Thesis INDEK 2014:41 KTH Industrial Engineering and Management

Industrial Management

SE-100 44 STOCKHOLM

Examensarbete INDEK 2014:41

Agil Tillämpning av Projektprocessen inom Mjukvaruutveckling

- En undersökning av den Agila projektprocessen, inklusive utmaningar vid praktisk tillämpning

Kristina Ernsell

Godkänt

2014-06-16

Examinator

Matti Kaulio

Handledare

Anna Jerbrant

Sammanfattning

Genom dess anpassningsförmåga och förändringsmottaglighet har den Agila metodiken blivit en populär tillämpning för projektprocessen inom mjukvaruutveckling, en miljö där snabba förändringar tillhör vardagen. Den Agila metodiken framhäver interaktion mellan projektroller framför dokumentation och formella processer, vilket ökar behovet av fungerande informationsspridning genom hela projektprocessen.

Studien har utförts hos ett mindre svenskt IT-konsultföretag, vilket önskade att införskaffa en programvara för ett projektlednings- och planeringsverktyg som kan stötta hela projektprocessen och alla involverade projektroller. Medvetenheten kring de områden i projektprocessen som är i behov av stöd var däremot inte helt tydlig. Målet med studien var därför att undersöka företagets tillämpning av den Agila projektprocessen och identifiera eventuella utmaningar. Vidare var målet också att undersöka hur en programvara för ett projektlednings- och planeringsverktyg kan stödja den Agila projektprocessen inom mjukvaruutveckling. Examensarbetet utfördes som en abduktiv fallstudie där flera kvalitativa datainsamlingsmetoder användes tillsammans med litteraturstudier.

Som resultat av studien har två huvudslutsatser dragits. För det första; kravhantering, kundrollen, kommunikation och kunskapsöverföring identifierades som framträdande utmaningar i projektprocessen i behov av ökat stöd. För det andra, att en programvara för ett projektlednings- och planeringsverktyg kan stödja projektprocessen genom att;

förbättra kommunikations- och samarbetsmöjligheterna, ge en övergripande och historisk projektöverblick, fungera som en gemensam lagringsplats och tillhandahålla struktur. Vidare har studien visat att en programvara för ett projektlednings- och planeringsverktyg måste interagera med den Agila projektprocessen för att ge ett effektivt stöd. Som ett slutligt bidrag skapades ”the Interaction model”, vilken visualiserar huvudområdena inom vilka en programvara för ett projektlednings- och planeringsverktyg måste interagera med projektprocessen för att ge ett fullt stöd till processen.

Nyckelord: Agil projektprocess, programvara för Agil projektledning- och

planeringsverktyg, Agila mjukvaruutvecklingsprojekt

Master of Science Thesis INDEK 2014:41

Agile Application of the Project Process within Software Development

- An investigation of the Agile project process, including challenges in practical application

Kristina Ernsell

Approved

2014-06-16

Examiner

Matti Kaulio

Supervisor

Anna Jerbrant

Abstract

With its core in adaptability and change responsiveness, the Agile methodology has become a popular application of the project process within the often volatile environment of today’s software development projects. The Agile methodology emphasizes interaction between project roles over documentation and formal processes. This higher interaction increases the need for functioning information dissemination throughout the entire project process.

The study was carried out at a small sized Swedish IT consultancy firm. The company wished to acquire a project management and planning software tool to support the entire project process and all involved project roles. However, awareness of areas in the project process in need of support was not entirely clear. Therefore, the objective of the study was to investigate the company’s application of the Agile project process and identify potential challenges. Furthermore, the objective was to investigate how a project management and planning software tool can support the Agile project process within software development. The thesis was carried out as an abductive case study, where qualitative data collection methods and literature studies were combined.

As a result from the study, two main conclusions have been drawn. Firstly; requirements engineering, the customer role, communication, and knowledge transfer were concluded as prominent challenges in the project process in need of increased support.

Secondly, a project management and planning software tool can support the project process by; increasing the communication and collaboration abilities, providing holistic and historical project overview, providing a single storage location, and providing structure. Furthermore, the study has also shown that the project management and planning software tool needs to interact with the Agile project process in order to provide successful support. As final contribution, the Interaction model was created. The model visualizes the main areas in which a project management and planning software tool must interact with the Agile process, in order to support the entire project process successfully.

Key words: Agile project process, Agile software project management and planning

tool, Agile software development projects

Acknowledgment

This thesis represents the final work of my academic career at the Royal Institute of Technology, KTH. The work has been challenging, but also exciting and fulfilling. It would not have been possible without the support from a number of persons, which I would like to thank.

I would like to show my gratitude to all employees at the case study company for the warm reception and interest of my study. A special thanks to my company supervisor, who has cared for me and supported me throughout the entire process. Thanks for your advice and your understanding of my struggles.

Furthermore, I would like to thank Anna Jerbrant, my supervisor at KTH for her always critical but honest opinion on my work and progress. Your support, knowledge, and experience have been of great value to me. I also would like to thank Matti Kaulio and my seminar group for the discussions and feedback during the semester.

Finally, I would like to thank my family and friends for their patience. You have always been there to encourage and support me, not only during this last semester, but for all five years.

Thank you!

Kristina Ernsell,

Stockholm, Sunday 15 ^th June, 2014

Table of Contents

1 Introduction 1

1.1 Problem Background . . . . 2

1.2 Aim and Objective . . . . 2

1.3 Research Questions . . . . 2

1.4 Starting point of the study . . . . 2

1.5 Delimitation . . . . 3

1.6 Thesis Outline . . . . 3

2 Theoretical Framework 5 2.1 Traditional Project Management . . . . 5

2.1.1 The Customer Role in Traditional Project Management . . . . 7

2.2 The Agile Methodology . . . . 8

2.2.1 The Agile Project Process . . . . 9

2.2.2 The Agile Team . . . . 10

2.3 The Scrum Method . . . . 12

2.3.1 The Scrum Roles . . . . 12

2.3.2 The Scrum Artifacts . . . . 13

2.4 The Project Process in Software Development . . . . 15

2.5 The Project Process Tools in Software Development . . . . 16

2.6 The Integrated Software Engineering Environment . . . . 17

3 Methodology 19 3.1 The Abductive Case Study . . . . 19

3.1.1 Interviews . . . . 21

3.1.2 Literature study . . . . 22

3.1.3 Observation . . . . 22

3.1.4 Documentary Analysis . . . . 23

3.2 Data Analysis . . . . 23

3.3 Quality of the Report . . . . 24

3.3.1 Reliability and Validity . . . . 24

3.3.2 Generalizability . . . . 24

3.3.3 Ethics . . . . 25

3.3.4 Limitations . . . . 25

4 The Case Company 26 4.1 The Organization . . . . 26

4.1.1 Organizational Roles . . . . 27

4.1.2 Business idea: New IT . . . . 28

4.1.3 Vision . . . . 28

4.1.4 Mission . . . . 29

4.1.5 Values . . . . 29

4.2 The Offerings . . . . 29

4.3 The Main Processes . . . . 30

4.3.1 The Delivery Process . . . . 31

4.4 The Project Process . . . . 32

4.4.1 Project Initiation . . . . 32

4.4.2 Ongoing Project . . . . 34

4.4.3 Project Closure . . . . 35

4.4.4 Project Roles . . . . 36

4.4.5 Requirements Engineering . . . . 36

4.5 The Support & Maintenance Process . . . . 37

4.6 The Project Infrastructure . . . . 38

4.6.1 Code Management . . . . 38

4.6.2 The Issue Tracking System . . . . 39

4.6.3 Information Hub . . . . 39

5 Empirical Findings & Analysis 40 5.1 The Project Process . . . . 40

5.1.1 Project Initiation . . . . 40

5.1.2 Ongoing Project . . . . 42

5.1.3 Project Closure . . . . 43

5.1.4 Project Roles . . . . 43

5.1.5 Requirements Engineering . . . . 44

5.2 The Project Infrastructure . . . . 45

5.2.1 Code Management . . . . 45

5.2.2 The Issue Tracking System . . . . 45

5.2.3 Integration . . . . 45

5.3 Summary . . . . 46

6 Discussion 48 6.1 The Project Process . . . . 48

6.1.1 Project Structure . . . . 49

6.1.2 The Customer Role . . . . 49

6.2 The Project Infrastructure . . . . 50

6.2.1 Integration . . . . 50

6.3 The Need for a Project Management and Planning Software Tool . . . . 51

6.4 The Interaction Model . . . . 53

7 Conclusion 55 7.1 Which prominent areas need to be supported in the Agile project process within software development? . . . . 55

7.2 How and in what way can a project management and planning software tool support the Agile project process within software development? . . . . 56

7.3 Empirical Contribution . . . . 57

8 Final Reflections of the Study 58 8.1 Sustainability . . . . 58

8.2 Future Research . . . . 58

References 59

Appendix A - The Agile Manifesto 62

Appendix B - Interview Questions 63

Appendix C - Interview Characteristics 64

Appendix D - Tool Comments, Company Specific 65

List of Figures

1 The Waterfall model (Inspired by Royce (1970, pp. 329)). . . . 6

2 The Iron triangle (Inspired by Atkinson (1999, pp. 338)). . . . 6

3 The Agile project process (Inspired by Appelo (2010, pp. 324)). . . . 9

4 The structure of an Agile team (Inspired by Ambler (2005)). . . . . 12

5 The Scrum process (Inspired by Schwaber (2004, pp. 6) and Gustavsson (2011, pp. 129)). . . . 14

6 Design of the research process. . . . . 20

7 Organization map of the case company (reproduced from the Intranet). . . . . . 27

8 Relation between the case company’s competence areas and offerings (reproduced from the Intranet). . . . 29

9 The main processes at the case company (reproduced from the Intranet). . . . . 30

10 The Delivery process at the case company (reproduced from Intranet). . . . 31

11 The project process at the case company (reproduced from the Intranet). . . . . 32

12 The support & maintenance process at the case company (reproduced from the Intranet). . . . 37

13 The Interaction model. . . . 53

14 The Interaction model. . . . 56

List of Tables

1 Description of the Agile roles. . . . . 11

2 Scrum concepts and artifacts. . . . 14

3 Summary of the interview characteristics. . . . 64

4 The tool; Case company specific comments. . . . 66

Abbrevations

CAM Customer Account Manager.

CPA Critical Path Analysis.

DRY Don’t Repeat Yourself.

FDD Feature-Driven-Development.

GUI Graphical User Interface.

IPSE Integrated Project Support Environment.

IT Information Technology.

ITS Issue Tracking System.

SME Small and Medium Enterprises.

TDD Test-Driven Development.

TFS Team Foundation Server.

WBS Work Break-down Structure.

XP eXtreme Programming.

1 Introduction

This chapter presents an introduction to the study, including the underlying problem background and research questions. In addition, the aim, objective and delimitation of the study are pre- sented.

In recent years, the Agile methodology has increased its popularity significantly, mostly be- cause its focus on dynamics and flexibility, which provides a successful way to master the ever changing business environment of software development (Cohen et al., 2004; Nerur et al., 2005;

Conboy and Morgan, 2011). The traditional project approach advocates a controlled, strict, and sequential process to obtain high quality and a successful outcome, with emphasis on heavy initial planning to reduce uncertainty, follow up plans, and to monitor and document progress (Engwall, 2003; Hodgson and Cicmil, 2006; Hass, 2007). As this approach was beneficial for disciplines with highly defined processes, other frowned as they realized that responding to change were more crucial than to follow the initial plan (Highsmith, 2002).

The need for increased flexibility is especially requested in the area of software development, commonly known as a volatile context. As a rebellion against the structured and inflexible pro- cesses, several approaches towards managing projects arose during the 1990’s with the common emphasis on closer collaboration between stakeholders, face-to-face communication, frequent deliveries, self-organizing teams and a change adaptive environment (Alliance, 2014c; High- smith, 2002; Larman and Basili, 2003; Appelo, 2010; Cohen et al., 2004). These were the roots of what today is known as the Agile methodology (Highsmith, 2002). The values of the Ag- ile methodology are summarized in the Agile manifesto and its twelve supplementing principles (see Appendix A), funded in February 2001 by seventeen practitioners of different programming methodologies (Alliance, 2014a; Cohn, 2005).

The Agile project process is carried out in an iterative process, in contrast to the traditional sequential one. The success of an Agile project is measured in customer satisfaction, in con- trast to fulfillment of the original plan; requiring less formality, process, and documentation (Highsmith, 2002; Cockburn, 2002). However, planning is still necessary and the success is highly affected by the level of collaboration with the customer (Paulk, 2002). Therefore, the need for management and planning tools in Agile projects to succeed with the communication both within the project and with external stakeholders is present. To address this, a great amount of software solutions have been released, each with its own strengths, but only capable to successfully support specific areas in the Agile project process.

Furthermore, despite that literature elaborating on the Agile process have been published (Co-

hen et al., 2004; Cockburn and Highsmith, 2001; Paulk, 2002; Conboy et al., 2011; Sheffield

and Lem´ etayer, 2013), knowledge of the Agile project process in practice is deficient (Dyb˚ a and

Dingsøyr, 2008; Nerur et al., 2005; Sheffield and Lem´ etayer, 2013). Therefore, it is of interest

to study the Agile project process and its challenges, in order to increase the understanding of

how a project management and planning software tool can support the process. The thesis is

based on a case study at a Swedish Information Technology (IT) consultancy firm, with focus

on their turnkey projects.

1.1 Problem Background

The case company is a small sized IT consultancy firm located in the center of Stockholm, Swe- den. Founded in the early nineties, they have since the beginning been helping its customers to achieve rapid changes in the customers’ respective organization. The case company provides work as IT specialists and through turnkey projects. The former includes delivering specialist expertise and competence enhancement to an organization or other external projects at the lo- cation of the customer, and the latter full responsibility to develop and administrate IT-systems and solutions in-house at the case company’s office. The areas of expertise provided by the case company through these offers are divided among the competence areas usability, requirements and test, system architecture and development, project management, and business intelligence.

The case company promotes Agile practices when possible, but when working at the location of the customer, i.e. specialist services, the specific customer’s project process is used. This implies that the case company adapts to the customer’s solution in these situations. However, regarding the in-house turnkey projects, Agile practices are used in the project process.

Similar to the Agile manifesto, the case company emphasizes interaction between project roles over documentation and formal processes. Nevertheless, as a consequence of this, an increased need for information dissemination throughout the project process has been identified. To manage this, the case company wants to acquire a project management and planning software tool to support the entire project process and all involved project roles. However, awareness of areas in the project process in need of support is not entirely clear.

1.2 Aim and Objective

The overall aim of this study is to contribute with theory around the Agile project process within software development, in order to improve the understanding of its challenges.

The objective of the study is to investigate the application of the Agile project process within software development and identify potential challenges. Furthermore, the objective is to in- vestigate how a project management and planning software tool can support the Agile project process within software development.

1.3 Research Questions

In order to fulfill the aim and objective of this study the following research questions have been formulated:

RQ 1: Which prominent areas need to be supported in the Agile project process within software development?

RQ 2: How and in what way can a project management and planning software tool support the Agile project process within software development?

1.4 Starting point of the study

In the context of this thesis, there are two starting points that are beneficial for the reader to be aware of. Firstly, the company studied in this thesis wish to remain anonymous. Therefore, throughout the report it will be referred to as the case company.

Secondly, this thesis is my final work to achieve a Master of Science in Industrial Engineering

and Management. Beside this, the thesis is also included in my work to achieve a Master of

Science in Engineering, degree Programme in Computer Science and Engineering. Therefore, certain technological aspects and components will be given more attention than it would have in the traditional Master of Science thesis at the school of Industrial Engineering and Manage- ment.

1.5 Delimitation

The study is based on the context of the case company. Therefore, the investigation is delimited to the current project process and the opinions belonging to the employees in, and the customers of, the case company. Since the case company operates in the IT consultancy business area, the findings obtained will mostly reflect concerns of interests in such a context, with focus area in software development. The case company performs both self-managed in-house turnkey projects as well as externally located projects. Based on the nature of the investigation, as well as access to relevant data, the study will be delimited to the in-house project process, which will be reflected in the results possible to obtain. Nevertheless, the belief is that some discoveries will provide theoretical contribution and insights of value for other professionals.

1.6 Thesis Outline

The report consists of a number of chapters discussing different areas of the work carried out.

The outline is as follow:

Chapter 2 - Theoretical Framework: The theoretical framework for this study is presented. The literature study underlying the theoretical framework has been conducted for two purposes; firstly to provide me with the basic conceptual knowledge needed and secondly to study what current research claims.

Chapter 3 – Methodology: The design of the study and the methods chosen for data gathering and data analysis are presented and discussed. A discussion of the research’s reliability, validity and generalizability, as well as its ethical issues are elaborated upon.

Chapter 4 - The Case Company: Presents the description of the case company in order for the reader to understand the context in which this study was carried out. The company’s project process is described and divided into the areas; project initiation, on- going project, project closure, project roles, and requirements engineering. Furthermore, the case company’s project infrastructure is addressed.

Chapter 5 - Empirical Findings & Analysis: The empirical findings are presented and analyzed according to the main areas identified in chapter 4; the project process and the project infrastructure.

Chapter 6 - Discussion: The analysis of the most prominent empirical findings is fur- ther studied in relation to the theoretical framework. The discussion is divided into the subchapters: the project process, the project infrastructure, the need for a project man- agement and planning software tool, and the Integration model. In the final subchapter, the Integration model, a model visualizing the areas in which a project management and planning software tool must interact with the Agile project process is presented.

Chapter 7 – Conclusions: The main findings obtained through the study are summa-

rized in order to answer the research questions. Besides answering the research questions,

the chapter also contains specific recommendations to the case company.

Chapter 8 – Final Reflections of the Study: Final reflections of the study are

presented. Firstly, a brief discussion of the study from a sustainability perspective is

given. Secondly, an area for future research is presented.

2 Theoretical Framework

This chapter presents an initial review of the existing literature related to Agile project process in relation to software development. The aim is to provide the reader with a brief introduction to the area of study, as well as terms that will be recurring in the report.

The theoretical framework for this study is divided based on two purposes; the concept of Agile and the current research, with the aim to provide the reader with two different angles on the subject. In order to understand the need for the Agile methodology, subchapter 2.1.

briefly covers traditional project management aspects, as well as the main critique against it.

Thereafter, subchapter 2.2. describes the Agile methodology in more detail, in order to increase the conceptual understanding for the area of study. Lastly, subchapter 2.3. presents the process and main artifacts related to the most project management oriented Agile method, i.e. Scrum.

This subchapter is important since it covers many terms that will be recurring.

Beside the more theoretical oriented aspects, the theoretical framework also includes more recent research. The aim with these subchapters was to establish a foundation based on the claims in research and to identify aspects to which the findings of this study was compared. This is covered in subchapters 2.4, 2.5, and 2.6.

2.1 Traditional Project Management

”If you fail to plan, you are planning to fail!” - Benjamin Franklin

Traditionally, projects were seen as approaches to carry out predefined tasks and project man- agement as the process of planning, tracking and controlling the execution towards its final goal (Andersen, 2008; Maylor, 2010; Packendorff, 1995). According to Engwall (2003, pp. 791), the traditional project management theory deals with two principle problems;

1. ”how to structure and plan project activities in order to meet the stipulated objectives, and”

2. ”how to ensure that project activities decided upon are executed according to the stipu- lated plan.”

Engwall (2003) is supported by Matta and Ashkenas (2003) and Packendorff (1995), which

argue that traditional project management advocates focus on detailed initial planning, trying to

predict all needed activities and the time they will take to accomplish; only to then delivery what

is referred to in the article by Hass (2007) as the ’Big Bang’, the finalized end product.

The early approaches within software development were, in coherence with traditional project management, insisting on defining all tasks in the early stages of the project, only to then carry them out in a strictly sequential manner. The process most often referred to within software development is known as the Waterfall model, depicted in figure 1, and includes the phases requirements specification, analysis, design, implementation, testing, and maintenance (Brookshear, 2009; Royce, 1970).

Figure 1: The Waterfall model (Inspired by Royce (1970, pp. 329)).

In order to achieve the identification of manageable tasks and to structure the project, several methods and techniques have reached the market with the promise of contributing to a successful outcome. According to Packendorff (1995), most of these methods aim to find the optimal sequence of activities and how to allocate the appropriate resources most beneficially. During the planning phase, Work Break-down Structure (WBS), Critical Path Analysis (CPA) and Gantt charts are commonly used in order to design the project (Maylor, 2010). The examples given are all beneficial when you need an overview of the project, or need to monitor the progress, but do they really measure success?

The primary approach to measure the success of traditional project management is through the Iron triangle, depicted in figure 2 (Atkinson, 1999; Hodgson and Cicmil, 2006; Wateridge, 1998). The Iron triangle, also referred to as the Golden triangle, encompasses the success criteria; time, cost, and quality (Atkinson, 1999; Westerveld, 2003; Hodgson and Cicmil, 2006;

Wateridge, 1998).

Figure 2: The Iron triangle (Inspired by Atkinson (1999, pp. 338)).

Atkinson (1999) criticizes the facts that the properties of the Iron triangle is quite questionable as point of reference for success. He argues that time and cost only can be discussed as estimations, made in the point of time where the least is known about the project. Proceeding with quality, he problematizes the property of quality as a phenomenon emerging from people’s attitudes and beliefs, most likely to change during time. His critique is supported by Wateridge (1998), who consider the Iron triangle as a quite narrow view, requesting the inclusion of all stakeholders’

views in the success criteria for a project. Continuing on the same path, through common definition of the phenomenon success among key stakeholders and continuous tracking and measuring, the outcome of the project is easier to predict (Thomas and Fern´ andez, 2008).

If the interpretation of the starting quote of this section and the following presented dialogue is literal, one could consider planning as the key to success. Planning is crucial to the success of any software development project but, taken to the extreme, it could induce the false comfort in the belief that there is a way to do things right the first time, disabling the project manager’s ability to adapt to a changing environment (Cohn, 2005; Highsmith, 2002; Paulk, 2002). Matta and Ashkenas (2003) elaborate further on the belief that future is predictable and that everything can be estimated, but comes to the conclusion that no one can predict every variable in the future and even less plan for it.

Traditional project management has received considerable critique in literature for the use of highly plan-driven methods to reach the desired outcome, preventing the flexibility of the project to adapt to changes as well as risking to omit substantial features in the plan (Highsmith, 2002;

Matta and Ashkenas, 2003). Another issue with traditional project management discussed by Cohn (2005), in the context of software development, is the traditional approach of planning through activities, rather than features. The author claims that the use of Gantt-charts and WBS identifies activities to be performed, and that the progress of the project is measured in accordance to these activities. This would consequently imply needed identification of missing activities rather than missing features, when tracing the project progress in accordance to the promised outcome. Nevertheless, the problem as he describes it, is that the customer has no value in the completion of the activities; rather the customer value lies in the features delivered.

Engwall (2003) acknowledges that the methods used in traditional project management usually are described as necessary conditions for project success. Nonetheless, as pointed out in the earlier discussion these methods have some weaknesses. The traditional project management as universal approach to projects is further questioned by Engwall (2003), who stresses that more current findings address the success of projects as dependent on context-specific circumstances, rather than an universal process.

2.1.1 The Customer Role in Traditional Project Management

Within the area of traditional project management, the customer role is described as an external

stakeholder to the project, i.e. people outside the project team, with the responsibility to

provide information and criteria important for success (Maylor, 2010; Atkinson, 1999). During

the first phase of requirements gathering and specification, the involvement and collaboration

is high and the customer plays an important role. In the following phases, the work is managed

isolated within the project team and the customer involvement is limited to decision points

(Karrbom Gustavsson and Hallin, 2013; Nerur et al., 2005; Conboy and Morgan, 2011; Ceschi

et al., 2005).

2.2 The Agile Methodology

The environment of today’s IT projects is turbulent, volatile, and uncertain, where the ever changing circumstances could cause tremendous problems if a project team is unable to cope with the changes; requirements from yesterday might not be relevant tomorrow (Highsmith, 2002; Appelo, 2010; Cockburn, 2002; Hass, 2007). Where traditional approaches to project management risked being overwhelmed by change, the Agile methodology, with its core in adaptability and change responsiveness, is more favored to maneuver and embrace the non- static environment (Cockburn, 2002; Appelo, 2010; Highsmith, 2002; Cohn, 2005).

The Agile approach is perhaps the most pronounced shift from the Waterfall model (Brooks- hear, 2009; Larman and Basili, 2003). It covers a variety of methods, such as Scrum, eXtreme programming (XP), and Feature-driven-development (FDD), each with its own certain char- acteristics, but where Scrum is the most management oriented (Gustavsson, 2011; Highsmith, 2002; Appelo, 2010; Dyb˚ a and Dingsøyr, 2008; Abrahamsson et al., 2003). Nevertheless which methodology that is considered as most appropriate for your cause, there are some common characteristics derived from the Agile manifesto and its supportive twelve principles (see Ap- pendix A), funded in February 2001 (Alliance, 2014a). The Agile manifesto states:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

According to Cohn (2005), all involved parts, including the customer, should work as one team to evoke a unified mindset of the domain, requirements, and functionality of what to be built (Hass, 2007). This is supported by Paulk (2002), who argues that without a functioning customer collaboration and incremental development process, the Agile project would most certainly fail. Cockburn (2002, pp. 13) further claims that ”the time and money spent on guessing at the users’ response to the delivered system would be better allocated to deal with their response on seeing the real system”. Therefore, in order to response to changes, the Agile approach advocates an iterative and incremental project process that delivers finalized software receptive for feedback at the end of each iteration (Cohn, 2005; Highsmith, 2002).

Because of the Agile resistance towards long-term planning and documentation, in combination with its favor of a roughly specified end result, the methodology have been criticized to be a disguise for undisciplined hacking (Paulk, 2002). Appelo (2010) declares the fact that Agile development did arose as a reaction to the formal approaches, but also highlights the repudiation from undisciplined programmers, “chaotic” processes, and low-quality products, describing it as the middle row between order and chaos. The belief that Agile project management should not involve planning is commented on in literature, where Cohn (2005) argues that Agile teams in fact do a lot of planning, but more evenly distributed throughout the project. Paulk (2002) also addresses the issue by distinguishing between planning for change and not planning at all.

The success of an Agile project is according to Highsmith (2002) measured through the delivery of customer value, however it is defined by the customer. In contradiction to the traditional project management, which put much effort on identifying and carrying through critical tasks, the Agile methodology values, plan, and deliver continuously throughout the project process in relation to the currently requested features and business priorities. (Cohn, 2005; Hass, 2007).

To succeed with the aforementioned, a frequent and honest two-way-communication between

the customer and developer team is required in order to fully utilize the important feedback- loops, useful to navigate the project in the desired direction (Cohn, 2005). Therefore, the Agile methodology encompasses continuous planning throughout the project, focusing on creating a plan that is currently useful (Highsmith, 2002).

2.2.1 The Agile Project Process

As mentioned in earlier sections, the Agile methodology advocates an iterative project process with incremental development. It tries to balance flexibility and structure, always striving to provide a finalized product into its intended environment at the end of each iteration (Highsmith, 2002; Appelo, 2010). In order to achieve this, the Agile project process is divided into timeboxed iterations which all encompass the interrelated work of analysis, design, coding, and testing.

A timeboxed iteration means that the iteration always should finish in time, even if it would require removal of planned functionality (Cohn, 2005). In addition to this, Highsmith (2002) and Appelo (2010) illuminate the process of double-loop-learning, i.e. the need to continuously test the team’s knowledge through retrospectives ¹ and customer focus groups to provide feedback that enables learning. A visualization of the Agile project process is depicted in figure 3.

Figure 3: The Agile project process (Inspired by Appelo (2010, pp. 324)).

In the Agile methodology planning is considered as an activity; where the activity itself is more important than the actual plan (Paulk, 2002; Cohn, 2005). The plan should be created in relation to the current situation, encourage change, and as earlier mentioned, be redesigned through the entire project process to the extent that it always is useful at the moment (Cohn, 2005; Highsmith, 2002). According to Cohn (2005, pp. 29), the concern of planning in Agile projects could be divided into three levels;

• Release: executed in the beginning of the project process, aiming to determine scope, schedule, and resources for the project. It should always reflect the current situation, whereby it is encouraged to continuously update it throughout the project process at each iteration start. Generally a length of 3-6 months, whereby larger projects might consist of several releases encompassing several iterations, where each ends with a customer demo.

1

Time allocated to reflect upon how the team is doing and find ways to improve.

• Iteration: at the start of each iteration, based on the accomplishment in the preceding iteration, the Product owner identifies and prioritizes the work to be carried during the forthcoming iteration. The iteration is generally a length of 2-4 weeks.

• Daily: carried out on a daily basis where team members discuss and coordinate their daily efforts.

2.2.2 The Agile Team

When describing the properties of a software project, Appelo (2010) refers to it as a complex adaptive system because of its nature in multiple integrating and interacting parts, internal rules, and how it evolves over time (Highsmith, 2013; Kirk and Tempero, 2012; Larman, 2004;

Anderson, 2004). The author, Appelo (2010), attributes the general system theory for the recognition of several attributes; self-construction, interaction among team members are just as important as the team itself, and interaction with the surroundings among others. ”It is widely acknowledged that findings in complexity science can be applied to social systems, i.e. software development or management” (Appelo, 2010, pp. 50), whereby the interest and relevance of system theories in the discussion of software development is defended. Despite his claim, he still questions how far it is possible to copy the concepts from one discipline to another. In addition, he present the ongoing debate of which scientific concepts that can be applied where, and whether scientist agrees upon the application of complex system theory to software devel- opment (Appelo, 2010). However, nevertheless from where the roots can be derived, an Agile software team is defined trough the characteristic of; self-organizing, goal-oriented, and constant collaboration (Gustavsson, 2011; Highsmith, 2002; Cockburn and Highsmith, 2001).

The Agile methodology relies heavily on the individual competence of people, believing that no matter which process they use, a competent team will accomplish their assignment, as well as no process can compensate for an insufficient team (Cockburn and Highsmith, 2001). Even though the earlier mentioned characteristics of an Agile team are equally important for the success of an Agile project, the constant collaboration is highly important for the knowledge transfer between, and skill development of, team members, where tacit knowledge account for the majority of knowledge to be transferred. Defined as a personal quality, hard to formalize, communicate, and reproduce (Nonaka, 1994), tacit knowledge is in nature hard to communicate and transfer. Therefore, it is important with an environment where questions and answers can flow naturally and where team members are willing to share and work together (Paulk, 2002;

Appelo, 2010; Dyb˚ a and Dingsøyr, 2008; Nerur et al., 2005). For that reason, the belief that understanding comes from face-to-face contact rather than from documentation, is an important aspect of the Agile methodology. This leads to the conclusion that Agile teams are optimally gathered at the same location (Highsmith, 2002; Cockburn, 2002; Cohn, 2005; Cockburn and Highsmith, 2001). In addition, Cockburn and Highsmith (2001, pp. 132) claim that ”people working together with good communication and interaction can operate at noticeably higher levels than when they use their individual talents”, which further strengthen the argument of a team gathered at the same location. Therefore, Agile teams are eager to develop not only the individual competencies, but also the team’s collaboration skills.

The roles within an Agile team can roughly be divided into four categories; the developer team,

the project leader, the Product owner and the customer (Cohn, 2005). Cockburn and Highsmith

(2001) stress the fact that in order to decrease the time from feedback to decision, the customer

should be made available to the team, or in the best circumstances a part of it. In addition,

Paulk (2002) addresses functioning, i.e. close and effective, customer collaboration as one of

the most significant enablers for the Agile methodology. When elaborating on the subject, the

study carried out by Dyb˚ a and Dingsøyr (2008) revealed contrariwise results, both indicating

that an on-site customer was valuable to all developers, but also that it could be a stressful role not possible to sustain for a longer period of time. Based on aforementioned one can argue that a close collaborative customer relationship is a prerequisite for an Agile method, but the optimal solution might not be to have it on site.

Even though literature describes the Agile roles as clearly separated into the earlier described four categories, it was indicated through the investigation carried out by Conboy et al. (2011, pp.

51) that in order to be a good Agile developer you must master all trades, i.e. ”be a developer, a tester, an architect, a customer, and a quality assurance expert among several other software related things”. The authors acknowledge this as a challenge of the Agile methodology but also propose activities to master it. It is proposed that pair programming and pair rotation can be used to distribute knowledge and to facilitate learning, that encourage of task self-assignment can increase the learning, and that specific roles can be reintroduced when it would benefit the team.

The optimal size of an Agile team is dissimilar depending on which literature you consult.

However, even though no exact number can be assigned, there seem to be a recurring recom- mendation between five to ten members, whereat larger teams are encouraged to be divided into smaller teams creating teams of teams (Paulk, 2002; Cohn, 2005; Dyb˚ a and Dingsøyr, 2008;

Gustavsson, 2011; Cockburn and Highsmith, 2001; Appelo, 2010). The description of each team role is presented in table 1, and the structure is depicted in figure 4.

Role Description Source

Developer team

The general role of the software developers, includ- ing the members responsible for producing and deliv- ering the requested functionality. Described as self- organizing, self-managing, and cross-functional.

Cohn (2005), and Schwaber (2004)

Project man- ager

The primary focus of the Agile project manager is di- rected on the people factors, e.g. talent, skill, and com- munication, rather than formality, process and docu- mentation. The mission is to energize people, and to create a safe and friendly environment where creativ- ity can flourish. This also applies to the customer re- lationship where, instead of agreeing upon a detailed contract, a collaborative relationship should be initi- ated.

Cockburn (2002), Cohn (2005), Ap- pelo (2010), and (Cockburn and Highsmith, 2001)

Product owner

Referred to as the active customer, the Product owner is a representative from the customer with the respon- sibility to consolidate a common project vision, pri- oritize work, and to steer the project in a profitable direction. It aims at the deliverance of a final product as desired from the perspective of the customer and/or all stakeholders.

Cohn (2005), Gus- tavsson (2011), Schwaber (2004) and Appelo (2010)

Customer The person, or unit, who has initiated the project. If the project is internal, the Product owner and cus- tomer role often are combined.

Cohn (2005)

Table 1: Description of the Agile roles.

Figure 4: The structure of an Agile team (Inspired by Ambler (2005)).

2.3 The Scrum Method

Scrum is described to be the more project management oriented among the Agile methods (Highsmith, 2002; Dyb˚ a and Dingsøyr, 2008). The method promotes, like the rest of the Agile methods, an iterative and incremental project process, where an increment of the final product is produced at the end of each iteration (Schwaber, 2004). However, Cohn (2009) elaborates on the two concepts’, i.e. iterative and incremental, actual meaning and the weaknesses inherent when only succeeding with one of them. In addition, he also claims that these disappear when you combine them, as done in Scrum. He further argues that Scrum in a successful way combine the belief of the iterative project process, i.e. that there is no way of producing a correct feature the first time, with the incremental one to fully develop one feature and then move on to the next. The requirement to succeed with the aforementioned is to continuously produce a working software ² that provides value to its users and, or, customers.

2.3.1 The Scrum Roles

The roles in a Scrum team are similar to the general Agile team roles and share their character- istics. Exception is the project leader, who is referred to as the Scrum master (Schwaber, 2004;

Gustavsson, 2011). According to Cohn (2009), the Scrum master has no authority in the team, functioning as a servant-leader with the removal of obstacles and solving problems that hinder the progress of the team as priority. The informal role is supported by Schwaber (2004), who also addresses ensuring compliance to Scrum rules and practices as one of its responsibilities.

Both authors stress that the Scum master should be considered as a facilitator for the team to reach their goal in an efficient manner.

In some occasions though, when the project includes an external customer, some Scrum teams choose to expand the role of the Scrum master to include both the role as a team coach and the role as project manager. An alternative approach is to assign a specific project manager, responsible for the customer contact, and communication between customer and Scrum master (Gustavsson, 2011).

2

Working software is software that is both complete and potentially shippable (Cohn, 2009, pp. 158).

2.3.2 The Scrum Artifacts

When working according to Scrum, there are certain artifacts and concepts particularly related to the project process; product backlog, sprint backlog, sprint, daily scrum, sprint review meeting, retrospective, user stories, task board, and burndown chart. These are described in more detail in table 4, and combined they create the flow of the Scrum project process as depicted in figure 5.

Concept/

Artifact

Description Source

Product backlog

Used for requirement management, and is the respon- sibility of the Product owner. The product backlog consists of a prioritized list of functional and non- functional requirements expressed in the words of the customer. One project equals one product backlog, and it should be frequently re-prioritized in order to affirm that the most valuable functionality from the customer perspective is worked on.

Schwaber (2004), Cohn (2009), Kniberg (2006),

& Gustavsson (2011)

Sprint backlog

Defines the requirements selected from the product backlog which are to be included in a Sprint and the work, or tasks, needed to be carried out in order to deliver in accordance. When decided upon, only the developer team is allowed to change it.

Schwaber (2004), Cohn (2009), Kniberg (2006),

& Gustavsson (2011)

Sprint Combining iterative and incremental work, sprints lies in the core of Scrum and is the term corresponding to common Agile iterations. The timebox of a sprint is appointed by Schwaber (2004) to 30 consecutive cal- endar days and should never be extended. During this time the developer team works together on the tasks identified in the sprint backlog.

Schwaber (2004), Cohn (2009),

& Gustavsson (2011)

Daily scrum As a mean to facilitate the constant control of the project, daily scrum meetings are used to synchronize the work of all team members. For a time of approx- imately 15 minutes, the team get together and each one answers the questions: What have you done since the last meeting; What will you work on until the next meeting; and Are there any obstacles?

Schwaber (2004)

& Gustavsson (2011)

Sprint review meeting

Lies in the termination of each sprint, where the devel- oper team demonstrates their progress so far for the Product owner. This enables direct feedback from the customer representative. After the presentation, all participants collaboratively decide on what the team should work on next.

Schwaber (2004)

& Gustavsson (2011)

Retrospective After each sprint review meeting, and before the next sprint planning, time is allocated for the team to re- flect upon how they are doing and to find ways to improve. Typically aim to answer the two questions;

What did we do well? and What can we do better?.

Schwaber (2004)

& Gustavsson (2011)

Table 2 – Scrum concepts and artifacts (continued on next page).

Continued from previous page.

Concept/

Artifact

Description Source

User stories A common way in Scrum, and the Agile methodology, to express requirements is to use user stories. User stories are short, simple descriptions of features told from the perspective of the user.

Cohn (2005) &

Kniberg (2006)

Task board The task board provides an easy graspable way to present which tasks that are worked on and which ones that are completed. Through the commonly used columns; To do, In process, and Done, it provides the team an indication of the amount of work left.

Cohn (2005), Cohn (2009), Gustavsson (2011) & Kniberg (2006)

Burndown chart

Used to provide an indication of how the team per- forms in relation to time. Consists of two axes (re- maining work in hours & total time of sprint) and a line indicating the most probable completion of work at a certain time as a point of reference.

Cohn (2005), Schwaber (2004), Gustavsson (2011) & Kniberg (2006)

Table 2: Scrum concepts and artifacts.

Figure 5: The Scrum process (Inspired by Schwaber (2004, pp. 6) and Gustavsson (2011, pp.

129)).

The Scrum project process is initiated by the Product owner and the customer who compiles

an initial product backlog, consisting of the requirements that, when turned into functionality,

will deliver the vision of the system to be developed (Schwaber, 2004; Kniberg, 2006). Schwaber

(2004) declares that changes in the product backlog correspond to a change in business require-

ments, which will consequently affect the velocity of which the developer team can transform

the backlog into functionality. However, important to realize is that even though the product

backlog is managed by the Product owner, it is entirely up to the team to decide on the solution,

and how to reach the goal (Gustavsson, 2011; Schwaber, 2004).

2.4 The Project Process in Software Development

Dubakov and Stevens (2008, pp.15) state that almost any development process includes activities as; requirements management, planning, tracking, quality assurance, and feedback gathering.

Even though the basis for software development incorporate the same set of activities, these can be, and are, implemented in endless of ways using many different methods (Kirk and Tempero, 2012). The methods used ought to be efficient, i.e. meet budget, time, and expectations (Coleman, 2005), whereby it is argued by Abrahamsson et al. (2003) that project management activities are needed in order to enable the proper execution of development tasks and to reach a successful project result.

The Agile methodology is argued to outshine traditional management approaches, i.e. plan- driven, in several challenges, but there are still some to beware of. Conboy et al. (2011) discuss in their article the ”people” challenges related to Agile project process. Among the issues dis- cussed, the increased transparency between customer and developer team is noted. The frequent interaction between the customer and the whole team, demands all team members to possess higher domain knowledge of the customer’s business in order to maintain confidence. The re- sponses given in the investigation revealed evidence of real situations where deficient customer domain knowledge has evoked a disengaged customer and dysfunctional communication. How- ever, in another article published the same year, it is argued that the more transparent project process is a particular strength of Agile approaches (Conboy and Morgan, 2011), a statement which is supported by several, not least the Agile manifesto.

Furthermore, Conboy et al. (2011) elaborate on the impact true understanding of the Agile values and principles can have for the outcome. They present a case of two teams operating in the same organization, participating the same Agile course, and still obtaining different project outcomes. The cause was traced to intangible combinations of resources, whereby the authors claim that formal training is not sufficient without continuous hands-on training.

Despite discussing several challenges related to the Agile project process, the authors omit the impact caused by failing to master these challenges. Neither do they elaborate on the situation or challenge when the team is performing by excellence, but the customer’s work or engagement is inadequate and actions to counter this.

In the study carried out by Kirk and Tempero (2012), the authors investigate the practices used for software development in three Small and Medium Enterprises (SME) located in New Zealand. The aim of the study was to better understand how successful companies adapt its software development practices to its specific context, implying that ”best practices” are context-dependent. The authors initiate the report by questioning the prescriptive nature of models, and the assumptions on what constitute ”best practice” they communicate. They highlight that most companies stating following a certain methodology or process model, in reality only incorporate parts of it, i.e. adapting it to its certain context, or are not adopting the purpose of it. Nevertheless, they further claim that the less formal approach can work as well as the more formal ones, especially in smaller organizations (Kirk and Tempero, 2012). The absence of formal and standardized project process models is supported by Coleman (2005), who concludes in his investigation that Irish SMEs are using ”good enough” project processes adjusted to fit their specific needs instead of standardized ones.

Despite the fact of being written for more than ten years ago, Boehm (2002) acknowledges

that neither traditional nor Agile approaches are sufficient when both rapid delivery and high

assurance is requested, whereby the author claims that a mix of these two is needed. Briefly, the

author also addresses the risk of tacit knowledge shortfalls within Agile methods if an on-site

customer is unrepresented. This was, he argues, reduced through documentation in traditional

project management approaches. Similar concerns were aired by Conboy et al. (2011), who claim that despite minimal documentation is emphasized; the appropriate documentation can be seen as a facilitator for communication. This is, as also noted by the authors arguing for supportive documentation, inconsistent with the general view of Agile practices where docu- mentation beside the code is discouraged (Nerur et al., 2005). Nonetheless, as indicated by Sheffield and Lem´ etayer (2013), a one-size-fits-all approach to software development agility is highly inappropriate if aiming for project success. Instead they argue that the project pro- cess should be tailored to fit the current needs, combining traditional plan-driven features with Agile methodology where a more flexible and adaptable approach to project management and software development is adopted (Cockburn and Highsmith, 2001).

Baskerville et al. (2011) have investigated how the meaning and practice of Information System Development has evolved over time and based on their findings they speculate on what follows a decade of agility. ”The studies reveal a two-stage pattern in which dramatic changes in the market causes disruption of established practices and process adaptations followed by consoli- dation of lessons learned into a once again stable software development process” (Baskerville et al., 2011, 534). They stress that the most recent study from 2008 revealed that organizations were combining plan-driven and Agile project processes, allowing workflows to cross between, a finding which is in line with the aforementioned studies. For the future they anticipate this to evolve further, to the point where the plan-driven and Agile software development are indis- tinguishable.

The change towards indistinguishable processes is in line with the need expressed by Morgan and Maurer (2006), who argue that lack of formal project management practices is a significant driver for project risk. They acknowledge that the power of such practices lies in the ability to create well-defined patterns and directives for coordinating interactions and integrating the various elements of a project. Furthermore they note the strength of formal milestones as a mean to monitor the progress and to detect possible deviations throughout the project (Morgan and Maurer, 2006). The incorporation of a formal process tailored to its specific needs, could therefore be argued to enhance the prospects for project success, even though it would diverge from the foundation of the Agile methodology.

2.5 The Project Process Tools in Software Development

According to the Agile manifesto, individuals and interactions should always be favored over processes and tools (Alliance, 2014a). Despite this, Appelo (2010, pp. 22) claims that ”plenty of tools are described and promoted in Agile literature”. Used for automated testing, continuous integration, and daily builds, as well as requested to distribute information, he describes the role of the tool as a mean to strengthen motivation, communication, and collaboration in teams.

To further expand his discussion, he return to the sense of the Agile principle and state that tools can be necessary, but they are never sufficient for success, implying that human analysis of the gained information always is needed in order to decide on action (Appelo, 2010).

When elaborating on the challenges facing organizations planning to adopt the Agile methodol-

ogy, Nerur et al. (2005) highlight the technological matters as critical, where the right tools are

considered as prerequisites for success. The authors mention tools that support and facilitate

an iterative project process, version control, configuration management, or other Agile tech-

niques as examples, but do not explicitly refer to tools supporting the managing of an Agile

project process, i.e. planning, monitoring etc. Just like consolidated by Appelo (2010), the

authors aware the readers that tools alone can guarantee the successful outcome of a software

development project.

As it can be interpreted by the reasoning related to Agile tools in literature, the majority of tools supporting the Agile project process are development focused. This is supported by Dubakov and Stevens (2008), who argue that the lack of tools supporting the management of Agile projects has caused managers to use old-fashioned tools to plan and monitor projects.

In the traditional approaches, where a linear project process with clear requirements and little change expected is favored, planning tools can be used to optimize the management of a project (Sheffield and Lem´ etayer, 2013). However, when working Agile this can cause more problems than it resolves. The traditional tools are not designed for, and therefore do not support an Agile project process, omitting concepts crucial for the Agile team, e.g. product backlog, burndown chart, and task board (Dubakov and Stevens, 2008).

But is an Agile project management tool necessary? Does not the Agile manifesto state; ”In- dividuals and interactions over processes and tools”? Yes it does, but following the similar reasoning as when parting out the benefits with a slightly more formal project process in the previous subchapter, it can be argued that a tool can enhance the activities of requirements gathering, iteration planning, progress tracking, and reporting, with minimum effort and side effects (Dubakov and Stevens, 2008). The Agile methodology increases the requirements on social interaction and the skills of the team members, where the absence of sufficient user and executive project support is enough to kill a project (Conboy et al., 2011; Cockburn and Highsmith, 2001).

Commonly when discussing the tools used by Agile advocates, the paper, pen, and whiteboard are mentioned and often included in the description of how an Agile team work (Cohn, 2009;

Gustavsson, 2011; Kniberg, 2006). Beside the benefits of easy learning, easy usage, and flexibil- ity, these primitive tools entail some drawbacks, such as reusing data, back up data, and remote access to the data (Dubakov and Stevens, 2008). The similar argumentation is presented by Dubakov and Stevens (2008) related to solutions such as Excel, which despite cheap, easy, and providing means to manage the product backlog and iteration burndown charts, still do not provide remote access to the data, sufficient visibility and reporting, automated time updates, as well as lacking the foundation of business logic. The lack of sufficient support has led to the situation were organizations combine several tools to address individual problems, inducing duplication of work trying to keep all up to date.

2.6 The Integrated Software Engineering Environment

Related to the project process in software development, there are a number of systems that need to be integrated in order to support the project process automatically, e.g. through automatic builds (Brown, 1988; Lehman and Stenning, 1985). When the complexity of systems and projects increases so do the aspects to take into consideration, such as storage locations, exchange of information etc. Brown (1988, pp. 126) highlights a number of issues to consider, including that ”the management of a software project becomes much more difficult, in particular, control of the development and maintenance process and ensuring its continued progress”.

In order to embrace the entire development life cycle, there is a concept known as Integrated

Project Support Environments (IPSE) aiming to provide the support needed. The aim with

these environments is to improve production efficiency and quality, through the provision of

complete set of support tools and integration needed throughout the entire project process

(Brown, 1988; Lehman and Stenning, 1985). IPSE are similar to a Software engineering envi-

ronment and refer to ”a set of management and technical tools to support software development,

usually integrated in a coherent framework” (Brown, 1988; Lehman and Stenning, 1985; Howe,

2010).

Even though discussing the concept of IPSE, Brown (1988, pp. 133) addresses integration as necessary in order to ”ensure that the complete project life cycle is supported in a convenient, and flexible manner/.../”. In similar, despite investigating the benefit of integrated systems in industrial project planning, the research carried out by Winstanley et al. (1993) demonstrated that integrated systems provided a comprehensive and flexible project support toolkit.

Nevertheless, as one can understand the importance of an integrated environment, Lehman and Stenning (1985) differentiate between ”integration” and ”purposeful integration”. The authors claim that traditionally, methods and supporting tools generally are not conceptually alike, nor have directly compatible interfaces, whereby modification is needed to link them into a single system. Further on it is argued that reworking ad hoc solutions cannot provide the conceptual unity or procedural coherence made available through purposeful integration, which is based on support tools with common theory and within a unified conceptual framework. Therefore, the aim should be to strive for purposeful integration in order to facilitate the project most successfully.

A more recent, less scientific research oriented article, is written by Rusick (2011) in order to clarify why system integration is critical to growth. The author highlights a number of interesting points relevant in the topic of why an integrated environment is advantageous. The main point is; Data at one location is efficient. Having to enter data only once decreases the error rate, as well as the time needed to keep all storage locations up to date. It is frustrating to have similar information stored in multiple places. In addition, several storage locations induce the risk of data being out of sync, referred to as lack of data integrity.

Based on the aforementioned discussion, an integrated software engineering environment is

worth striving for if aiming at quality, flexibility and efficiency. Therefore, as also supported by

Rusick (2011), system integration should be a part of the IT strategy.

3 Methodology

This chapter presents and evaluates the strategy and methods chosen for the study. In addition, a discussion of the study’s quality is presented.

The traditional perception of research is according to Alvesson and Sk¨ oldberg (1994) the process of creating an objective, and interpretation of the same, through the adaptation of a scientific approach. In order for me to answer the research questions, I needed to understand underlying processes, activities, perceptions, and reflections, where the successful outcome was dependent on me to interact and engage with the studied. This kind of in-depth knowledge is subjective in nature whereby a qualitative approach was chosen (Alvesson and Sk¨ oldberg, 1994; Collis and Hussey, 2009; Corbin and Strauss, 1998).

Since the result should be based on underlying similarities and opinions in reality, one could assume that the research process was designed inductively. However, Alvesson and Sk¨ oldberg (1994) describe the inductive approach as a risky leap where compilation of individual aspects into a common truth is common. On the other hand, the authors also argue for the fact that researchers that are well informed in the area of investigation can hamper their own abilities, due to the influences of earlier stated fact. Therefore, the design of the research process was inspired and influenced by an abductive approach (Alvesson and Sk¨ oldberg, 1994; Collis and Hussey, 2009). This decision allowed me to alter between empirical data collection and studies of earlier research, increasing my ability to complement my knowledge base in relation to my emerging findings.

The study has been designed as a case study with a small sized Swedish IT-consultancy firm as case company and single study object. Based on the time available, the kind of deep analysis of a unit’s state needed was considered as hard to obtain without affecting the quality negatively if several units were to be studied. Therefore, I decided to focus on one specific unit from where context general insights were thought to be possible to derive. Denscombe (2000) does however stresses that the credibility of the generalizations derived are sensitive to critique, whereby the researcher must thoroughly state the context to which the findings applies. However, the decision to conduct a case study was not based entirely on the context of a single study object rather than the general wide range. The advantage to use and combine a variety of methods suitable for the situation had a major influence, enabling me to collect data from different sources providing me with a holistic perspective of the reality. This is listed by Denscombe (2000) as one of the advantages related to case studies, together with the decreased need to control the phenomenon, since the aim is to study the situation as it naturally occurs.

3.1 The Abductive Case Study

The work carried out during this study can for convenience be divided into three main phases:

problem identification, data collection, and analysis. The case study was designed as depicted

in figure 6, during which a variety of methods were used for different purposes. It can easily

be interpreted that the design was strictly linear and that the activities were isolated from one

another. However, so was not the case in practice. Instead, the activities were interrelated and

carried out in a more iterative approach, increasing my ability to work flexible and adapt to

emerging findings.