The impact of agile methods of working on the mechanisms of control

(1)

The Impact of Agile Methods of Working on

the Mechanisms of Control

Anna Zdravkova 11282398

MSc in Business Administration – Digital Business Track

Submission date: 22 June, 2018

Thesis Supervisor: Prof. em. dr. ir. Hans J. Oppelland

Second reader: Prof. Dr. Hans Borgman

Word count: 17.418 words excluding Appendices

(2)

Statement of originality

This document is written by student Anna Zdravkova who declares to take full responsibility for the contents of this document.

I declare that the text and work presented in this document is original and that no sources other than those mentioned in the text and its references have been used in creating it.

The Faculty of Economics and Business is responsible solely for the supervision of completion of the work, not for the contents.

(3)

2.3.1. Output Control ... 15 2.3.2. Behavior Control ... 15 2.3.3. Clan Control ... 16 2.3.4. Self-control ... 16 2.4. Knowledge in organizations ... 17 3. Research design ... 19 3.1. Conceptual model ... 19 3.2. Propositions ... 19 4. Method selection ... 23 4.1. Research philosophy ... 23 4.2. Qualitative research ... 23 4.3. Research approach ... 24 4.4. Research strategy ... 24

4.5. Field study design ... 25

4.5.1. Case selection ... 25

4.5.2. Case profiles ... 26

4.5.3. Description of the sample ... 26

(4)

5. Data collection and analysis ... 29

5.1. Data collection methods ... 29

5.1.1. Planning data collection ... 29

5.1.2. Interview process ... 30

5.1.3. Observation ... 30

5.2. The process of coding and analyzing the empirical data ... 31

5.2.1. Thematic analysis ... 32

5.2.2. Familiarization of data during the transcription process ... 32

5.2.3. Coding of the data ... 32

5.2.4. Testing propositions ... 33

6. Results and interpretation ... 35

6.1. P1: Outcome control ... 35

6.2. P2: Behavior control ... 37

6.3. P3: Clan control ... 39

6.4. P4: Self-control ... 42

7. Discussions and conclusions ... 47

8. Limitations and future research ... 49

10. Appendices ... 58

10.1. Appendix A: Interview protocol ... 58

10.2. Appendix B: Interviews ... 61

10.2.1. Interview Product Owner NN IP ... 61

10.2.2. Interview Agile team member Accenture ... 66

10.3. Appendix C: Codebook ... 72

10.4. Appendix D: Coding per case ... 76

10.5. Appendix E: Case profiles and analysis ... 78

List of Tables and Figures

Table 1 Case study overview: agile practices ... 26

Table 2 Case study overview: participants role ... 28

Table 3 Overview cases: Data type ... 31

Table 4 Support of propositions per case ... 35

Table 5 Framework capturing the impact of agile on mechanisms of control and the role of the controller's knowledge and expertise ... 48

Figure 1 Scrum development cycle ... 6

Figure 2 Kanban method ... 7

Figure 3 Agile Unified Process development cycle ... 8

Figure 4 XP development cycle ... 8

Figure 5 Future-driven method development cycle ... 9

(5)

Figure 7 Crystal method ... 11

Figure 8 Adaptive Software Development phases ... 11

Figure 9 Conceptual model of Agile methods, Mechanisms of Control and Knowledge of the Controller ... 19

Figure 10 Example questions observation ... 30

Figure 11 Word Cloud ... 33

Figure 12 Example Case 2 Proposition 1 ... 34

(6)

Abstract

Several studies have focused on the importance of understanding the impact of transition to agile way of working on the entire on the entire organization, including people, their way of working and relationship between different employees. However, not so much research has been conducted on the impact of the agile way of working on the employed mechanisms of control. No explicit research has been done to reveal the changes to the employed

mechanisms of control in organizations when agile methods are introduced. This is addressed in this research thesis by exploring six cases of organizations set up in the Netherlands. Data collection is guided by eight propositions which are developed from control theory and knowledge inside organizations. The findings show that when implementing agile in

organizations, there is an increased focus on outcome control as the quality of the product is of importance; reduced behavior and process control, as not how the product is implemented matters; increased clan control which is the dominating type of control in agile teams, led by their shared values and communication standards; and increased used of self-control, as the self-regulation skills are vital for agile.

Key words: agile way of working, mechanisms of control, knowledge, outcome control

(7)

1. Introduction

1.1. Background

The adoption of agile methods of working in various companies is increasing, as the organizations recognize the benefits these methods come with (McHugh, 2011). Some of the advantages include reduced risk, improved control and better communication (Lee & Xia, 2010). Although the agile project management can be very beneficial, it requires team’s understanding and adaptation to the nonroutine project tasks (Lee & Xia, 2010). As the agile teams should be able to provide solutions to complex tasks (Lee & Xia, 2010) which require cross-functional commitment, this type of product development can yield issues associated with structuring control mechanisms for nonroutine and complex tasks (Kirsch L. J., 1996). Not only the employed control mechanisms might be influenced when an organization transitions to an agile method of working, but this type of new methods requires a deep understanding of the tasks and requirements throughout the organization (Kirsch L. J., 1996). This specifically refers to the individuals that are responsible to ensure that the outcomes are produced as planned (Kirsch L. J., 1996). As Manz and Sims (1980) & Greenberger and Strasser (1986) state, the tasks that involve autonomy, creativity and flexibility are difficult for controllers to exert control on.

The research conducted on agile methods in organizations is increasing each year, but the empirical studies that examine the relationship between the adoption of agile way of working and the control theory to product development are limited (McHugh O. , 2011, pp. 18-19) Further research is needed to find out what is the impact of the agile way of working on the employed the mechanisms of control (Hekkala et al., 2017). Kirsch (1996) explains that the theory of control is incomplete when control is imposed on complex and non-routine tasks, such as the information system development. He observes that the level of knowledge of the task is a major determinant of control. Moreover, Mahadevan, Kettinger, and Meservy (2015), who have observed the control changes that occur in organizations using a combination of agile and traditional methods, argues that the lack of knowledge in the field results in the controllers exercising outcome control only.

(8)

1.2. Research problem

Mechanisms of control are considered to be a very important aspect of the organizations as they are used to ensure that the employees are working towards achieving their goals (Kirsch L. J., 1996). Mahadevan et al. (2015) claim that no explicit research has been done to reveal the changes to the employed mechanisms of control in organizations when agile methods are introduced. Kirsch (1996) argues that the theory of control is incomplete when control is imposed on complex and non-routine tasks, such as the information system development. He observes that the level of knowledge of the task is a major determinant of control (Kirsch L. J., 1996). In addition, Mahadevan et al. (2015) argue that the lack of knowledge in the development process results in the controllers exercising outcome control. The knowledge gap that will be addressed in this research is the lack of in-depth research on the impact of controller’s knowledge on the mechanisms of control when organizations implement the agile way of working. Future research is needed to find out how the transition to an agile project management influence the mechanisms of control (Hekkala, Stein, Rossi, & Smolander, 2017) and what the impact of the controller’s knowledge on this relationship is.

1.3. Research objective

The objective of the research is to develop a framework which shows what is the impact of the agile way of working on the employed mechanisms of control and how is this relationship further influenced by the controller’s knowledge and expertise of the agile development process.

Exploring the relationship between transitioning to an agile way of working and the control modes exercised in the organizations is of both academic and managerial importance.

This research will bridge a research gap between the lack of understanding of the

mechanisms of control in agile organizations and the need of research of the controller’s knowledge in the agile development process. It is important for organizations to understand how the mechanisms of control change when they adopt the agile way of working as control is the mean that can ensure that organizations are working towards achieving their goals (Kirsch L. J., 1996). It is expected that the transition to an agile way of working in organization changes the employed mechanisms of control and that the controller’s knowledge moderates the relationship between agile methodology use and control. The research objective is further translated into the following research question: What is the

(9)

impact of the agile method of working on the employed mechanisms of control and how is this relationship further influenced by the controller knowledge of the agile development processes?

Answering the research question will discover the relationship between variables that are vital for the agile organizations to understand. There is a need to find out how the control imposed on the agile teams (Hekkala et al., 2017) is influenced by the level of understanding on the controller and the new methods of working (Kirsch L. J., 1996).

1.4. Research method

To address the knowledge gap and achieve the research objective, a multiple-case study will be performed. This research method will be used as the topic is studied within its real-life setting, which will contribute to the obtaining of rich descriptions and deep understanding of the dynamics of the case (Saunders, Lewis, & Thornhill, 2016, pp. 184-187). This type of study is beneficial if a combination of different forms of observations, ethnography, interviews, focus groups and other research methods are combined (Saunders et al., 2016, pp. 184-187). The data will be collected from six service companies that have an employed agile method of working to their practices. Firstly, the information will be acquired through semi-structured interviews, which interviews will be further recorded, transcribed and analyzed. Secondly, observations will be performed during the visit to the companies which will strengthen the construct validity in the environment (Saunders et al., , 2016, pp. 354-356).

1.5. Thesis structure

The next section sets the theoretical background of the research and describes what is known about each of the concepts of the theoretical framework. Section 3 uncovers what is the research design, including the research propositions and the conceptual model. It is followed by the description of the method selection (section 4) and the data collection process and the analysis (section 5). The next part of the thesis presents the results of the conducted research and finishes with discussion, conclusion, and propositions for future research.

(10)

2. State of the Art

2.1. A traditional vs. agile project management approach

The main process and product development methods can be characterized as either being iterative and less ceremonial or waterfall-like and more ceremonial (Borgman, 2017). More and more organizations nowadays tend to adopt the “lightweight” (McHugh O. , 2011) project management approach, such as agile, as this method is characterized by little documentation, light processes, less initial planning (Serrador & Pinto, 2015) more flexibility and response to change (McHugh O. , 2011). The classical methods, on the other hand are rigid, plan-driven, bureaucratic and focused on control (Serrador & Pinto, 2015). Serrador and Pinto (2015) argue that the traditional waterfall methods result in excessive rework, customer dissatisfaction and lack of feedback during the project cycle.

The environment firms operate nowadays is complex, customer preferences change frequently and the solution options change quickly (Maruping, Venkatesh, & Agarwal, 2009). The requirements of the users are a result of the increasing business needs and the competitive market environment (Maruping et al., 2009). This is a reason for the companies to adopt the agile project management approach when developing new products and services (Rigby, 2016).

The foundation of the agile methodology was laid in 2001 when a group of software practitioners signed the Agile Software Development Manifesto, which includes the core values of agile software development (Sheuly, 2013). According to it, the focus is on individuals who can create working software through customer collaboration and continuous responses to change instead of following a plan (Sheuly, 2013). The principles of the Agile Manifesto are in conflict with the traditional development methodology as they encourage “undisciplined approach”. The teams that are involved in the agile way of working need to cooperate and work in harmony in order to achieve good results. They work on projects that involve uncertainty and short development time (Darrin & Devereux, 2017). Depending on the development approaches and the requirements of the user, different agile developing teams have implemented new methodologies which could better satisfy their needs. The limitations of many existing agile methods have led to the emergence of new types. (Fowler & Highsmith, 2001).

(11)

2.2. Agile Methodologies

Different agile development methods can be adopted according to their relevance in the current situation and the specifications of the environment. Sunner describes a wide range of well-known agile methods, amongst which Scum, Kanban, Agile Unified Process, Extreme Programming, Feature-driven Development, Dynamic Systems Development Method,

Crystal, Adaptive Software Development, Lean Software Development and Agile Modelling. Each of them will be described in a detail in the next section (Sunner, 2016).

2.2.1. Scrum

One of the most popular agile software and product development methods is Scrum. It is based on incremental development and simple implementation (Zhi-gen, Quan, & Xi, 2009). Schwaber 2004) describes it as iterative development method which can be used as more technical approaches to agile development. The principles of Scrum include four main pillars, namely Scrum team, Backlog, Sprint and the Scrum meetings. The team members get new responsibilities once they become part of the Scrum team. The Backlog consists of Product Backlog and Sprint Backlog. The former consists of tasks that are to be completed in order to develop the product and the latter is a list that consists of all features that the Scrum team needs to complete in the current Sprint (Zhi-gen, Quan, & Xi, 2009). The Sprint is a process that consists of a number of development activities, some of which are analysis, design, implementation, testing and etc. The Scrum meeting is represented by the Sprint meeting which takes place at the end of each sprint, and the Daily meeting (Daily stand-up) which occurs every day with the presence of all the members (Zhi-gen, Quan, & Xi, 2009). The main roles that prevail in the Scrum methodology are Product Owner, Development Team, and the Scrum Master. The responsibilities of the Product Owner include defining,

prioritizing and explaining the customer requirements of the product to the teams. The

Development Team is a cross-functional team, consisting of three to nine individuals who are responsible for completing the tasks allocated by the Product Owner. The Scrum master is responsible for facilitating the principles of the Scrum development method and What characterizes the Scrum method is the empowerment and the self-responsibilities the team members of the whole team have. The role of the project manager has been eliminated and instead, there is a Scrum master who facilitates the execution of the agile development process (Sommerville, 2011).

(12)

The Scrum development method consists of three phases (fig. 1). The first phase is the phase in which the outline planning and the architectural design are defined. It is then followed by sprint cycles where increments of the development system are developed. Teach sprint ends with the presentation of the increment to the customer. (Sunner, 2016) The final phase is the project closure where the team wraps up the development process and evaluate the whole project (Sommerville, 2011). Figure 1- Scrum development cycle- From “Software Engineering” by Sommerville, I. (2005), 9th ed. Pearson, p.73. 2.2.2. Kanban

Kanban is another agile methodology which is used across a range of industries. Primarily it has been implemented in the software industry to tackle problems, such as a lack of

reliability, resistance to change and lack of flexibility (Ahmad, Dennehy, Conboy, & Oivo, 2018). This method is used by the development teams if there is an increased need for prioritization, clear goal and detailed description of the process (Sunner, 2016). Kanban is organized around the following core principles: workflow visualization, limited work in progress, flow measurement and management, explicit process policies, improved collaboration and regular feedback loops (Sunner, 2016). Anderson (2010) describes the process of Kanban as “evolutionary and incremental” method which is used to utilize the lean ideas (Anderson, 2010, p. 6). Although there is no standard procedure for the implementation of Kanban, there are some steps that usually are present in the development process, such as Backlog, Analysis, Development, Testing and Deployment (fig. 2).

(13)

Figure 2 - Kanban method. From “Understanding Agile methodology and Agile techniques” by Sunner, D. (2016), 2nd International Conference on Applied and Theoretical Computing and Communication Technology, p. 133.

The completion of the tasks can be divided into two stages, namely ‘In progress’ and ‘Completed’.

2.2.3. Agile Unified Process

The Agile Unified Process combines elements of both the Agile and Unified Process (UP) and it is used with the intention to shorten the development cycle, reduce risk and improve the quality of the delivered product (Li & Wang, 2010). The development cycle of this methodology is divided into the following consecutive stages: ‘Inception’, ‘Elaboration’, ‘Construction’ and ‘Transition’ (fig. 3) (Sunner, 2016). The first and the most important stage of the development process, the Inception, takes approximately one-fifth of the number of iterative. In this stage, the existing processes and problems are analysed, the future

direction and improvement of the processes are designed and the main goals of the project are set (Li & Wang, 2010). The Elaboration stage includes six iterative and its main goal is to ensure the implementation of the tasks described in the Inception and finish the product development in a flexible way (Li & Wang, 2010). It provides a detailed architecture of the system (Sunner, 2016). The Construction stage includes ten iterative and during its execution, the project progress and the further adjustments are refined. The final stage comprises three iterative and its main purpose is to deliver the product to the end user. During this stage, the system is validated and deployed (Li & Wang, 2010).

(14)

Figure 3 -Agile Unified Process development cycle. From “Understanding Agile methodology and Agile techniques” by Sunner, D. (2016), 2nd International Conference on Applied and Theoretical Computing and Communication Technology, p.134. 2.2.4. Extreme programming (XP)

Extreme programming is one of the most popular and widely used agile methods. This

methodology encourages the frequent release of fresh version and the supply of increments at least once each two weeks (Sunner, 2016). Beck calls this programming method an ‘extreme’ as the iterative development is pushed to utmost levels (Beck, 2000). The Extreme

Programming includes small releases, increased functionality with frequent increments and simple design (Sunner, 2016). Customers are actively involved in the development process through continuous engagement and feedback sessions. Besides having on-site customers, other principles of the Extreme Programming are refactoring, pair programming, collective ownership, continuous integration and sustainable pace (Sommerville, 2011).

Figure 4 - XP development cycle. From “Understanding Agile methodology and Agile techniques” by Sunner, D. (2016), 2nd International Conference on Applied and Theoretical Computing and Communication Technology, p.131.

(15)

2.2.5. Feature-Driven Development

Hezave and Ramsin (2015) compare the requirements of the Feature-Driven Development to the notion of features. This method encourages seamless development process and the use of tool support. Moreover, the client decides on the features that the software can have and his requirements act as an input for planning decisions. There are five main tasks which are part of the Feature-Driven Development and are performed in an incremental way (fig. 5)

(Sunner, 2016). Figure 5- Future-driven method development cycle. From Understanding Agile methodology and Agile techniques” by Sunner, D. (2016), 2nd International Conference on Applied and Theoretical Computing and Communication Technology, p.132.

The first step is to ‘prepare an overall model’ and its main task is to identify the object model. The next step is ‘Preparation of feature list’, in which as it comes clear from the title, the set of features and related subjects are determined. The third step is ‘Planning by feature’ and it is used to create a plan for the development process. The final two steps, ‘Designing by feature and ‘Building by feature’ are dedicated to building and testing the system, after which it is delivered to the customer (Sunner, 2016).

2.2.6. Dynamic Systems Development Method

Jim Highsmith (2001) defines Dynamic Systems Development Method as “an outgrowth of

(16)

development method is used when the team needs to understand the requirements of the clients well and when the focus is on solutions that work not only as promised but are delivered as quickly as possible (Stapleton, 1999).It is mainly used to deliver the right solutions at the right time, while it also gives clear guidance for delivery of projects which are within budget and upon agreed schedule. The main principles of the Dynamic Systems Development Method include team empowerment, frequent releases, incremental

development, business-driven development approach, cooperation, initial requirements high level and end-user involvement (Sunner, 2016).

Figure 6 -Dynamic Systems Development Method. From Understanding Agile methodology and Agile techniques” by Sunner, D. (2016), 2nd_{International Conference on Applied and Theoretical Computing and Communication Technology,} p.132 2.2.7. Crystal

Poppendieck and Poppendieck (2006) define Crystal method of Software Development as a combination of approaches which changes based on the complexity and size of the project (Poppendieck & Poppendieck, 2006). The fundamental principles of this method include continuous feedback, frequent delivery, safety, access to users, constant communication and automated testing and integration. Crystal method includes the use of visual graphs which represent hexagons which are either colored in maroon, yellow, orange, red or are not colored (fig. 7). The darker the color from top to bottom, the more difficult the project becomes. From left to right, the hexagons represent the increasing level of criticality, which is expressed through the following letters: C (comfort), D (discretionary), E (essential) and L (life) (Sunner, 2016).

(17)

Figure 7- Crystal method. From “Understanding Agile methodology and Agile techniques” by Sunner, D. (2016), 2nd International Conference on Applied and Theoretical Computing and Communication Technology, p.133.

2.2.8. Adaptive Software Development

Adaptive Software Development is a modified version of the Extreme Programming (XP) method and it is used for small and simple software projects. The main phases that are part of this development method are: communication and planning, analysis, development, testing and deployment (Qureshi & Hussain, 2008). Sunner (2016) summarizes these phases into three main steps, which are speculation, collaboration and learning (fig. 8) (Sunner, 2016). What is typical for this method is that the developers don’t have a plan to follow but they start working whenever a high-level idea is present. The lack of pre-planning steps gives them high flexibility and they can make the systems in a short period of time. Moreover, the developing teams quickly adapt to new systems and methods whenever it is needed (Sunner, 2016).

Figure 8 -Adaptive Software Development phases. From “Understanding Agile methodology and Agile techniques” by

Sunner, D. (2016), 2nd International Conference on Applied and Theoretical Computing and Communication Technology, p.132.

(18)

2.2.9. Lean Software Development

Lean Software Development method is focused on creating value to the customer by reducing waste, optimizing processes and improving quality (Ebert, Arahamsson, & Oza, 2012). Additionally, Poppendieck and Poppendieck (2006) argue that the main seven principles this development method is based on are: eliminating waste, building quality by avoiding defects, creating knowledge, taking on commitment, delivering swiftly, respecting people, and

creating a holistic view (Poppendieck & Poppendieck, 2006)

2.2.10. Agile Modelling

Agile Modelling is a software development method which is based on predefined set of principles. Some of the core postulates of this agile methodology are maximizing ROI of all the stakeholders, creating only models are needed, quick feedback given by the client, simplicity of the models used, and delivering high quality of work (Sunner, 2016). What is typical for the Agile Modelling method is the quick response to changing requirements which is achieved through adaptability, extensibility, integrability, operability and usability

(Karagiannis, 2015). Rumpe (2002) argues that this agile methodology works well mainly for big projects and it is not very well applied to develop systems that require flexibility (Rumpe, 2002). Despite the challenges that might exist, the Agile Modelling method allows for using a combination of different models, which are assisted by tools and supported by tests to ensure a high level of quality (Rumpe, 2002).

As seen in the previous sections, different agile methodologies have been used mainly for software development. Although they have been introduced in the IT industry, Conforto, Salum, Amaral, da Silva, & de Almeida (2014) argue that these flexible approaches can also be adopted and successfully used in other industries. It has been found that both types of organizations – these that are software development companies and the ones that work in the service sector – experience the limitations of traditional project management approaches (Conforto et al., 2014). They adopt agile management practices when it comes to developing highly innovative products and services with a reduced amount of errors when they need the input from experts in cross-functional departments and continuous feedback after each phase (Conforto et al., 2014). But the collaboration and teamwork of many different people on projects come with challenges (Conforto et al., 2014). Maruping, Venkatesh and Agarwal

(19)

(2009) argue that project leaders face issues of how to effectively manage the team

(Maruping et al., 2009). It is not only technical but also a social process which includes the supervision of people with different characters, skills and experience (Maruping et al., 2009). To ensure that the team is managed well and the utilization of critical skills and expertise is facilitated successfully, the means of control has to be used (Maruping et al., 2009).

2.3. Mechanisms of control in organizations

Ouchi (1979) initially developed the control theory which is focused on the management of employees (Ouchi, 1979). Kirsch defines control as “management’s attempts to ensure that

individuals working on organizational projects act according to an agreed-upon strategy to achieve desired objectives” (Kirsch L. J., 1996, p. 1). The author argues that the controlling

party uses control mechanism to promote certain behavior by the ones that have been controlled (Kirsch L. J., 1997). He also adds that the mechanisms of control are used mainly to motivate people to work in such way that the desired goal is attained (Kirsch L. J., 1996). In more recent academic papers, Mahadevan, Ketinger and Meservy define control in organizations as the

“mechanisms that permit a company to proceed towards its goals” (Mahadevan at al., 2015,

p. 79). According to Ouchi, there are four types of control, namely output control, behavior control, clan control and self-control, which are classified into formal and informal control (Ouchi, 1979). Kirsch (1997) explains that formal control can be implemented through evaluation of the performance of the controlee. Informal control is focused on social strategies for reducing goal dissimilarities between parties involved (Kirsch L. J., 1997). These two types of control mechanisms are perceived by many researchers as two ends of a continuum (Merchant, 1988). Contributing to the Ouchi’s work, Eisenhardt (1985) has suggested two underlying control strategies which are perceived as a design mechanism in organizations. The first one suggests that control can be implemented in the organization through performance evaluation. This type looks into how the outputs and mechanisms of the working process can be measured. Depending on the information available that is to be measured, outcome or behavioral control can be exerted (Eisenhardt K. M., 1985). Ouchi (1979) argues that it depends on the level of knowledge of the process and the ability to measure outcomes. If all the steps that are to be taken are well known and the outcome measurability is low, then behavioral control can be implemented. However, if the organizational members have a clear picture in their minds of what needs to be produced and the outcome measurability is high, outcome control will be exerted in the organization (Ouchi, 1979). The second strategy is focused on

(20)

control by minimizing the variance of preferences among team members. This type of social control can be used in case of low outcome measurability and imperfect task programmability (Eisenhardt K. M., 1985). Nowadays, however, more and more companies rely on combining members from various functional departments in order to achieve arich source of experience and knowledge sharing. (Bonner, Ruekert, & Walker, 2002). This type of collaboration requires some degree of freedom, flexibility, adaptability and participative decisions techniques to ensure speed and high quality of deliverables (Bonner et al., 2002). This doesn’t go without risks as the cross-functional development process requires also a different approach which will ensure the work goes smoothly and the end product meets the agreed standards. Formal control which is generally implemented at an individual project level can assure that the process is kept on track, but if too much of it is exerted on a team level, then creativity of the project groups can be constrained (Bonner et al., 2002).

Kirsch and Sambamurty (2002) contribute to the field of control theory by exploring control modes in the information systems (IS) projects. The authors argue that control is used to stimulate IS professionals to achieve desired goals. They also emphasize the important role of the client liaison in the IS projects (Kirsch & Sambamurty, 2002). The client is involved in the entire course of the development process by articulating requirements, checking the quality of deliverables, communicating with the developing teams and monitoring overall progress. To ensure that the needs of the business are met and the end deliverable is of good quality, the client liaison exerts control over the IS developing team members (Guinan & Cooprider, 1998). Software development is considered as not only technical but also as a social process of managing relationships between the team members and utilizing their skills and competencies (Beath & Orlikowski, 1994). Managing both technical and social processes might be challenging for the project leaders as a need to take into consideration the management of not only individual employees but the social relationships between them (Maruping et al., 2009). The type of controlling mechanisms implemented in the IS projects will be used as a benchmark for the control modes in the agile way of working. As the agile methodology was initially applied to the information systems development, the work of Kirsch et al. (2002) will be helpful to support the notion of the control mechanisms implemented in agile companies.

Traditional firms implement control practices through a lot of documentation and feedback at the end of the last phase, which might lead to stagnated innovation (Mahadevan at al., 2015). Agile organizations, in contrast, favor reduced documentation and continuous feedback

(21)

sessions, which result in increased level of innovation (Smeekes et al., 2018). This type of organizations experiences control mechanisms that might be adjusted according to the nature of the project (Smeekes et al., 2018). Control is implied through the monitoring of behaviors and outcomes which is needed to ensure strong team performance (Maruping et al., 2009). As a clear distinction between the behavioral and outcome control together the control implemented within the teams is usually a challenge to draw, the next subsections set out a detailed description of each of the four main control modes as introduced by Ouchi (1979).

2.3.1. Output Control

Ouchi and Maguire (1975) initially make a distinction between two modes of organizational control, namely behavior and output control. The latter is based on outlining certain project goals (Kirsch L. J., 1996) that are to be achieved and the “measurement of the outputs, while providing legitimate evidence for the quality of the deliverable (Ouchi & Maguire, 1975, p. 559). Output control is a formal type of control that is implemented to ensure that set of project goals will be achieved (Maruping et al., 2009). Eisenhardt adds that it is used when the outcomes are measurable and the controller can estimate whether the target has been reached (Eisenhardt K. M., 1985). In this type of control, the controller focuses on the final results without regard to the means which have been used to reach the objective. Thus, the controlling party set the requirements that are to be met and the final desired outcome which is expected to be delivered by the controlee. To make sure that the goals are met and the final deliverable is produced in a timely manner and meets the pre-determined set requirements, the controller makes use of mechanisms that will measure the controlee’s performance (Kirsch L. J., 1997).

2.3.2. Behavior Control

Another type of formal control is the behavior control mode. It is focused on the processes and the procedures that the teams need to follow in order to attain their objectives (Maruping et al., 2009). The controller strives for influencing the means that are used to achieve the goal by continuously observing the behavior of the controlee. The latter needs to follow the stated procedures and predetermined tasks which will lead to the desired outcomes (Kirsch L. J., 1996). If procedures and process determined by the controller are followed, controlees are awarded for meeting the target. The controlling party not only need to observe and evaluates

(22)

each process step but the controller needs to develop a detailed framework that has to be followed. This requires knowledge, skills, and expertise of the whole development process. (Kirsch L. J., 1996). Kirsch and Sambamurty highlight the challenge of exercising behavior control, which requires the ability of management to understand the system through which teams process the inputs into outputs (Kirsch & Sambamurty, 2002).

2.3.3. Clan Control

Informal control consists of clan control and self-control (Maruping et al., 2009). Clan control is defined by Daft as “the use of social characteristic, among which shared values,

understandings and opinions” (Daft, 2009, pp. 207-224). This type of control is useful when

outputs and behaviors are difficult to measure (Daft, 2009, pp. 207-224). It is imposed when shared values and beliefs are encouraged within the organization when employees are encouraged to behave according to common norms, and their actions comply to the expected group rules (McHugh O. , 2011). Clan control is implemented by promoting common beliefs, values, and understandings within the clan, which is perceived as a team of individuals who have a common goal (Ouchi, 1980). Members of the clan do not follow a predefined set of tasks or methods, but they rely on common behaviors, which have been established through the socialization process (Ouchi, 1979). Individuals that are part of the clan determine the end goal taking into consideration the best interest of the team and then they work towards achieving it (Wilkins & Ouchi, 1983). Although this type of control is not always chosen by the organizations, it is implemented in many companies in which this form of control is perceived as dominant (McHugh O. , 2011).

2.3.4. Self-control

The second type of informal control is the self-control, which is exerted by the individual who sets his own objectives and monitors whether he has achieved them (Erez & Kanfer, 1983). The controlee determines the mechanism that will be used to support the successful completion of the tasks (Choundhury & Sabherwal, 2003). These mechanisms include determining standards for certain actions, setting milestones and monitoring progress of these milestones (Choundhury & Sabherwal, 2003). The self-control concentrates on the individual and the individual autonomy (Maruping et al., 2009). This type of control is an encouraging mechanism for individuals to formulate their own rules and objectives and then observe their own progress

(23)

towards achieving their goals (Maruping et al., 2009). The organization plays a role by stimulating individuals through rewards and incentives, which results in stronger self-control (Maruping et al., 2009). Complex tasks that require intellectual activity and creativity, such as the ones that are performed through agile project management, are suitable for the use of self-control (Maruping et al., 2009). As these tasks are new to the agile teams and the product owner, an extensive amount of knowledge and understanding are needed to ensure the success of the projects (Kirsch & Sambamurty, 2002).

2.4. Knowledge in organizations

Charband and Navimipour describe knowledge as “awareness or understanding of information

or skills” (Charband & Navimipour, 2016, pp. 1-21). Its value increase when shared in the

organization. (Quinn, Anderson, & Finkelstein, 1998). Each employee brings different knowledge and experience to the company which need to be managed and integrated into a coherent whole by the project manager (Walz, Joyce, & Curtis, 1993). Knowledge is necessary for developing and improving quality in companies, especially when it comes to the agile development organizations. The latter is heavily reliant on knowledge sharing and applying among the people who work in cross-functional teams (Kuusinen, et al., 2017). Not only is knowledge of the project team members important, but also the level of understanding and expertise of the ones who need to ensure good quality of the deliverables (Kirsch L. J., 1996). Ouchi claims that the knowledge of the process is an important factor for choosing control modes (Ouchi, 1979). He also adds that knowledge is important to choose the right processes that will transforms inputs into the desired outputs (Ouchi, 1979). According to Kirsch “when control theory is applied to a complex, nonroutine task such as the

management of information systems development, the theory of control is incomplete”

(Kirsch L. J., 1996, p. 1). Not only traditional management of information system development consists of complex tasks. The agile way of working is used for “making

complex things simple or, at least, simpler” (Gill, Henderson-Sellers, & Niazi, 2018, p.

319). The level of knowledge of the controller will determine how control will be exerted (Ouchi, 1979). If the level of knowledge is substantial, a behavior control can be applied, and if the desired output can be measured, the outcome control can most successfully ensure that this is delivered as agreed upon (Ouchi, 1979). These propositions by Ouchi (1979) will be further tested in this research while looking at the agile organizations.

(24)

Knowledge and the expertise of the controller are very important in both traditional and agile development methodology. Each controller has a different level of knowledge and various skills across time. Mahadevan et al. (2015) explain that the role of the controller in the Waterfall method is taken by the manager. They describe the primary controller in each stage of the Scrum activities although there is no clear distinction of controller’s role in the agile development process. The controlling party in the product backlog and iteration planning is the Scrum master. Agile team members are responsible for their own activities in the daily stand-ups and daily scrum. In the phases of delivering the demo, the iteration retrospect and for the documenting, and approving the changes throughout the entire process the product owners took the lead (Mahadevan et al., 2015).

In this paper, the controller is perceived as the party that demonstrates controlling and approving authority on the team during the development process. The expertise and knowledge of the controlling party of the agile system development is the moderating variable that will affect the implemented mechanism of control in the agile organizations.

(25)

3. Research design

3.1. Conceptual model

This section explains the development of the conceptual model which is the backbone of the thesis. The main phenomenon that is examined is the relationship between the agile methods implemented in organizations and the main mechanisms of control as introduced by Ouchi (1979), which are output control, behavior control, clan control and self-control. Controller’s knowledge of the particular product and process development combined with his expertise is introduced as a moderator of the relationship.

There is no definitive conceptual model identified in previous research papers that describe the relationship between the agile way of working and the employed mechanisms of control, where the level of knowledge and expertise of the controller is taken into account. There are attempts to describe the change to control modes in organizations where agile methods are applied. However, the research setting is quite limited, the sample groups are small and homogenous, leading to results that cannot be treated as reliable nor valid.

Figure 9 Conceptual model of Agile methods, Mechanisms of Control and Knowledge of the Controller. Source: Author

3.2. Propositions

For the development of research propositions, integration of earlier developed theories of control mechanism (Ouchi 1979, Kirsch 2002, Eisenhardt 1985, Maruping, Venkatesh and Agarwal 2009), control of complex tasks (Slevin and Pinto 1987, Stuckenbruck 1988, Kirsch 1996, Bello and Gilliland 1997) and the knowledge of the transformation process (Kirsch 1996) will be performed. The rigor of the theory will be tested in the concept of the agile way of working. The agile teams and their development practices have some characteristics in common with the ISD (information systems development) described in the academic work of

(26)

Kirsch (1996, 1997, 2002).

One of the characteristics of the agile methodology is the increased focus on value creation and business outcomes (Conforto et al., 2014). They are achieved through an increased focus on outputs and control methods exerted on the final deliverable. Maruping et al. (2009) suggest that the outcome controls are generally preferred regulation mode to the process controls in agile organizations. Earlier studies also hypothesize that the ability to measure the outputs predisposes the use of outcome control (Kirsch & Sambamurty, 2002). As Smeekes

et al. (2018) suggest in their paper, focus on what the teams deliver, the goals they achieve, increase in agile teams vis-à-vis the emphasis on the process, or how they do it, which decrease. Consequently, providing a foundation to form the following proposition:

Proposition 1(a): The product development project management relies on the increased use of outcome control when implementing an agile way of working.

Kirsch suggests that “[…] outcome control will be used […] where outcomes are highly

measurable, except where both behaviors are highly observable and controllers are very knowledgeable, in which case behavior control will be used […]” (Kirsch L. J., 1996, p. 6).

This finding by Kirsch argues that if the outcomes can be evaluated, control that evaluates their quality can be exerted by the controller “regardless of his knowledge of the

transformation process”. He adds that the knowledge of the controller will have an influence

in the use of outcome control only if “the behaviors are highly observable and “outcomes are

not measurable” (Kirsch L. J., 1996, p. 6). Based on these findings, the following proposition

can be suggested:

Proposition 1(b): The level of controller's knowledge and experience in the field of agile development have no effect on outcome control, where outcomes are measurable.

Mahadevan et al. argue that “behavior control is appropriate when there is near-perfect

knowledge of the input-to-output transformation process” (Mahadevan, Kettinger, &

Meservy, 2015, p. 79). Smeekes et al. argue that process control is usually dominant in the traditional method of working as the latter requires “high levels of documentation and

monitoring throughout the development process” (Smeekes et al., 2018, p. 5474). Adding to

(27)

primary measure of progress” as the intermediate requirements are difficult to measure

(Fowler & Highsmith, 2001, p. 30). These insights lead us to the following:

Proposition 2(a) There is a decreased focus on behavior control when transforming into an agile organization.

In his paper, Kirsch states that “the more knowledgeable the controllers are about ISD, the

more likely they will implement behavior-based control” (Kirsch L. J., 1996, p. 5). He also

explains that if the controller does not have a lot of knowledge and expertise in the systems development process, he cannot evaluate what is observed and will not rely on behaviour control to regulate the working process. Thus, the implementation of behavior control in agile organizations and the level of knowledge of the controller interact to determine the extent of behavior control:

Proposition 2(b) The more knowledgeable and experienced the controller is about the agile systems development process, the more likely he will implement behavior control.

According to Ouchi (1979; 1980), clan control is preferred a form of control when the project is complex, the work is uncertain, the development process is not clear, outputs and progress are difficult to measure. This control is suitable for organizations where organizational fit, strong culture of trust and common norms are leading values present in the company (Daft, 2009). The study of Kirsch (1996) does not provide a lot of explanation of the clan control and the proposed hypothesis was not supported. The author initially suggested that the use of clan control depends on the use of behavior control, outcome control measurability and the low level of controller’s knowledge (Kirsch L. J., 1996). McHugh (2011) further develops the framework of clan control use in her paper by explaining that it is a challenge to implement outcome and behavior control to the agile software teams as their results are often difficult to measure. This is why it is important for the teams to build a cooperative relationship and strive for common goals in order to encourage project success through clan control. Agile development requires individuals to work together as a team to achieve a common goal and produce quality work. Clan members can set their own requirements and decide on how to and what to deliver with a minimal or no supervision by the controller. Chudhury and Sabherwal (2003) add that each agile team can perform the role of controller and controlee simultaneously. These arguments result in logical grounds for the following proposition:

(28)

Proposition 3(a): There is an increased use of clan control when a firm transition into an agile organization.

There are limited studies that examine the relationship between clan control and the knowledge of the controller. Ouchi (1977; 1979) has developed a framework in which the clan control prevails in the teams if the ability to measure outputs is low and the knowledge of the transformation process is imperfect. This leads to the following proposition:

Proposition 3(b): The chance of relying on a clan control is higher if the controller has imperfect knowledge of the agile development process.

Complex tasks that require intellectual activity, such as the ones that are performed in the agile way of working, are suitable for the use of self-control (Maruping et al., 2009). The tasks that the agile teams need to perform are usually other than their day-to-day tasks and to adapt they need additional training and practical experience to get used to the agile way of working. Moreover, detailed knowledge and understanding are needed to ensure the success of the projects (Kirsch & Sambamurty, 2002).

McHugh, Conboy, & Lang (2011) argue that self-control plays a much more important role in the agile development method than in the traditional development methods. They add that individuals take on responsibilities and feel more empowered when being part of the agile team. It is suggested that the controlee has much more freedom in managing his work which is formulated in the following proposition:

Proposition 4(a) There is an increased focus on self-control when transforming into an agile organization.

The results of the research by Kirsch (1996) produced unexpected findings, which suggest that “[…] controllers with more knowledge of ISD are more likely to induce the project leader to

exercise self-control” (Kirsch L. J., 1996, p. 15). One explanation given by the author is that if

the controlling party is less knowledgeable and experienced in the development project, he is not confident enough to “delegate responsibility” to the controlees (Kirsch L. J., 1996, p. 15). The controllers are more willing to give more control to team members who are more competent. Thus, if the controlees know how experienced the manager of the project is, they

(29)

will feel responsible to undertake more task and self-manage the project to deliver satisfactory performance. Consequently, providing a sound foundation to from the following proposition:

Proposition 4(b): The more knowledgeable and experienced the controller is, the higher the chance he will delegate responsibility to the controlees when transforming into an agile organization.

The propositions presented in this section will guide the data-collection methods which will be described in detail in the following chapters.

4. Method selection

To decide on the most appropriate research method, the research objective is taken into consideration (McHugh O. , 2011). The research focuses on four modes of control, namely, output control, behavior control, clan control and self-control (Maruping et al., 2009) and how they are influenced when the organizations transition to the agile method of working. The objective of the research is to develop a framework that describes the impact of the transition to an agile method of working on the four mechanisms of control, and the moderating effect of the controller’s knowledge on this relationship.

4.1. Research philosophy

For this research, an interpretive philosophical stance is used as this exploratory study can best examine the agile project management teams in their natural setting (Saunders et al., 2016, pp. 140-141). Interpretivism argues that humans are different from the physical phenomena. The purpose of the research is to create a rich understanding of the social environment by entering and exploring the world of the participants (Saunders et al., 2016, pp. 140-141).

4.2. Qualitative research

Qualitative research is used when the aim of the method is to explore the phenomenon in its ‘natural’ environment (Myers M. , 2009, pp. 8-9). As an exploratory research, it examines the complex relationship and its main goal is to discover new patterns, instead of testing already existing models (Myers M. , 2009). This type of research method is used to gather detailed

(30)

information about studied phenomenon and to understand why people act in a certain way (Myers M. , 2009, pp. 8-9). It is not appropriate if generalizations need to be made to a large population, as with quantitative method (Saunders et al., 2016, pp. 165-168).

In this research, a qualitative method is used to explore the relationship between the transaction to an agile way of working in organizations and the mechanisms of control that are employed in the company. Respondents will be studied in their natural setting to establish access to meanings and in-depth understanding of the processes that happen (Myers M. , 2009) in the agile teams and how they relate to the control applied in the organization while looking at the knowledge of the controller (Kirsch L. J., 1996).

4.3. Research approach

As Saunders et al., explain in their book, the research approach is a term used to describe theory development. This is “a general term for inductive, deductive or abductive research

approach” (Saunders et al., 2016, p. 726). The basic research methodology that is used as an

approach to analysis is inductive reasoning. The focus is on developing a theoretical framework and looking at previously studied phenomena from a different perspective (Saunders et el., 2016). In the particular research, the research starts by collecting data from different companies that have implemented agile and then continues by exploring the impact of the agile way of working on the employed mechanisms of control and the moderating role of the knowledge and expertise of the controller. As a result, a new theoretical framework will be built, which will be of both academic and managerial importance.

4.4. Research strategy

The research strategy is “a general plan of how the research will go about answering the

research question” (Saunders et al., 2016, p. 726). For this research, an exploratory multiple

case study is performed. This research strategy is used as the topic is studied within its real-life setting, which will contribute to the obtaining of rich descriptions and deep understanding of the dynamics of the case (Saunders et al., 2016, pp. 184-187). The research will be

performed in six companies that have employed an agile method of working to their

practices. Each company is considered a different case as it represents different environment for the implementation of various agile methods and as a result, it might have a different

(31)

influence on the mechanisms of control. Baxter and Jack claim that the multiple case study creates more convincing results which are strong and reliable (Baxter & Jack, 2008). The data will be gathered by using purposeful sampling method, where the participants are selected based on pre-determined criteria. Each case will include an access to at least two respondents. One of them will be the Product Owner in the team or the Scrum Master and the rest will be the team members in the Agile development team. This will ensure representation of one of the most important parties in the teams, which will, as a result, provide credible and reliable results.

4.5. Field study design

Yin (2003) describes the field study design as the plan of research data identification, collection, and analysis with the aim to achieve the research objective (Yin, 2003). The following parts describe how the cases in this research are selected, a short description of the cases and design of the data collection protocol.

4.5.1. Case selection

The cases in this research are selected considering a number of factors. First of all, cases are selected based on specific criteria. Each case is chosen to represent a company in the

different industry which can be studied and will examine whether the propositions will hold among different groups and in different settings. A number of conditions need to be met before a company can be selected for being a case in the research. Firstly, the organization needs to be active in the service sector. Secondly, the company needs to have implemented the agile way of working and each of the participating teams had started using an agile methodology at least six months prior to the collection of the data. And thirdly, some of the agile teams need to use agile for development of products and services, other than software development. These conditions are very important as the majority of studies that focused on agile way of working include a research on companies that use agile methods for the

development of software and are active in the IT sector.

The cases are selected with the aim to extend an emerging theory and produce results which are considered valid and reliable as the research question is tested across different settings.

(32)

Another important factor that is taken into account is the sufficient access which can be gained in the organizations (Yin, 2009, p. 26).

4.5.2. Case profiles

The companies were selected based on the criteria mentioned in the previous section. The teams were selected based on their differences such as industry and development product and processes. As each company is a part of a different industry, each of them represents the different case.

Case Industry HQ Firm size Firm age (yr.) Start date agile implement ation Agility (%) Agile method NN Investment Partners Investment

Management The Hague 1,000-5,000 1994 2016 30% Scrum; Kanban; XP Biz-Dev-Ops Be Frank Financial Services Amsterdam 11-50 2010 2010 90% Scrum OHRA Insurance Arnhem 201-500 1925 2016 50% Scrum ABN AMRO Banking Amsterdam 10,001 + 1991 2015 50% Scrum Kanban SAFe BESTSELLER Clothing Brande 10,001 + 1975 2015 50% Scrum

XP Accenture IT & Services Dublin 10,001 + 1989 2011 20% Scrum

Kanban SAFe Holacracy

Table 1- Case study overview: agile practices. Source: Author

4.5.3. Description of the sample

The participants in this research are chosen based on purposeful sampling as they should be involved in the agile way of working in the company they work for. Moreover, in each case, there must be representatives of at least two roles in the agile teams, one member and one person that has more controlling or facilitating role. In most of the cases where Scrum method is used, this role will be taken by Product Owner and the Scrum Master.

Profile of each of the participants, while ensuring anonymity and confidentiality, is provided in table 2.

(33)

They are described in term of their positions at the company, role in the agile team, main responsibilities, field of experience and number of years of experience working in both Agile methodology and Waterfall. The main field of expertise and the number of years working in agile together with the number of agile projects completed and certification will be used to determine whether the person responsible for the evaluation of the final deliverable has a role of a controller or more of a facilitator.

Case Position Role in the agile team Main responsibilities Number of years working in Agile methodology Field of expertise/level Number of years working in Waterfall method NN IP Business Process Manager Scrum team member Wholesale Proceeds and prepares information for funds.

<1 year Business/junior 3 years

Business Processes and Systems Improvement Squad Lead RPA Engaged in automation of processes 3 years Business /IT/junior 10 years Business Change Analyst Scrum team member Internal clients & Regulatory Analyze reporting and clients’ data <1 year Business/Finance /senior 5 years Investment Performance Analyst Scrum team member Regulatory Design and apply regulation <1 year Business /Finance/junior <1 year Senior Project &Change Manager Product Owner Handling all questions related to Finance instruments

2 years Business /senior/ experienced in the field

8 years

BeFrank Digital Manager Scrum Member Develop marketing strategy of the company. Responsible for the front end of the online environment, portals, website, app. 3 years Business/Marketi ng/senior 5 years Manager Product Owner Helping the team for the front and back end of the online environment 4 years IT/experienced in the field/senior 5 years

OHRA Lead Developer Scrum Member

Develop and deliver software

(34)

Java Developer Scrum Member

Develop software using Java

1 year IT/junior <1 year System

Developer

Scrum Master

Develop systems for the back office

3 years IT/senior 7 years

Developer Scrum Member Develop and deliver software 3 years IT/senior 10 years Agile Developer Product

Owner Develop new insurance products for freelancers 3 years Business/IT/senio r 10 years ABN Amro

Agile Coach Agile Coach

Facilitate the teams on working in agile way

Software Developer Scrum Master Develop softwares for insurance companies

<1 year IT/junior <1 year

Business Analyst Scrum Member Analyze and test systems 3 years Business/IT/senio r 20 years BESTSE LLER Software Developer Scrum Member Develop software

3 years IT/senior 8 years Software Developer Product Owner Help teams develop systems 2 years IT/senior/experie nced in the field

8 years Accentur e Scrum Master Manager Agile Coach Facilitate developing and Service portfolio management teams

Software Business Analyst Product Owner, Scrum Master, Agile Coach Facilitate and helps teams to develop automotive software 7 years Business/senior/e xperienced in the field 1 year Table 2- Case study overview: participants role. Source: Author

4.5.4. Design of data collection protocol

One of the data collection methods for this research is the semi-structured interview, which requires the development of an interview protocol. It includes explanation and purpose for the interview and the research. The research protocol informs the respondents that the data will be stored anonymously and ensures confidentiality of the information gathered by the respondents. It also gives definitions of the mechanisms of control that are studied in the

(35)

paper. The next part of the protocol includes a list of pre-defined questions which are clearly phrased, using simple and non-academic language. The majority of questions are open-ended in nature as the can encourage discussion among the interviewer and the interviewee.

5. Data collection and analysis

Data collection can be carried out using various methods which are chosen based on the research approach, the research questions and the unit of analysis. The selection of the various research methods depends on other factors, such as the time frame allowed for the research, the costs, resources and the available facilities which are required for the particular study (Sekaran, 2002). As Myers (2009) explains, the most frequently used data collection instruments for qualitative research methods and particularly case studies are interviews, direct observations and documentation (Myers M. , 2009, p. 8). The use of multiple data collection methods to study different aspects of the research problem, known as triangulation, will be used to ensure the topic is examined from different angles and unusual phenomena are uncovered (Myers M. , 2009, pp. 5-9).

5.1. Data collection methods

In this research, multi-method qualitative research is used. Firstly, the information is acquired through semi-structured interviews, which interviews are further recorded, transcribed and analyzed. Secondly, observations are performed during the visit at the companies which will strengthen the construct validity at the environment (Saunders, Lewis, & Thornhill, 2016, pp. 354-356).

5.1.1. Planning data collection

A visit to the firm’s offices in the Netherlands is planned in advance. The data is collected over a period of two months. Empirical data is collected primarily and direct and

observations of the agile processes were performed. This ensures that construct validity is strengthened as the environment and the behaviors of the interviewed employees were considered. Each of the meetings with the agile teams is planned with the help of the Agile Coach or the Scrum Master and a meeting room is reserved so that the interviews could be

(36)

conducted in private. In case C6 (Accenture), the interview and the observation are planned and executed via a phone and Skype.

5.1.2. Interview process

For this research, semi-structured interviews were used. Set of predefined questions were prepared and followed, however additional questions were asked which provided additional clarification once needed. The interview guideline can be seen in Appendix 1. As Myers and Newman (2007) explain, this type of interview is very useful for a replication of the study (Myers & Newman, 2007). In total, 19 interviews were conducted. All but three of the interviews were held face-to-face which aimed to establish credibility. Each interview started with an introduction to the topic, the aim of the research and handling and storage of the data.

Moreover, a definition of the agile mechanisms that are topic of the research was given and they were explained in detail. The participants were ensured that their responses would be treated as confidential and that anonymity is guaranteed. They were also informed that the interview would last between 30 minutes and one hour. A permission to record the interview was also requested which would allow me as a researcher to minimize note-taking and focus on listening to the answers.

5.1.3. Observation

Direct observation is used as a complementarity to the primary data collection method. Five of the companies were visited and data was collected by observing agile practices in action, a majority of which was the daily stand-ups and beginning of the sprints. The questions

considered when conducting the observations and writing the field notes are suggested by Silverman (2008) (fig. 10). They are explored per case and per proposition.

The impact of agile methods of working on the mechanisms of control