Barriers Against Better Team Performance in Agile Software Projects Master of Science Thesis in the Master's Programme International Project Management YAVUZ KOZAK Department of Civil and Environmental Engineering Division of Construction Management CHALMERS UNIVERSITY OF TECHNOLOGY Göteborg, Sweden 2013 Master's Thesis 2013:122 II REPORT NO. 2013:122 Barriers Against Better Team Performance in Agile Software Projects A Qualitative Study To Identify Factors That Can Decrease Performance of Agile Software Teams Master of Science Thesis in the Master's Programme International Project Management Yavuz Kozak Department of Civil and Environmental Engineering CHALMERS UNIVERSITY OF TECHNOLOGY Göteborg, Sweden 2013 III Barriers Against Better Team Performance in Agile Software Projects A Qualitative Study To Identify Factors That Can Decrease Performance of Agile Software Teams YAVUZ KOZAK © YAVUZ KOZAK, 2013. Technical report no 2013:122 Department of Civil and Environmental Engineering Division of Construction Management Chalmers University of Technology SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Civil and Environmental Engineering Göteborg, Sweden 2013 IV Barriers Against Better Team Performance in Agile Software Projects A Qualitative Study To Identify Factors That Can Decrease Performance of Agile Software Teams YAVUZ KOZAK Department of Civil and Environmental Engineering Division of Construction Management Chalmers University of Technology Summary Agile methodologies evolved to cope with the changing requirements in management of software projects, in an effort to increase bring business value of products and create higher client satisfaction. At the heart of agile methodologies lies the agile project teams. Success of agile projects highly depend on the performance of project teams. In contrary to the driving forces that foster performance of teams, there are barriers that limit their performance and productivity. In this master thesis, factors that limit the performance of teams operating in agile software projects are studied. A literature review approaching the research question from three dimensions (software projects, agile methodologies and teamwork) is made. Qualitative data, collected from interviews with 8 agile project managers is used to identify and present various barriers grouped under three main topics: (1)Interaction and personal perspective, (2)material perspective and (3)agile process perspective. It is concluded that performance of teams in agile projects depend on many factors and there are different barriers that prevent teams from progressing more efficiently throughout the project. Barriers identified in this thesis are interpretations of the participants of interviews and generalisations may not apply to all teams in the industry. The report is written in English. Keywords: Agile, Software Project Management, Team Performance, Barriers V Preface This master thesis identifies barriers that decrease performance of teams that operate in agile software projects. Thesis was carried out between January and September 2013, at Chalmers University of Technology, Construction Management Department. Thesis was supervised by Inger Bergman from Chalmers University of Technology and Dr. Claudio Benghi from Northumbria University. Author of this thesis would like to thank his supervisors for their guidance, family and girlfriend for their support throughout the thesis work. He would also like to thank all the project managers that he has interviewed for their valuable contributions on the context of the thesis. Yavuz Kozak, Sweden, September 2013 VI Table of Contents 1 Introduction .......................................................................................................... 1 2 Literature Review ................................................................................................. 3 2.1 Software Project Management ...................................................................... 3 2.1.1 Key Concepts in Software Projects ......................................................... 4 2.1.2 Agile Software Development ................................................................... 6 2.2 Team Performance ...................................................................................... 15 2.2.1 Teamwork ............................................................................................. 16 2.3 Factors Affecting Team Performance .......................................................... 17 2.3.1 People Perspective: Personal, Interpersonal and Team Interaction ..... 19 2.3.2 Material, Tool and Environmental Factors .................................................. 27 2.3.3 Process Based and Organisational Factors .................................................. 29 3 Methodology & Data Collection .......................................................................... 32 3.1 Introduction .................................................................................................. 32 3.2 Research Question ...................................................................................... 32 3.3 Characteristics of Research ........................................................................ 32 3.3.1 Introduction ........................................................................................... 32 3.3.2 Interpretivism (Research Paradigm) ..................................................... 32 3.3.3 Induction (Data and Theory Relationship) ............................................. 35 3.3.4 Qualitative Inquiry (Data Collection Approach) ..................................... 35 3.3.5 Interviews (Data Collection Method) ..................................................... 35 3.4 Research Procedure .................................................................................... 36 3.4.1 Literature Review .................................................................................. 36 3.4.2 Data Collection ...................................................................................... 37 3.4.3 Data Analysis ........................................................................................ 38 3.5 Ethical Considerations ................................................................................. 38 3.6 Scope and Limitations ................................................................................. 39 VII 4 Results & Data Analysis ..................................................................................... 40 4.1 Demographic Data....................................................................................... 40 4.2 Analysis of Results ...................................................................................... 41 4.2.1 Interpersonal and Personal Perspective ............................................... 41 4.2.2 Materialistic Perspective ....................................................................... 52 4.2.3 Agile and Organisational Process Perspective ..................................... 53 5 Discussion .......................................................................................................... 58 5.1 Introduction .................................................................................................. 58 5.2 Discussion ................................................................................................... 58 5.2.1 Interpersonal and Personal Perspective ............................................... 58 5.2.2 Materialistic Perspective ....................................................................... 61 5.2.3 Agile and Organisational Process Perspective ..................................... 62 5.2.4 General Discussion ............................................................................... 64 6 Conclusion ......................................................................................................... 66 6.1 Conclusion ................................................................................................... 66 6.2 Further Research......................................................................................... 67 7 Bibliography ....................................................................................................... 68 8 Appendix ............................................................................................................ 72 8.1 Appendix A – Interview Topics .................................................................... 72 8.2 Appendix B – Interview Consent Form ........................................................ 73 8.3 Appendix C – Agile Manifesto and 12 Principles ......................................... 74 8.3.1 Manifesto for Agile Software Development ........................................... 74 8.3.2 Principles Behind the Agile Manifesto ................................................... 74 VIII Table of Figures Figure 1 – Level of effort in traditional and agile projects. ........................................ 10 Figure 2 – Extreme Programming Office Space ....................................................... 12 Figure 3 – Categories of Barriers to be Researched ................................................ 18 Figure 4 – Interview Topics....................................................................................... 72 1 Introduction Software industry has grown significantly in the last decade. BSA (no date (Accessed: 12 April 2013)) report on software industry reveals that "software and related services sector experienced a real annual growth rate of 14%" in U.S.(which corresponds to 46% of the world software market(BSA, no date (Accessed: 12 April 2013)) between 2006 and 2007. Together with the growth in the industry, the demand for faster and more precise software solutions increased. This growth of demand and industry brought the necessity to change the way software projects are managed. Shorter deadlines, more complex requirements and ever-changing client needs made it hard for traditional development approaches to cope with. (Takeuchi & Nonaka) argued in (1986) that sequential approach to developing new products are no longer able to get the job done. Emergence of agile methods in software development was a consequence of effort to cope with the dynamic environment of software management process. Observing that "while hardware speed and network capacity have made impressive strides ... software development has not improved under the same order of magnitude"(Chiang & Mookerjee, 2004), the idea that ‘software development processes should be improved’ was born. Agile Manifesto was created in (2001) as a guideline for improving the software development process, giving more emphasis on interactions and flexibility. The four values of the manifesto are:  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan (http://agilemanifesto.org/, 2001) Today, many software development methodologies that are characterized as agile are being used (Scrum, Extreme Programming, Lean etc.). These comparably fresh methodologies offer more flexibility, creativity, productivity and stakeholder satisfaction when compared to traditional methods. Zwicker, 2007, 2 cited in Fernandez and Fernandez (2008) agrees on this argument stating that majority of the companies using agile methodologies that he polled saw more than 10 per cent improvement. However, for these methods to work as intended, extensive efforts are in several areas. Team dynamics is one of those areas since success of agile methods are highly dependent on interactions and team effectiveness. Moe, Dingsøyr, and Røyrvik (2009) state that team performance has direct relationship with effectiveness of teamwork coordination. However, they add that usage of teams does not guarantee success for the organisation. As they can be the architects of success, they can also be the source of failure. "Most software development projects fail because of failures with the team running them"(DeMarco and Lister, 1999, cited in (Acuña et al., 2009)). Teams can be thought as systems which are influenced by positive forces such as high budget, experienced specialists in the team, high-tech tools, capable consultants, etc. and negative forces, which are the barriers that this research focuses on. To increase speed(efficiency) of a system(team), positive forces should be supported and negative forces should be eliminated. Sanjiv Augustine et al. (2005) stated that throughout the project, the project manager identifies problems and removes obstacles to implementation of the practices. Inspired by the above ideas, in this study, the barriers that affect the team performance in agile software projects negatively were attempted to be clarified. Focusing on two major agile methodologies (XP and Scrum), obstacles that teams encounter are researched, analysed and listed under logical groups. Following introduction chapter, literature review examines the scholarly knowledge created so far about the topics of interest. Next, methodology chapter explains the literature review and data collection methods as well as research type, ethical considerations and limitations. Results and data analysis chapter starts with a brief analysis of the data sources and continues with listing of data collected. Discussion part critically analyses the collected data under the light of literature review. Finally, conclusion chapter makes an overall summary of the research and suggests further research. 3 2 Literature Review This chapter focuses on the previous works of scholars about subjects related to the research question. The research question was approached from three dimensions: 1. Software project management, 2. Agile methodologies, 3. Teamwork. For this aim, software project management, agile project management and teamwork will be discussed briefly in the following sections. Next, explicitly stated and possible barriers found in analysed literatures will be analysed. Information gathered from academic journals and textbooks were organised in a logical manner to give the reader an understanding of why the research question is of importance, which angles of project management should be considered and findings in previous research that are related to the research topic. 2.1 Software Project Management Association for Project Management (2006) defines projects as unique, transient endeavours undertaken to achieve a desired outcome. Ahmed (2012) defines project management as starting an activity to achieve some stated goals using limited resources, budget, and time. Software projects are born with specific or unspecific requirements from the client, which in time evolves to a software product (product was depicted as source code in (Ahmed, 2012)). These projects are run by individuals or teams-which can be multi-disciplinary- that try to implement all the specified goals with their human and material resources in a given time and with the least amount of defect. The end product is expected to satisfy the client in terms of functionality, usability, performance and delivery time. 4 2.1.1 Key Concepts in Software Projects Client Requirements Today, most of the organisations require software. From simple web-pages to online sales pages of retailers, or from customer databases to enterprise resource planning systems organisations require software of different complexities for different needs. Although software industry provides standardised solutions to the market, most clients require specialized software that complies with their organisational structure and addresses their specific needs. It is rarely the same what client defines in the beginning and what he expects at the end of the project. In the beginning of the projects, requirements being not complete or clear the client has a set of needs and a vision of the final product. These elements are usually changed by the client because of several reasons such as  Client may not need some of the functionalities any more,  Client may want to put extra functionality,  Some functions client described may not address to its needs as client expected,  Client may want change in design,  Requirements may be perceived differently by the project team. Therefore, as the project progresses, existing requirements may change or new requirements and constraints may be added to the projects. One of the major goals of project teams is to satisfy the client by implementing the requirements set-and in time may be changed-by him. Therefore, requirements and client are two of the important factors in software projects. “For the truth is, the clients do not know what they want.” (Brooks, 1995) Project Team One of the limited (and the most important one) resources of projects is the project team. Performance of teams (thus projects) largely depend on the 5 cumulative skillset and cohesion of the team members. Deeprose (2001) argues that teams are differentiated from other work groups such that team’s members have a common purpose and they need each other to attain it. Moreover, they share and divide roles and responsibilities to accomplish the agreed on tasks. Software projects require combination of different skills in the team. Developers, architects, testers and managers are common for most of the software project teams. Performance of projects depends on the level of communication and cohesion between the team members rather than their number. Brooks (1995), argues that effort and progress are not interchangable, therefore performance of teams are not linearly related to the number of team members. In addition, he claims that each new member added to the team brings exponentially increasing amount of need for total communication. “Projects, after all, are all about people.” (Ahmed, 2012) Tools It is in the virtual nature of software programming to get involved with specific tools since the end product is a list of commands interpreted by a hardware, rather than something physical. Software projects require tools like servers, computers, development and office tools, project management tools to “increase productivity and quality, shorten delivery time and accomplish manually impossible tasks”(Ahmed, 2012). Selection of appropriate tools and training team members on the usage of tools can increase success potential of projects. Process From inception to hand-over, software projects are managed using predefined guidelines and standards. These are formed by experience and research of many years by contribution from academia and industry. There are various project management processes on the market that helps project managers to plan, execute, evaluate, measure and document the projects. Project processes include all the activities starting from project initiation to closure. Depending on the size and complexity of the projects, length and 6 number of activities vary. All of the activities in a project are interrelated and are executed in a logical order with respect to the progression of the project. “One size[process type] does not fit all [projects]!” (Ahmed, 2012) 2.1.2 Agile Software Development This research’s focus is on agile software development methods. Because of the limitations in data sources for interview, two iterative and incremental methodologies, namely XP and Scrum will be the main two methods that will be focused on. This section will make a brief explanation of the agile methods. What is Agile Software Development The term agile comes from agility, which is used as a mean to express the adaptable nature of agile software development methods. “In the centre of increased globalization is the need for project managers to have flexibility in a project system in order to be able to adjust constantly to emerging challenges and opportunities”(Fernandez & Fernandez, 2008). Traditional (or so called sequential) methods, which are older than agile methods were being designed as series of pre-planned actions that follow one another. Sequential methods assume and require that a phase should be finished before another can start. For instance, to begin the testing phase of a project, the whole product was expected to be built and integrated. This approach has several flows related to adaptability of the process and quality of the product being closer to customer expectations:  Planning of complex and long projects are hard and actual progress diverges from the planned progress in time,  In software projects, customer expectations and specifications about the product change over time. Introducing those changes to the project decreases the plan’s applicability,  Integration of the code is done at the end of programming phase in sequential methods. This leaves the project team less time to make fixes 7 and changes over the product to be tested. Moreover, finding and fixing bugs in the integrated code takes more time. Agile software development methods, greatly reduced these drawbacks of sequential methods by making the development process more adaptable to changes. Agile manifesto, which summarizes the principles of agile development was introduced in 2001. Four principles of agile manifesto are stated below.  Individuals and interactions over processes and tools,  Working software over comprehensive documentation,  Customer collaboration over contract negotiation,  Responding to change over following a plan. (http://agilemanifesto.org/, 2001) Following these principles in their processes, several software development methods were introduced in time. Abrahamsson et al., 2003, cited in Sanjiv Augustine et al. (2005) state that agile development methodologies have sought to focus on rapid iterative delivery, flexibility and working code. This research focuses on two popular methods that are used widely in software management industry. These methods are XP and Scrum, which are based on agile values and are similar in many ways. Principles and practices of those methodologies will be summarized below. Principles behind agile manifesto (see Appendix C – Agile Manifesto and 12 Principles) that forms a base for principles of the two methodologies will be included as quotations. Principles 1. Communication “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” (Principles Behind the Agile Manifesto) Like other agile methods, XP and Scrum makes heavy use of face-to-face communication throughout the project. Basic idea behind this principle is that face-to-face communication allows flow of knowledge faster and more freely. 8 Koch (2004) states that agile methods all prefer face-to-face communication over written means. Meetings, working environment, programming methods are designed to foster the communication between the team members. de Sousa and Almeida (2011) stated that face-to-face communication creates a greater potential for effective understanding. 2. Self-organising teams and motivated individuals “The best architectures, requirements, and designs emerge from self- organizing teams.” “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” (Principles Behind the Agile Manifesto) Avoiding micromanagement and empowering the agile team to make its own decision is one of the key principles in agile methods. It is claimed that when teams are given more responsibility about the control of project progress, they will “organize their work in a way which suits them best to accomplish their mission”(Stober & Hansmann, 2010). Under this context, Takeuchi and Nonaka (1986) argues that agile teams operate like a start-up company. In addition, self-organising behaviour in teams is effective when individual members are motivated and knowledgeable enough to fulfil their parts in the team, without the need to take orders from someone else. 3. Early and frequent delivery of working software “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” “Working software is the primary measure of progress.“ “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” (Principles Behind the Agile Manifesto) A key difference between sequential methods and agile methods is the release of a working software several times throughout the project. Improving and adjusting in every next release, the product converges to what the customer 9 really wants. During demos, customer is asked to examine the prototype and give feedback so that they can be applied as soon as possible. Moreover, this gives the customer to add or remove features to/from the feature list in the middle of the project. Since aim of the team is towards creating a working software that fulfils the needs of customer, the end product is more likely to progress towards customer satisfaction. Fernandez and Fernandez (2008), in their research, emphasize that structure is most effective when oriented on “product” instead of “process”. 4. Technical excellence, good design and simplicity “Simplicity--the art of maximizing the amount of work not done--is essential.” “Continuous attention to technical excellence and good design enhances agility.” (Principles Behind the Agile Manifesto) Attitude in agile projects is towards sparing enough time for a piece of work to produce it with high quality. This decreases the need for rework, retesting and rewriting. Moreover, “when changes are required (for example, incorporating a new requirement), well structured, cleanly implemented programs will be easier to change.”(Koch, 2004). Aiming for a good quality code also enhances the programmers capabilities. In addition, keeping the code simple helps the team to avoid tasks that add no value to the project and prioritize ones that are more important. Simple design also helps programmers to test and update the code faster. “Agile project management approaches also emphasize a generative approach, where only what is needed(processes, tools, procedures, documentation, etc.) is required to be used in the project” (Fernandez & Fernandez, 2008). 10 5. Stakeholder collaboration “Business people and developers must work together daily throughout the project.” (Principles Behind the Agile Manifesto) Agile methods rely on continuous collaboration between every stakeholder in the project. People from both the technical and business aspects of the project share their ideas and express their opinions. A difference from usual stakeholder management in traditional project management methods is that communication is done more frequently, and customer is actively included in the projects. 6. Sustainable pace “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” (Principles Behind the Agile Manifesto) Traditional project management methods usually work with a bell-shaped pace where the work done(code written) is less than average at the beginning and end of projects (see Figure 1). Koch (2004) states that to make regular progress apparent, and avoid rush towards the deadline, a consistent rhythm should be established. Moreover, working extra towards the deadline has a chance to cause exhaustion for the next iteration. Therefore, agile teams work with a sustainable pace, trying to avoid working for extra hours. Figure 1 – Level of effort in traditional and agile projects. (taken from (Koch, 2004)) 11 7. Self-reflection and adjustment “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” (Principles Behind the Agile Manifesto) Retrospectives are important part of agile methods. Evaluating past performance of self and the team and trying to adjust to perform better is essential to adapt to requirements of the project. Retrospective meetings and feedbacks from other team members serve the purpose of self-reflection in the team and adjusting accordingly. Instead of having a lessons-learned meeting at the end of the project in traditional projects, agile projects spread this throughout the project to apply needed changes right away. 8. Welcoming change requirements “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” (Principles Behind the Agile Manifesto) Ambiguity of requirements is considerably higher in software projects. Therefore, requirements tend to change during the project. Agile projects welcome these changes since adjustment of project plan is easier with shorter and more frequent iteration plans. Even towards the end of the project, new requirements are accepted and implemented in an effort to increase the business value of the product towards client’s needs. Practices 1. Working Environment The environment that teams are working in directly affects their interaction level. XP and Scrum teams are sometimes situated in a separate office, sitting in close proximity to each other and having tools like meeting rooms, whiteboards to foster information flow (see Figure 2). These workspaces are “designed to maximize face-to-face conversation within the team. It also facilitates “accidental communication,” as people overhear what other pairs are discussing.”(Koch, 2004). de Sousa and Almeida (2011) also mentioned that 12 team members believe that frequency of interaction between team members are directly related to the proximity between physical spaces each member occupies in the laboratory. Figure 2 – Extreme Programming Office Space (taken from (Koch, 2004)) 2. Pair-Programming Programmers are usually expected to work in pairs on a code with one person writing and the other helping. This help includes giving feedback, advices, checking the code and discussing possible solutions. Blankenship et al. (2011) argues that pair programming enables knowledge sharing and increases technical excellence since sharing of experiences between the co-workers is enhanced. 3. On-site Customer To adapt the product to customer needs, team needs to know both what customer wants and if customer is satisfied with the code written so far. This requires the team to have a continuous communication with the customer. On- site customer or product owner in XP and Scrum acts as a proxy between the customer and the team, participating in discussions and planning. Koch (2004) argues that having such a proxy with the team is for the teams advantage since team members do not have to make assumptions on what needs to be done. 13 They can ask the proxy at any moment and questions regarding the customer would be answered quickly. 4. Iteration Planning XP and Scrum methodologies plan which features to deliver, how much resource is required to deliver them and who should deliver them before each iteration. Planning meetings require all the stakeholders to be present so that “questions should [can] be raised and disagreements settled, while all of the key people are together in one room.”(Koch, 2004). Adding or removing features to/from the product is done during these meetings. Therefore this activity which is done several times throughout the project enables the team to adapt the final product to changes in requirements. 5. Daily Meetings Collective mind-set in agile projects require every team member to know about other team members’ and project’s progress. This is done by having small daily meetings between the team members. Blankenship et al. (2011) describes several key activities in these meetings, which are  Discussion of yesterdays, and today’s prospective problems,  Progress update from every member in the team These activities help the team to stay up-to-date with project progress(Cervone, 2011) and realise the visible progress over the project tasks. Moreover, they can comment and feedback on people’s problems in a timely manner. As a general rule, this is done in an open space, with everyone standing and for a maximum of 15 minutes. 6. Collective Ownership Collective ownership of code is an XP practice. Every programmer in the team is “empowered to take any actions that they agree is necessary to reach the desired result”(Koch, 2004). This means that there is no ownership on any chunk of code that is written and any member is responsible for development and functionality of it as long as changes does not cause existing tests to fail. 14 7. Participation of Team in Decision Making During planning and meetings, “all team members should jointly share decision authority, rather than a centralized decision structure”(Hoegl and Parboteeah, 2006, cited in Moe, Dingsøyr, & Røyrvik, 2009). This method, if the team is mature and knowledgeable enough, “let[s] those who are the closest to the object of discussion make faster decisions”(Stober & Hansmann, 2010). 8. 40-hour Week Rule This rule, which is special to XP method limits the team’s per-man hours in a week to a maximum of 40 hours. While it does not forbid team members to work extra if they want, this rule is to maintain energy and motivation of the team members until the end of the project. 9. Small Releases and Continuous Integration This rule, which is special to XP method states that there should be frequent releases, each one adding more value to the product towards client requirements. Moreover, “code for each story [code item] is integrated into the evolving system as soon as it is ready”(Koch, 2004). 10. Sprint This practice special to Scrum method divides the project into smaller time- constrained chunks (usually 3-4 weeks) which produces a working prototype of the final product. Each sprint starts with sprint planning where the features of the product that will be implemented are decided. Therefore, team starts with a goal to be achieved at the end of the sprint. However, it is team’s responsibility to decide on the strategy to achieve it. Members are given freedom to choose which items they wish to implement. “Scrum’s time-boxed increments provide a mechanism for all project stakeholders to learn about the system being built on a regular basis”(Koch, 2004). At the end of sprints, a sprint review is done to evaluate what has been done during the last sprint. All the stakeholders in the project takes part in sprint reviews. 11. Product Backlog Product backlog is an artefact special to Scrum methodology. It contains all the features that would be implemented in the project. New features can be added 15 or removed to the backlog and it is maintained by the product owner. At the beginning of each sprint, the team decides on which features to implement from the backlog. It can be considered as a list of all the features the client wishes to see in the final product. 12. Test Oriented Design XP methodology advices teams to produce the tests for the code before the code is written. This helps programmers to have a deeper understanding and “special insights into the code they are about to write that naturally results in better code that is freer of defects in the first place”(Koch, 2004). Moreover, this practice ensures that the test code would progress together with the product code. Summary Agile software development increases client satisfaction by making the process more adaptable to changes in requirements and resources, increasing stakeholder commitment, empowering teams and increasing simplicity. There are several agile methods that are designed to achieve these goals. Their common values are the agile manifesto and principles behind it. Different methods introduce same or different practices to proceed towards the best product possible by the resources at hand. 2.2 Team Performance What is a Team? It is required to make a clear definition of team to understand and evaluate team dynamics and team performance. Katzenbach and Smith (2005) argues that the term “team” is used without knowing the difference between working groups and teams, which prevents application of the discipline that leads to good performance. A common definition of a team is “a small number of people with complementary skills who are committed to a common purpose, set of performance goals, and approach for which they hold themselves mutually accountable”(Katzenbach & Smith, 2005). Teams are separated from working groups fundamentally by team members focusing on the team goals rather than 16 their individual goals. People forming the team combine their skills to “achieve something beyond the capabilities of individuals working alone”(Marks et al., 2001). 2.2.1 Teamwork This section will briefly describe the term teamwork and qualities of teamwork under the context of agile software development. Points where agile methods differ from traditional methods will also be mentioned. Teamwork can be described as a process of social interactions and actions. It takes a goal as an input and results in a virtual or physical product. Quality of social interactions have direct impact over the cost, delivery time, quality of the output and stakeholder satisfaction. “The concept of teamwork carries with it a set of values that encourage listening and responding constructively to views expressed by others, giving others the benefit of doubt, providing support, and recognizing the interest and achievements of others”((Katzenbach & Smith, 2005), cited in (Moe et al., 2010)). Teams’ performance does not add up linearly with each team member. People’s performances are highly dependent on their environment(human and material). Therefore, the desired skillset cannot be obtained by adding up people having those skills. Teams are formed with people who can work together and who increase (or do not decrease) each other’s’ performance. It is not uncommon for managers to consider team members’ Belbin characteristics and form a balanced team. In addition to considerations while forming the teams, performance of teams also depend on the monitoring and control activities over the team. Traditional project management processes rely on the proven mechanisms of planning, monitoring and control of project manager to get most from the team. Moreover, decision making is more concentrated at project manager and teams are managed to decrease conflicts and increase communication. Teamwork is a major part of agile software development process. http://agilemanifesto.org/ (2001) states the importance of interactions and people over processes and tools. Flexibility and adaptability of these processes are results of continuous interaction between stakeholders. 17 Linear methods like waterfall divide the project execution process into stages and allocate certain responsibilities to different team members. Groups or individuals take products of previous stage (e.g. high-level design) and pass on their products (e.g. low-level design) to the next stage (e.g. testing), therefore maintaining a systematic chain. Incremental and iterative methods like Scrum or XP “divide the implementation phase into several pieces and repeats it several times on subsets of the overall project”(Stober & Hansmann, 2010). Team members work together to release a testable prototype of the final product in iterations, building onto the previous iteration’s output. This repeated cycle enables continuous testing of the product in each iteration and provides the opportunity to change or improve the requirements with feedback from the previous product, therefore making the process more flexible to react to changing requirements. This process requires all of the team members to be active and communicating throughout the process without waiting for their turn. In this rugby approach, “team members work together from start to finish.”(Takeuchi & Nonaka, 1986) Agile methods, instead of micro-managing the team, allows teams to decide for themselves. “This philosophy is a movement away from traditional command- and-control management and toward one that counts the team as an entity that has its own knowledge, perspective, motivation, and expertise”(Koch, 2004). Empowering the team with control over their own actions require involvement of team members not only by workforce but also by expressing ideas, contributing in making decisions and sharing ownership over the project. 2.3 Factors Affecting Team Performance In previous sections, basic understanding of software project management, agile methods and team dynamics were discussed. Under the light of these knowledge, this section will focus on identification of discussed barriers in literature and other factors that were not explicitly classified as barrier but interpreted to have negative effect on team performance. Academic and published materials were taken as a basis for review. Books, case studies and journal papers were studied. 18 "… the use of teams does not always result in success for the organization”(Moe, Dingsøyr, & Røyrvik). The section is divided into three distinct categories. Factors about team interaction and personal capabilities, material factors and process based/ organisational factors. Categorisation of the factors were done so that they cover the key concepts of software project management discussed in Section 2.1.1. An overview of the main topics can be seen in Figure 3. Evidences of possible barriers that are found in literature research will be explained in the following sections. Figure 3 – Categories of Barriers to be Researched 19 2.3.1 People Perspective: Personal, Interpersonal and Team Interaction Agile methods are based on continuous communication in the team and responding faster to changes in requirements. Dispersion of knowledge and information between people, relationship of team members, team characteristics and leadership in the team plays an important role in shaping the performance of teams. Another angle to look for the factors affecting the team performance from people’s viewpoint is the personalities and capabilities of the team members. In addition to certain capabilities that are required from software development teams, agile teams require their members to have extra capabilities that would fit them into the self-managing, collaborative and cross-functional team environment. This section will review the literature to identify factors that pose a barrier against team performance under inter-related categories of self-management and personality communication, support, trust, team alignment, ownership and coordination, learning and leadership. Managing people challenges is more of an art than a science; the problems’ source could be the organization, the project, the team, or an individual. (Conboy et al., 2011) Self-Management Takeuchi and Nonaka (1986) stated that in their research, one of the characteristics that leading companies show in managing their new product development process is usage of self-organizing project teams. Agile teams advance through the product development stages, starting and finalizing their work together. This ‘iterative and incremental’ development process is different from traditional methods where teams work like in a relay race. Instead of single or less number of deadlines with longer durations, agile teams are under pressure of many deadlines with shorter durations to work in each iteration. Therefore, team members should have a different approach coordinating their work with respect to the project. They should be efficient in organising their agendas to cope with the pace of the team. 20 A requirement for self-management is the absence of micromanagement in the team. Team members should be given a degree of freedom in organizing their agendas. Takeuchi and Nonaka (1986) states that involvement of upper management over the employees should be limited to providing guidance, money and support. That would allow employees to feel ownership of their own tasks and create room for innovation in their work. Moreover, it is stated in (Sanjiv Augustine et al., 2005) that skilled professionals do not adapt well to micromanagement. Therefore, team members’ lack of control over their work may cause them to be less efficient in creative thinking and innovation. Communication Information exchange in the team occurs mostly by means of verbal interactions between the team members. Communication is the basis for higher levels of interaction like support, leadership or learning. “Good communication, as a foundation to structure, requires an emphasis and value in both the human element and an understanding of roles and communication.”(Fernandez & Fernandez, 2008) Communication can be described as a function of context, medium, sender and receiver. Context being complex or simple, explicit or tacit, technical or non- technical, can have different characteristics. Medium is the means the information is being transferred such as face-to-face verbal exchange, written documents, teleconference etc. Sender and receiver are the source and the receptor of the information and maybe individuals or a group of people which are related or unrelated. This study is focused on the barriers related to exchange of information between team members. Nature of the information can vary between technical subjects and personal matters. Literature research indicates that communication has a central role in effectiveness of teams and progress of projects. In their research Sanjiv Augustine et al. (2005) stated that there is a correlation between richness of the interaction between team members and their openness to exchange of information. How easy it is to exchange information and how freely team members can discuss matters related to project effects their willingness to speak up and listen. Accepting and making constructive criticism 21 also play a crucial role in healthy communication. Although they have danger of damaging the team harmony, through conflicts and criticism, better ideas are likely to emerge. Moreover, unexpressed opposing ideas or progressing without everyone agreeing on may demotivate the team members. Katzenbach and Smith (2005) argue that constructive conflict is essential for common understanding and purpose in the team. Moreover, most of the times, conflicts are inevitable and it is up to team to make good use of it by getting a constructive resolution. “Working in teams provides an interpersonal context in which conflicts may occur and attempts to manage them are made” (Jehn, 1995, cited in Marks et al., 2001). Communication problems often have negative effects in teams. (Curtis et al., 1988, cited in Kraut & Streeter, 1995) argued that communication bottlenecks and breakdowns are common in large development projects. It can be deducted that agile software projects are as susceptible to those bottlenecks as well. Shared leadership and cumulative progress demands everyone to communicate continuously and share their progress. This promotes a better integration between parts of code and prevents the need for rework. However, a common result of communication problems is that not everyone in the team is aware of each other’s responsibility, so there is no effective monitoring. Moe et al. (2010) state that lack of communication and feedback leads to more rewriting and reduces team efficiency. When teams have communication problems they are likely to experience problems with coordinating their work (Marks et al. cited in (Moe et al., 2010)) Scrum methodology promotes colocation of the team members to increase communication in the team. Although teleconferences or mails greatly improved the communication potential of people who are not working side-by-side, face- to-face verbal communication still is the most effective way of information transfer within people. de Sousa and Almeida (2011) states that face-to-face communication creates a great potential for effective understanding. Colocation also provides the team to be at the same state of mind since information flow is more rapid. Likewise, by the result of not collocating the team members or other factors that prevents the team from communicating effectively, team members might have different states of mind about the progress of the project. Levesque 22 et al. (2001) argue that decrease in shared mental models in teams are related to decrease in interaction. Support In addition to monitoring, effective communication promotes backup behaviour of team members. Agile methodologies promote members to know of each other’s progress. This enables members to assist, advise or act as a backup for a member. Marks, 2001, cited in Moe, Dingsøyr, and Røyrvik (2009) describes three means of backup behaviour: providing verbal feedback or coaching, assisting behaviourally in carrying out a task and complete a task for the team member when needed. “If teammates are not looking out for, or willing to help out each other, the team will fail when any one member fails”(Marks et al., 2001). “If backup is to occur effectively, teammates need to be informed of each other’s’ work in order to identify what type of assistance is required at a particular time”(Marks, 2001, cited in Moe, Dingsøyr, & Røyrvik, 2009). Moreover, this shared responsibility behaviour prevents people from getting isolated in their work. Therefore, decrease in communication bears the risk of having specialized members which carry the risk of delays if specialized people are unable to perform. In their research, Levesque et al. (2001) found out that there was a correspondence between the time spent communicating between team members and project members’ roles becoming increasingly specialized. Moe et al. (2010) also found out that team members not monitoring each other resulted in little feedback and almost no backup. Trust Collaboration is essential part of a teamwork and it requires a certain level of trust between team members. Effective communication and support requires trust of knowledge and goodwill between team members. “Without sufficient trust, team members will extend time and energy protecting, checking and inspecting each other as opposed to collaborating to provide value-added ideas” (Salas et al., 2005, cited in Moe et al., 2010). Agile teams depend largely on collaboration(see Stakeholder collaboration in Principles section of agile methodologies). Therefore, trust between team 23 members play an important role in enabling the team to perform efficiently. However, it is not always the case that team is formed with people who have previous experience of working with each other. In those cases, instead of building trust over time, team members have no choice but to trust each other blindly from the beginning. Members need to put effort to create this environment and keep it that way. Lack of trust between members may cause members to hide information, blame each other, have disputes and decrease in their motivation. Team Alignment, Ownership and Coordination Agile methodologies depend largely on team collaboration Involvement of every team member in decision making process, helping each other, improvement of team progress and similar traits are expected from agile teams. Unlike traditional methods where there is a certain hierarchy and command-and- control behaviour, agile teams are expected to have a more flat organisation where self-organising teams carry out the role of leader themselves. Self-organising characteristic of teams require members to know their responsibilities as a team member, contribute and flow with the rhythm of the team without isolating themselves. Katzenbach, 1993, cited in Moe et al. (2010) states that successful teams gave themselves time to learn to be a team. Transformation to a self-organising team takes effort and time to learn and adapt especially for those who have no previous experience in working in such teams. Moreover, this characteristic is required to disperse to member’s personal working behaviours. Team members are expected to successfully self- organise their priorities time without the need for a strong control mechanism. This deductive approach is explained by Takeuchi and Nonaka (1986) as “the individual’s rhythm and the groups’ rhythm begin to overlap, creating a whole new pulse.” Self-managing team members need a high-level of coordination between themselves to work efficiently. Kraut and Streeter, 1995, cited in Moe et al. (2010) stated that there is a significant relation between the team performance and effectiveness of teamwork coordination. Members are expected to be oriented with the team’s pace, motives and working style. “High team orientation is claimed to improve the overall team performance in self-managing teams, 24 makes team members coordinate more…” (Salas et al., 2005 cited in Gulliksen Stray et al., 2011). Individual skills should be used efficiently and should be fit into the team’s goals. “Agreeing on the specifics of work and how they fit together to integrate individual skills and advance team performance lies at the heart of shaping a common approach” (Katzenbach & Smith, 2005). Low level of coordination in the team has the risk of leaving people out of pace with respect to team, which in turn causes project progress to lag. Moreover, it would prove harder to get the best from the uncoordinated team members where there is no significant command-and-control mechanism by an authority. As the project goes more complicated and detailed, losing the rhythm of the team may decrease the team performance in accomplishing goals. “Shared mental models are 'knowledge structures held by members of a team that enable them to form accurate explanations and expectations for the task, and in turn, to coordinate their actions and adapt their behaviour to demands of the task and other team members'” (Cannon-Bowers et al., 1993, cited in Levesque et al., 2001). Forming and sustaining the shared mental model in the team provides it with high coordination in the project progress, helps team members to commit themselves in the project decision making process and project execution process, own the project and help the team to perform better. Agile methodologies give responsibility and ownership of the final product to all of the team members by integrating them throughout the whole project. Levesque et al., 2001, cited in Moe et al. (2010) states that for software teams, all of the team members share responsibility for the end product and for this they should develop a shared mental model by negotiating and understanding the teamwork and the task at hand. Katzenbach and Smith (2005) argues that best teams invest a tremendous amount of time and effort exploring, shaping and agreeing on a purpose that belongs to them both collectively and individually. Acceptance of purpose in individual and group level depends on the characteristics of the team members and the level of understanding and coordination between them. Levesque et al. (2001) stated that members with different individual mental models have hard time coordinating their activities in the team. Salas et al., 2005 cited in Moe, Dingsøyr, and Røyrvik (2009) describes team orientation as giving priority to team goals over individual goals. Since sharing the same mental model in the 25 team requires members to agree on a common goal, teams with higher orientation are likely to have a stronger shared mental model. Levesque et al. (2001) states that for temporary groups, developing a shared mental model may result in loss in time and may lead to ineffective teams. Agile teams, being temporary and under pressure of deadlines are susceptible to this kind of deficiency. Teams that have hard time creating shared mental models may find themselves unable to make a collective decision. Moreover, as team members lose the sense of common goals, they may start to prioritise their individual goals over the team goals and progress of the project may diverge from the goal. Learning An advantage of agile methodologies is that it provides a good environment for team members to learn as they progress by use of constant communication and participation. Concepts like pair programming, daily meetings, monitoring and support behaviour helps the members to learn technical knowledge as well as the project progress. (Lynn, 1999, cited in Gulliksen Stray et al., 2011) states that learning has a direct impact on cycle time and product success. Moreover, a coordinated team requires each member to have the same state of mind about the project. “Team orientation requires that the team members know what the project plans and goals are”(Gulliksen Stray et al., 2011). Leadership Agile methodologies support propagating activities that traditional methodologies appoint to a single person to the team itself. Nevertheless, like every project team, agile teams need a single person to track and control everyday tasks, lead the discussions, manage the team and act as a gate between the client and the project team. Agile team leaders’ behaviours are oriented towards sustaining the team coordination, protecting the team from external disruptions and observing the team from a higher level to manage its effectiveness as a self-organising agile team. Sanjiv Augustine et al. (2005) defines leaders’ roles as identifying and analysing the practices that are not being followed and removing the obstacles to their implementation. 26 Unlike traditional boss type leadership behaviour, agile leaders are expected to be the flag carrier of the team and they should act as a role model. Burke et al. (2006) found out that use of transformational leadership behaviours are positively related to perceived team effectiveness. Shared leadership in the team is another point of view when considering leadership in the team. Team members are expected to lead the team by their experience and knowledge from time to time. Hoegl and Parboteeah, 2006, cited in Moe, Dingsøyr, and Røyrvik (2009) argue that all the team members should jointly share decision authority instead of a single controlling leader or everyone making decisions for their individual goals independent of others. Association for Project Management (2006) encourages project managers to demonstrate leadership that the team can follow. However, Katzenbach and Smith (2005) states that teams share leadership roles while working groups have a strong and clearly focused leader. This difference in perception of leadership is because agile teams depend on participation of team members in the decision making process. While studying an under-efficient software development team, Moe et al. (2010) found out that only a few team-members participated in the decision-making, and the Scrum master [leader] focused more on command-and-control than providing direction and support for other team members. This behaviour is usually the result of project managers trying to use traditional approaches as discussed in (Sanjiv Augustine et al., 2005). (Marks et al., 2001) state that no work-related tasks are performed in a vacuum. There are always external distractions to the project team that may disrupt and delay them. Protection of team against such disruptions and maintaining the team’s pace is up to leader. Gulliksen Stray et al. (2011) examined that in such a case, the leader collocated and isolated the team to protect them. Team’s efficiency with respect to the shared leadership and leadership behaviour of the team leader are closely related to each other. Team leader being not capable of performing an agile leadership may cause the team to get disoriented and disturbed by external distractions. Moreover, without the effective implementation of shared leadership, individual goals of members can gain primacy and team’s pace towards the goal may slow down. 27 Personality In addition to technical and agile competencies, personality of the team members in agile teams plays a significant role in the performance of those teams. Every individual in the team has different personality factors. Acuña et al. (2009) argue that those personality factors determine personal preferences, opinions, attitudes, values and characteristics which makes every individual different from each other. (Young et al., 2005) made a study over an XP team to identify the appreciated personality characteristics expected from different roles in the team. Results obtained from the “good team member” category shows the personality characteristics that play more important role. Dominant characteristics of that analysis are analytical thinker, good communicator, learner and willingness to share. Likewise, “bad team member” characteristics turned out to be willingness to be dictatorial and preferring leadership over creativity. Although different characters of individuals may prove worthy in different teams, people working with agile methodologies prefer working with people who are more inclined to team-working and self-management. Since personality of individuals play important role in their interaction with other team members, it may have direct impact on the performance of the team. 2.3.2 Material, Tool and Environmental Factors After interpersonal and personal perspective, second angle of the factors that can create barriers against team efficiency in agile projects are material factors. Software development relies heavily on technological tools. Hardware and software tools as well as visual office tools are commonly used in agile projects. Moreover, office environments in which the teams work are proved to have significant effect on teams’ performance. This section will review the literature to identify factors that pose a barrier against team performance under categories of materials, tools and environment Materials, Tools One of the most suggested tools in agile projects are dashboards and whiteboards. In addition to their simplicity, their high visibility when placed to a convenient place is higher than those of software tools. Nevertheless, there are 28 various software tools in the market to manage agile projects. Teams can configure these tools to fit their processes and collaborate easily on a virtual environment. Moreover, software tools are a must for geographically distributed team members. Marks et al. (2001) states that effective teams rely heavily on technology. Many software developers prefer using more than one computer and/or monitor in their workplace. In addition, some tasks or programs may require high-speed computers or internet connection. Usage and selection of tools may have negative effect on team performance in agile teams. If a team is forced to modify their familiar working process to a new software tool, they may sacrifice their productivity. Furthermore, inadequate hardware or software tools can slow down the team’s product development speed. Environment Agile methodologies require team members to be in continuous and intense communication throughout the project. For this reason teams are located in the same office unless they have to work geographically away from each other. de Sousa and Almeida (2011) states that face-to-face communication creates a great potential for understanding each other. To increase the communication potential of team members and isolate them from external distractions, project leaders usually place the team in an isolated office for the project. This helps the members to work in close proximity with each other and have a sense that they are working for only that project which in turn increase their commitment. Takeuchi and Nonaka (1986) argues that all the information is shared easily without even trying when the members are located in the same place. In addition to that, de Sousa and Almeida (2011) states that frequency of the interaction between team members are closely related to the proximity between the physical spaces between them. Inadequate working environment can decrease the team’s performance through the project. Lacking facilities like large workspaces, meeting rooms, silent rooms etc. can decrease the team’s interaction opportunities and get them distracted while working. 29 2.3.3 Process Based and Organisational Factors Organisational culture, procedures and how processes are handled are deterministic in how teams perform. This section will review the literature for barriers resulting from organisational culture and agile project process. Organizational Culture All the teams in an organisation act according to the culture of the organisation and reflect the culture of the mind-set it belongs to. Therefore, effectiveness of the teams is largely dependent on behaviour and agile understanding of the organisation and it is important for organisations to support the agility of the agile teams performing under their roofs. “Teams themselves can influence the internal organization of teams, but team performance depends not only on the competence of the team itself in managing and executing its work; it also depends on the organizational context provided by management”(Guzzo and Dickson, 1996, cited in Gulliksen Stray et al., 2011). Organizational culture can enhance the performance of teams as well as hinder them. Procedures, hierarchical bureaucracy and traditional mind-set can influence team members not to act according to how their agile method requires. Agile Process All the agile software teams act and decide according to some pre-defined set of rules and with the help of standardized artefacts. Therefore team’s success in application of their specific set of process rules have significant effect over the performance of the team. “Without a proper development process in place, a project team could operate in a chaotic manner, resulting in low productivity and poor system quality.” (Paluk et al., 1993, cited in Chiang & Mookerjee, 2004). Although agile methodologies are most effective when oriented on “product instead of “process” (Fernandez & Fernandez, 2008), sticking to rules of process acts as a steering wheel for the team to reach their goals. This section focuses on subjects related to planning, meetings, iterations and documentation. 30 Planning Planning is one of the most important activity in agile software projects like any other project type. Agile projects differ from traditional ones with simpler and repeated planning that enables teams to take corrective actions in time. Marks et al. (2001) stated that teams primarily focus on planning to accomplish their objectives. Planning activities involve pre-action preparations which can be identified as “prioritization of goals and sub goals for mission accomplishment”, “…identification of main tasks as well as the operative environmental conditions and team resources available” and “…development of alternative courses of action for mission accomplishment… discussion of expectations, … prioritization of role assignment, and the communication of plans to all team members.”(Marks et al., 2001), post-action critics to “better understand the underlying causes of previous performance [to] … better prepare for future efforts” (Blickensderfer, Cannon-Bowers and Salas, 1997, cited in Marks et al., 2001). Project context going out of the plan scope, team (willingly or unwillingly) not acting according to plan or being unable to accomplish the iteration plan is not uncommon in projects. “No work-related tasks are performed in a vacuum, unaffected by deadlines, time limits, or schedules.”(Marks et al., 2001) Not acting according to plan have many risks. Gulliksen Stray et al. (2011) observed that team members prioritized individual goals over team goals and motivation of the team members decreased when an unrealistic plan is made. Meetings An important requirement for every team to stick to in the agile process is meetings. Kraut and Streeter (1995) defines meetings as a way of formal information exchange. In addition to periodic meetings with bigger contexts such as iteration planning and retrospective meetings, daily stand-up meetings play an important role in synchronizing the team members and get rapid feedback. General meetings help the team set their long-term objectives while daily meetings help them to make fine-adjustments to their daily actions. Unsuccessful realization of such an important element of projects may decrease teams’ overall performance. Some of the reasons for such results are participants being unprepared, necessary decision makers and team members 31 not being available at the meetings and context of the meetings being out of scope. Moreover, Gulliksen Stray et al. (2011) stated that the team they observed had problems with not spending enough time planning the upcoming sprint. Iterations Agile methodologies depend on repetitions of smaller scale execution phases aimed to bring a working prototype of the final product at the end. These iterations start with the iteration planning where the objectives are determined and ends with an evaluation and retrospective meeting. As a rule, scope of iterations are fixed until the end. In other words, it is seldom that new objectives are added or current objectives are removed from that iteration’s feature list. Sprints have fixed durations which are decided at the beginning of the projects. Those durations are determined according to the complexity, time constraints and available resources of the project. “For a given set of requirements, a shorter construction time should translate to a larger team and thus more expensive coordination among the team members.” (Chiang & Mookerjee, 2004) Moe, Dingsøyr, and Røyrvik (2009) observed that making changes during the iterations resulted in difficulties with delivering according to the sprint-plan. Chiang and Mookerjee (2004) states that unrealizable planning causes team to exhaust and increases stress during iterations. 32 3 Methodology & Data Collection 3.1 Introduction The purpose of this chapter is to describe the research, data collection and data analysis strategy. Chapter begins by defining the research question and describes the methods of the research by explaining the rationale behind the selected methods. Next, research procedure, which includes academic review of knowledge and data collection and analysis regarding the research question is defined. Chapter finishes by explaining the ethical considerations during the research and limitations of the research method. 3.2 Research Question Based on initial research about agile software project management and team dynamics, author decided that factors relating to the performance of agile teams are important when managing the well-being of the projects. Assuming that eliminating negative effects are as important as fostering positive ones, this research is trying to find answers to following question: What barriers are there that decrease team performance in execution of agile software projects? 3.3 Characteristics of Research 3.3.1 Introduction This section explains the characteristics of this research method to gives the reader a better understanding of what methods researcher used to create the knowledge and the reason for selection of the methods. It includes the research paradigm of the researcher while conducting the research, then continues with explaining the methods of data collection to be used. 3.3.2 Interpretivism (Research Paradigm) Understanding and evaluating a research question is affected by the view of researcher’s point of view. Moreover, the justification of a theory in a research depends on the rationale behind the explanation and proof of the data and information given by the researcher. Therefore, the knowledge created in a 33 research is explained from the researcher’s point of view. Fellows and Liu (2009) state that scientific knowledge is falsifiable rather than verifiable, meaning that while result of a single test to disprove the theory is sufficient, hundreds of results that supports the theory is not enough to prove its correctness. This statement creates the need for the researcher to explain his point of view. Especially in subjects related to people’s behaviour like this thesis’ topic, results depend significantly on how researcher approached the question and what he considers to be important . Saunders et al. (2009) and Fellows and Liu (2009) mention the term paradigm in their work. “Paradigm is a way of examining social phenomena from which particular understandings of these phenomena can be gained and explanations attempted” (Saunders et al., 2009). Fellows and Liu (2009) defines it as a framework to view a system, comparing it to a lens. Author’s paradigm in this research is connected to how he tries to understand the sources of barriers and whether these are facts independent of social environment or not. Fellows and Liu (2009) describe two different paradigms in their research: Interpretivism and positivism. In addition, Saunders et al. (2009) mentions about two other paradigms: Realism and pragmatism. Author of this research’s paradigm is interpretivism. It will be explained and rationalised together with the alternatives. Interpretivism This research adopts interpretivism for its research philosophy. It tries to identify various barriers that decrease team performance without assessing their importance or level of impact with respect to each other. Therefore, for this exploratory research, it is important “to understand differences between humans in our role as social actors”(Saunders et al., 2009), and avoid generalizations. Because, as it was stated in (Fellows & Liu, 2009), one person’s reality that is derived by observations and perceptions can be different from another’s. Therefore, author believes that results found are in this research dependent on various factors like culture, time-frame and personal opinions of research participants and can be different when the study is repeated under different conditions. 34 Alternatives There are three alternatives mentioned in works of (Fellows & Liu, 2009) and (Saunders et al., 2009). These are positivism, realism and pragmatism. This section will explain those alternatives and will give the rationale for not adopting those paradigms for this research. According to (Fellows & Liu, 2009), positivism is an approach that recognises only non-metaphysical facts and observable phenomena. Payne and Payne (2004) states that in positivism, the researcher makes up theories that are external to observer, meaning that the interpretation does not depend on perceptions of individuals. Those theories are testable and repeatable and come to form from deductive reasoning. (Saunders et al., 2009) states that in realism approach, what our senses show us as reality is the truth. Considering interpretations of (Saunders et al., 2009) and (Payne & Payne, 2004) key difference between positivism and realism is that while they both assume a scientific approach to create knowledge, realism accepts that there are less observable forces that lie behind the phenomena. In that sense, realism can be thought as an approach accepting that observable phenomena are external to human existence but giving less emphasis on empirical understanding with respect to positivism. Pragmatism is another approach that is mentioned in (Saunders et al., 2009). The logic behind this philosophy is that instead of selecting an absolute stance for the research like positivism or interpretivism, researcher can adopt the most appropriate approach that enables him to explain the phenomena best. Saunders et al. (2009) states that in pragmatism, the important thing is to answer the research question and different philosophies may be beneficial for answering some questions in the research. These three different alternatives to interpretivism were not adopted for this research since the research question and author’s approach to creating knowledge does not require absolute facts and statistical derivations. Moreover, aim of the study is to identify the barriers, which are interpretations of the research participants. Therefore, a philosophy that accepts that the knowledge that is trying to be created is subjective and dependent on the stance of people who interprets them is adopted for this research. 35 3.3.3 Induction (Data and Theory Relationship) Induction and deduction are two methods to create a relationship between the collected data and formulation of an hypothesis. It is claimed in several studies (Fellows & Liu, 2009; Saunders et al., 2009; Strauss & Corbin, 1998) that deduction is used when testing a hypothesis using the collected data and when application of empirical methods are suitable. However, induction method uses the collected data to arrive to generalisations and theory building. This research, as it adopted interpretivism approach and theory building with the collected data, uses induction to create knowledge. Studies mentioned earlier state that literature review and data should be analysed together when using inductive approach. This research critically analyses the data collected from the interviews with respect to the literature review to create knowledge. 3.3.4 Qualitative Inquiry (Data Collection Approach) Method of inquiry explains the selection of how data will be collected to explain and prove/disprove the research question. Studies made by (Fellows & Liu, 2009; Payne & Payne, 2004; Saunders et al., 2009) state that data collection methods can be qualitative, quantitative or a mix of the two. Qualitative methods are used when the concern is to find out the interpretations of people with smaller sets of samples. Quantitative methods are used when statistical explanations, behaviours that can be represented by numbers, associations between variables are studied with a bigger sample set to permit a level of generalisation. Selected approach for this research is qualitative inquiry. Data to be collected is required to be interpretations of people who are knowledgeable or experienced enough to express their point of view with respect to the research question. No statistical derivations are intended to be made. Moreover, the sample set is designed to be small enough to manage in a limited time-frame, large enough to cover different viewpoints. 3.3.5 Interviews (Data Collection Method) To collect relevant data for qualitative research, two common methods that can be used alone or together are observation and interviewing. For this research, 36 data was collected with in-depth interviews. An alternative for this research would have been examining documents and recordings that were relevant to the research question. However, this method was not used for lack of resources and possibility of researcher bias while analysing the materials. 3.4 Research Procedure This section explains the steps of the overall research from beginning to the end. 3.4.1-Literature Review explains the approach in selection and inspection of knowledge in literature. 3.4.2-Data Collection explains the selection of interviewees and their characteristics relevant for research. Moreover, interview process is explained. 3.4.3-Data Analysis explains how literature knowledge and data collected are merged together to answer the 3.2-Research Question. 3.4.1 Literature Review The approach to literature was from two angles. Firstly, books about agile project management were studied to get a solid understanding of the context of agile project management. Next, academic journals that were written about agile project management were studied. Articles can be grouped under the following subjects:  Agile methods versus traditional methods,  Case studies about efficiency of agile project groups,  Development of agile theory,  People oriented challenges in agile projects,  General Software failures. Following, using references obtained from previously read articles and new searches, the subject of teamwork was studied. Articles can be grouped under the following subjects:  Teams versus working groups: What makes teams functional  Case studies of teamwork in agile projects,  Productivity in software teams,  Leadership in teams,  Factors affecting team functionality, efficiency and progress. 37 Using the literature knowledge, specified barriers were listed. Moreover, possible barriers that were interpreted by the author but that were not specified explicitly were added to the list. Next, these barriers are categorized under logical topics. Chalmers University Library and Google Books were used for available academic books. Chalmers Internet Library, Northumbria Internet Library and Google Scholar were used for article search. 3.4.2 Data Collection After literature review was finished, data collection work was started. The research was designed to be a qualitative one and data collection method was selected as in-depth interviews. Participants “The study of a small sample of subjects might be more appropriate than a large number as with the deductive approach”(Saunders et al., 2009). 8 agile project managers were contacted for interviews. 3 of these participants were reached to using Charm fair 2013 in Chalmers University of Technology (http://www.charm.chalmers.se). Remaining 5 people were found by search in LinkedIn(http://www.linkedin.com). Of these participants:  3 were Swedish, working in Sweden, 4 were Turkish, working in Turkey and 1 was Turkish, working in Finland.  All of the participants were working in agile software projects or had experience of agile projects.  7 of the participants were using Scrum methodology while one of them was using a mixed methodology of Kanban and Scrum.  All of the participants had project management experience, mainly the scrum master role. Interview Process After an interview date was arranged, consent forms and interview topics were sent to participants 1-2 days before the interview. Signed consent forms were collected before the start of interview. Whole interview process took three weeks to complete. 38 4 participants from Sweden were interviewed face-to-face in their offices. Remaining 5 participants were interviewed over Skype. Interviews were voice recorded and notes were taken by the researcher during the interviews. Unstructured interviews were conducted since an exploratory research was being made and researcher did not want to effect participants to have biased answers by asking direct questions or limit scope of the conversation by defining borders to questions. Appendix A – Interview Topics was used as a guideline during the interviews. Participants were asked to explain what kind of barriers they experienced or think there are about several topics. A preliminary interview was made with a professional as a pilot. Results from pilot interview are not included in the research. The way questions were asked and distribution of topics in the guide were modified accordingly. Interview durations varied between 30 minutes and 2 hours depending on time available and amount of information participants were willing to share. 3.4.3 Data Analysis Data analysis was done in two consecutive steps Transcribing After the interviews, voice recordings were listened again by the author and notes were taken. Categorizing After all the interviews were transcribed, answers that were about similar topics were grouped together and listed. Author interpreted and paraphrased answers instead of citing them without changing the meaning and intention of them. 3.5 Ethical Considerations Participants of interviews were project managers and they were asked to talk about team performance. Some of the discussion topics like personal competencies or communication problems had danger of exposing team members’ personal deficiencies or habits that interviewees’ think they have. Exposure of these information may put interviewees in a difficult situation. 39 To make sure that interviewees will not be threatened in their professional and personal life, information gathered were documented anonymously, making sure that identities of interviewees will not be exposed. Moreover, interviewees were informed about those ethical considerations and were asked to confirm that they accept the interview under those conditions. In addition, all the interviews were voice recorded with interviewees’ consent. Recordings were kept in a safe environment and were listened only by the researcher. All the recordings were destroyed after the research was finished. A copy of consent form which all participants were asked to sign can be found in Appendix B – Interview Consent Form 3.6 Scope and Limitations Due to limitations on time and resources, research’s scope was limited. However, limitations were kept at a level such that they did not prevent the research from making logical or unrealistic predictions. Literature review was focused on two methodologies that use agile principles: Scrum and XP. Moreover, geographical and cultural variations on perceptions of team efficiency were not studied. Instead, team efficiency was assumed to be interpreted same globally. Data collection was limited to agile project managers whose experience was mainly on Scrum methodology. Moreover, participants were either scrum masters or product owners. Lastly, participants were from countries with different business cultures. 40 4 Results & Data Analysis 4.1 Demographic Data Before the interviews, personal information related to their profession was collected. Below are information about the participants:  Age o Between 31-35 o Mean: 33,8  Gender o 7 male o 1 female  Country of work o 3 in Sweden o 5 in Turkey o 1 in Finland  Job Titles o Product owner o Project manager o Scrum master o Scrum team member o Principle software engineer o Business analyst o Agile consultant o Founding partner o Agile coach Some participants had more than one job title  Experience in working with agile projects o Between 1.5 years and 6 years o Mean:3,7 years Their experience includes working as a team member and/or project manager  Current Job Industry 41 o Automotive o Tobacco o Information systems o Telecommunication o E-commerce o Banking o Entertainment o Mobile devices o Public sector o Transportation o Retail o Architecture o Insurance o Defence Some of the participants worked in projects of more than one industry. 4.2 Analysis of Results Respondents answers included negative as well as positive factors that they have observed. Only the negative points were included in this research. Similar answers were grouped together. A summary of answers were given in each section as numbered items. Numbers do not signify any ranking or importance relationship between the items. 4.2.1 Interpersonal and Personal Perspective This sub-section lists the findings gathered from the interviews categorized under the subjects of culture, support, leadership, communication, team- ownership, learning, product owner/client and personal adequacy. Culture Question of “What do you think about culture’s role in team performance?” was asked to participants. Their answers included negative as well as positive factors that they have observed. Only negative points were included in this research. Some of the participants said that they did not observe any negative 42 effect of culture based factors. Similar answers were grouped together. A summary of answers were given below as numbered items. 1. People with distinct cultural differences sometimes create social interactions that other team members feel uncomfortable. One of the participants mentioned a team member-who was from another country culture- was “speaking demanding and with a tone”. Other members in the team felt uncomfortable for getting in social interaction with that person. Another participant commented that his team was from a more relationship focused culture and the way of speaking people they communicate with for their project was unusual to them. Some team members felt offended by the direct speaking habit of these people. He added that those people were also thinking that the team members were “very emotional”. 2. Another factor that was addressed was ego of team members preventing them from being a good team player. Lack of traditional hierarchy based titles in the scrum teams offended some people when they started working with scrum. Losing their ‘senior’ titles to mere ‘scrum team member’ title made them feel uneasy. Participant commented that some people even left the company after their titles changed. Another participant noted that the ‘master’ phrase in the ‘scrum master’ title created “ego boom” in some people. They all argued that egos getting is a potential barrier in the teams. 3. One of the participants argued that significant age differences hinder people from working as a team. Some people felt uncomfortable working with other team members who were significantly younger. He argued that age differences were preventing people from having a fruitful interaction. 4. One of the points that most of the participants agreed on was that working with introvert people is a serious problem. Those team members who were used to working alone and not comfortable with high degrees of social interactions were hindering the teams’ performance. Their “reactions against socialising” were problematic when creating an effective team-working environment. 5. One of the respondents commented that there are sometimes people with “sharp characteristics” in the teams. He argued that “It can be hard to form a team culture with these people. The project manager needs to 43 find a midway between people to make everyone as comfortable as possible”. 6. One of the respondents commented that some people in the team are used to working ‘according to the book’ and added that they were trying to stick to the rules even if the rules were not helping. 7. One of the respondents noted that there are some people who are disciplined and some people are more slack during work times. He added that “if people who are not giving their hundred per cent cannot be addressed by the project manager, it can be a barrier”. Support Question of “What do you think about support’s role in team performance?” was asked to participants. 1. Some of the respondents argued that creating the environment for support is not easy. One of the reasons for this problem is that “it is often considered to be a routine and boring task”. Encouraging team members to give and request support in the team takes time. A respondent commented that “you cannot expect the results to just produce from thin air; you have to make an effort”. 2. According to respondents, trust was one of the factors that hinders the support environment. People not being honest to each other decreases the time they spend on giving and receiving feedback and help. Moreover, one respondent commented that blaming each other when there is a problem to get rid of the possible responsibility of failure causes the team to dissolve. One responded commented that creating an efficient team environment requires a certain amount of trust between the members and this requires the team members to be honest to each other. 3. Two respondents argued that teams do not usually have time for giving and receiving proper support. Team members become so occupied with their tasks at hand that they cannot respond to support requests from other members. Moreover, one responded argued that when people are new, they see problems but when they get experienced, they cannot find time to make the effort to make them right. 44 4. Another comment on this topic was that team members are not aware of their expertise and for that reason they do not act proactively when they could. 5. Behaviour of technically senior people in the team is important according to some of the respondents. One respondent claimed that some experienced people hide information intentionally. Another argued that experienced people prefer to work with other experienced members to advance more in their technical expertise. Moreover, one claimed that some people try to stand out in the team by trying to act like they know more than they do. This results in inefficient support and discomfort from other team members who do not appreciate the behaviour. 6. Hesitating to request help is one of the common problems according to respondents. Some team members are too shy to ask for help or they think that people judge their expertise when they do. One respondent claimed that if there is a team member who hesitates to ask for help, than the required team environment was not created. Moreover, he added that refusing to help for whatever reason discourages other team members to ask for help later on. 7. One respondent argued that support in a way of criticism instead of encouraging can be dangerous for the team. Leadership Question of “What do you think about leader’s role in team performance?” was asked to participants. 1. Some of the answers were related to the characteristics of people in the team and how the leader interacts with them. One respondent argued that if there is a fragile person in the team, the leader has to be careful when addressing him since they can demoralize easily. Moreover, another respondent noted that some people in the team are hard to reach and leader should pay special attention to them to make them express themselves. 2. Another point in the context of leadership is that leader’s personality has a direct effect on the performance of the team. One respondent commented that the leader should be a role model and set an example for the team. Another argued that poor leadership causes team to 45 underachieve and lose their motivation. Making mistakes was accepted as a normal event but one respondent said that leader should be able to admit the mistake and try to repair it. Moreover, one respondent argued that leaders with inadequate social capabilities and who cannot lead the team to act according to their designated process causes performance droppings in the team. 3. Leader’s behaviour against the team is also important in motivating the team. Two respondents argued that the boss-type hierarchical leadership does not apply to agile teams and even demotivate the team. Roles of the leader and product owner should be distinct and the leader should neither try to act like a product owner nor allow the product owner to micromanage the team members 4. Team leadership was another point that some of the respondents thought was important. One respondent argued that there should be context based natural leadership where anyone in the team who has experience about the current context should act as a leader when it is convenient. Otherwise the team would not be able to use the knowledge of the experienced people in the team. It is commonly accepted throughout the respondents who commented on team-leadership that it is more beneficial for the team to have the team itself as a hero instead of individual heroes. 5. Protecting the team from outside distractions was thought to be high of importance in the team. Sales department, customers, upper management or people from other projects constantly interrupts the team to get support from them. One respondent said that the team should be protected by the leader from outside distractions to keep them focused on their project tasks. However, one respondent argued that sometimes leader’s political force may not be enough to protect the team member from requests from someone higher in hierarchy. Nevertheless, outside distractions was accepted as a factor that hinders the team performance and it should be addressed by the leader if needed. 6. One respondent argued that the leader should be focused only on the