Challenges to Teamwork: A Multiple Case Study of Two Agile Teams Viktoria Gulliksen Stray1, Nils Brede Moe2, and Torgeir Dingsøyr2 1 University of Oslo, Gaustadalléen 23, 0373 Oslo, Norway stray@ifi.uio.no 2 SINTEF, SP Andersens veg 15 B, 7465 Trondheim, Norway {nils.b.moe,torgeird}@sintef.no Abstract. Agile software development has become the standard in many companies. While there are reports of major improvements with agile development over traditional development, many teams still strive to work effectively as a team. A multiple case study in two companies discovered challenges related to communication, learning and selecting the tasks according to the priority list. For example, the fact that the developers were not actively involved in the planning process, resulted in weak team orientation; even though the teams had identified and discussed recurring problems, they found it difficult to improve their teamwork practices; and because customers and support communicated tasks directly to the developers and developers chose tasks according to interest and expertise, following the priority list became difficult. We provide practical suggestions for teamwork in agile software development that intend to overcome these problems and strengthen team orientation and team learning in order to achieve effective agile teams. Keywords: Teamwork, Team orientation, Team communication, Team learning, Agile methods, Agile Software development, Scrum, Kanban. 1 Introduction Teamwork is important in software engineering and is a particular focus in agile development. Teamwork has been extensively studied in a number of fields, but little of this knowledge has been applied in the context of software development. One of the reasons may be that the general knowledge needs to be tailored to software development to become useful. Hence, there is a need for additional studies on teamwork in this specific area. Agile methods such as Extreme Programming (XP) and Scrum direct software development in small, self-managing teams. While there are reports of major improvement with agile development methods over traditional development methods [1], effective teamwork is still a challenge. In a number of studies in small and large Scrum teams in various consulting and product development settings in companies of variable size through the last five years, we have observed three recurring challenges [2-4]: A. Sillitti et al. (Eds.): XP 2011, LNBIP 77, pp. 146–161, 2011. © Springer-Verlag Berlin Heidelberg 2011 Challenges to Teamwork: A Multiple Case Study of Two Agile Teams 147 Solving the wrong tasks: Team members often work on tasks that have low priority or are not even prioritized. Many developers also choose only tasks within a given component, type of module or type of technology due to interest or felt ownership independently of priority. These practices are not consistent with the focus in most agile methods on delivering the highest prioritized functionality to the customer. Lack of communication: Sometimes critical decisions are taken by the project management without involving the team. This happens despite the strong emphasis on communication and shared decision-making in agile development methods. On the other hand, many team members approach only the team leader in the daily meeting and not the whole team. Moreover, we have observed team-members who did not pay attention when important issues were raised, and even a few who fell asleep in planning meetings. Unreleased potential of learning: Agile development methods suggest several ways of giving feedback and create opportunities for analyzing experience. However, we have observed that many teams spend little time reflecting on how to improve how they work, and they do not discuss obvious problems. Some of the teams that carry out regular retrospective meetings struggle to convert their analysis into changes in action. Among those who try to remedy identified problems actively, several give up after seeing little change. In this paper, we discuss and explain these three challenges further. We investigate the following research question: Why do many software teams find it hard to adhere to the task priority list, communicate well, and release the potential of learning? The remainder of the paper is organized as follows. Section 2 describes recent research on teamwork in other fields, as well as in agile software development. Section 3 presents the research design chosen for this study. Section 4 reports the results from two case studies. Section 5 discusses these results in relation to general teamwork theory. Section 6 concludes, including giving suggestions for theory and practice. 2 Teamwork One of the main characteristics of agile methods is that software development should be organized in small, self-managed teams [5]. The focus on teamwork as a research area within software development is relatively recent, but teamwork has been subject of research in several other disciplines for many years, from small group research to work life research to management science [6-11]. Activities found to be important for successful teamwork are as follows: responding constructively to views expressed by others, giving others the benefit of the doubt, providing support to others, and recognizing the interests and achievements of others. These activities have been demonstrated to be important because they promote individual performance, which boosts team performance, which in turn boosts organization performance [10]. Exploiting the potential advantages of setting up work teams, such as increased productivity, innovation, and employee satisfaction, requires a successful implementation in a given organizational context. 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 [6]. 148 V.G. Stray, N.B. Moe, and T. Dingsøyr Which processes and components that comprise teamwork and how teamwork contributes to team effectiveness and team performance have been the focus of a number of studies [12-16]. Salas et al. [15] identify 136 models and frameworks in a literature review and discusses a representative sample of 11 of them in more detail. Moe et al. [17] suggest five elements from team effectiveness models that are particularly challenging in agile software development. Here, we have chosen to focus on two of them: team orientation [18, 19] and team learning [18, 20], which are both critical for self-managing teams and explain challenges observed in two teams studied. For a deeper understanding of teamwork, it is necessary to understand the different processes of a team. Marks et al. have developed a recurring phase model of team processes [16] which we have used. In the next sections we describe the two elements team orientation and team learning, and then present the framework for team processes. 2.1 Team Orientation Team orientation refers to the team tasks and the attitudes that team members have towards one another. It reflects an acceptance of team norms, the level of group cohesiveness, and the importance of team membership, e.g. assigning high priority to team goals and participating willingly in all relevant aspects of the team [21]. High team orientation is claimed to improve the overall team performance in selfmanaging teams, makes team members coordinate more, and also to improve individual effort [22]. A high team orientation implies that the teams have shared goals, and work together to achieve these goals. Team members take alternative solutions provided by other team members into account, and appraise that input to determine what is most correct. Another indicator of high team orientation is increased task involvement, information sharing, strategizing, and participatory goal setting. If team members do not show interest in other person’s tasks, or do not ask for input and suggestions to alternative solutions, that is a sign of low team orientation. 2.2 Team Learning Learning is important in all software teams. Also, for agile teams to stay self-managed a capacity for double-loop learning that allows operating norms and rules to change is required [18]. Double-loop learning is distinguished from single-loop learning in that it concerns the underlying values. If an agile team repeatedly changes practices without solving their problems, this is a sign that they have not understood the underlying causes of their problem, and is practicing single-looped learning. Lynn [23] argues that learning has a direct impact on cycle time and product success, and has identified two factors that are central for learning; capturing knowledge, and a change in behavior based on the captured knowledge. Practices that must be in place for this to happen are among others; recording and reviewing information, have goal clarity, goal stability and vision support. Establishing shared mental models is a factor related to learning. Salas et al. [15] describe behavioral markers such as anticipating and predicting other team member’s needs. In addition, that the team is able to identify changes in the team or task and implicitly adjust strategies as needed. Challenges to Teamwork: A Multiple Case Study of Two Agile Teams 149 2.3 Team Processes For understanding team processes in this study we use the taxonomy developed by Marks et al. [16] through their extensive literature review. The taxonomy includes three categories: transition phase processes, action phase processes, and interpersonal processes. Transition phases are periods of time when team members focus on processes such as mission analysis, evaluation, establishing shared vision, planning, goal specification, and formulating strategies. Planning meetings in agile software development are transition phase processes. During action phases, team members conduct activities leading directly to goal accomplishment. In this phase the team concentrate on task accomplishments, monitoring progress, coordinating team members, as well as monitoring and backing up their fellow team members. Solving tasks will alternate between transition phase processes and action phase processes. The interpersonal processes includes conflict management, motivation and confidence building, and happens throughout transition and action phases. 3 Research Design and Method We have studied two teams as the basis for the findings presented in the next section. In this embedded multiple case study [24], we report on two concepts, team orientation, and team learning through description of episodes from the two cases. Table 1. Characteristics of the two teams in this study, North and South Project Product Agile Method Years using agile methods Team size North Geographical information system Scrum 2 4 South Content management system Scrum/Kanban 10 10 We chose two teams as cases from companies operating in different domains with varying years of experience using agile methods, see Table 1. Both teams used agile development practices to improve their ability to deliver iteratively and on time, increase software quality, and to improve teamwork and team communication. The project in Company North started in February 2007 and was supposed to be delivered by January 2008, but was not finished by February 2008 when our data collection ended. The project we observed in Company South started in April 2000. Scrum was used from the beginning. The client of the project was a Fortune 500 industrial company and the main product of the project was a custom-made web-based content management system (CMS). We observed the team from March 2010 to October 2010. We have collected data from observations, semi-structured interviews and documents. To understand how team orientation was developed and maintained in the projects, we observed activities where the team interacted with each other and with the surroundings: daily work and meetings (daily stand-up, planning, review, and 150 V.G. Stray, N.B. Moe, and T. Dingsøyr retrospective). For understanding team learning the daily meetings and retrospectives were important. The interviews and studying project documents also provided us with vital information for understanding the two factors. An overview of the data collected can be seen in Table 2. The observations lasted from 10 minutes to a full day. The interviews lasted from 20 to 60 minutes and were audio-recorded and transcribed. Table 2. Overview of the data collected for the study Source Observations Interviews Documents Company North Daily stand-up meetings (19), sprint planning meetings (4), sprint reviews (6), retrospective meetings (1) and other meetings (42), as well as observation of coding, testing and informal communication. The 72 observations were documented in field notes, which also included pictures. Developers (3), scrum-master (1), product owner (1). The 5 interviews were transcribed. Product backlogs, sprint backlogs, burn down charts, index cards and recorded data from Team System. Company South Daily stand-up meetings (15), retrospective meetings (2), other meetings (31), and observation of coding, testing and informal communication. The 48 observations were documented in field notes, which also included pictures. Developers (6), Project leaders (2, one technical and one functional). The 8 interviews were transcribed. Presentations and reports. We took field notes and pictures as well as collected iteration and project plans, meeting minutes, progress charts, and index cards used on project walls. We integrated all our notes to produce a detailed record of each session. On the basis of this broad material, we used meta-ethnographic methods to analyze and synthesize data from the transcribed interviews, dialogues, and field notes. The transcribed interviews were imported into a tool for analyzing qualitative data, NVivo. We categorized interesting expressions using the teamwork concepts described in Section 2. After the analysis we presented the findings in feedback meetings with the companies. 4 Case Analysis In this section we present the two projects and report characteristic episodes, which show aspects of team orientation and team learning. The projects were perceived as successful by the customers, team members and management, but they still had some challenges. One might think that the North project experienced challenges because they only had been using agile methodology for two years, but we observed similar difficulties in the South project even though they had used agile methods for ten years. 4.1 North Project The goal of the North project was to redevelop a software package used internally to handle reports from customers. Initially the project consisted of two developers Challenges to Teamwork: A Multiple Case Study of Two Agile Teams 151 (one junior developer recently hired and working 100% on the project, and an experienced developer working 50-100% on the project), a scrum-master, a product owner, and a project manager. The scrum-master also did some development. In addition he had the role as department head, which meant he had many other obligations. The project manager was cooperating with the product owner to define the features, in addition to being responsible for the budget and communicating with the top management. The product owner and the project manager were situated in another city. Two months after start-up, a third experienced programmer joined the team. He was working 50-100% on the project. 4.1.1 Team Orientation To achieve team orientation the team goals and vision need to be established among all team members. The one in charge for this in the North project was the product owner. However he was situated in another city and the team had to communicate with him using phone and e-mail. In the beginning they communicated on a daily basis, but the project owner was working on multiple projects and was often not available. Sometimes the team got stuck because they could not get immediate feedback from him and then discussions ended without conclusions since they were lacking vital information. During the last phase of the project one developer said while writing code: “We need to talk to the Product-owner, but he is on a vacation. I guess he do not really care too much, and this affects us as well.” The scrum-master was the head of department, and he often got tied up in other tasks. He frequently left in the middle of a workshop or meeting to answer an important phone call. When this happened the discussions and processes in the meeting were put on hold until he got back. It seemed like the scrum master gave priority to other tasks, and this affected the team members as well. The team meetings usually worked well and included everyone, however the planning meetings where the product owner and project manager participated often failed when it came to building team orientation. In one meeting we observed that the two developers, who usually participated actively in other meetings, were mostly quiet. We also noticed that the discussions focused on issues relevant to the product owner, project manager and scrum-master. The meeting did not have a clear agenda, and the topics discussed often excluded the developers. At the last part of the meeting, there was not enough time available for planning the upcoming sprint in detail, which was the primary goal of the meeting. This affected the developer’s chance of really committing to the team goals and plans, which is necessary for achieving team orientation. Not only the meetings were important for building team orientation. The scrummaster and the team early identified what they called project concerns. A project concern [25] is a functional aspect that is considered to be of such importance that it should be treated separately and be specifically visible through the project. The team defined the concerns to be performance and reliability. The concerns were supposed to make it easier for the team to prioritize, decide and lead when working on the architecture and implementation. We observed several times that this helped the team identify and dealing with conflicting features and when prioritizing. This obviously strengthened the team orientation. 152 V.G. Stray, N.B. Moe, and T. Dingsøyr The project showed good progress in the first phase, however soon the situation changed. One reason was that the developers worked less than planned on the project. In this company, developers worked on several projects at the same time, and also needed to solve support requests on products they had worked on earlier. The effect of this was that developers were frequently interrupted, the project lost resources and developers had to work not only on their running projects. In a standup–meeting, the scrum-master asked: “Will you work on the project this week?” Developer 1: “Yes, probably today or tomorrow.” Developer 2: “I will most likely work on the project today.” In the following stand-up we observed that developer 2 had not done anything because of several emerging issues in other projects When talking about the effect of this, one developer said: “When you during a sprint realized that you would not finish, you did not care if you were 70% or 90% done. It didn’t matter. These tasks were just moved to the next sprint, but then we also needed to add several other tasks to show progress… We classified tasks as finished before they were complete … Each sprint starts with doing things that we have said were done, and then you know you will not finish the sprint. Since we knew we could not finish, we did not care if we didn’t complete all the tasks during a sprint. Some tasks were moved 4 sprints before they were even started.” An unrealistic plan made the team members prioritize individual goals over team goals. As a consequence when picking tasks, a developer picked the one he was most interested in solving, not the one with the highest priority. Subsequently this affected team orientation. 4.1.2 Team Learning In one retrospective the problem of adding too many features, loosing resources, and not doing proper testing was discussed, and the team agreed that next time they would start on the right level and schedule enough time for testing. Our data indicate that this situation did not change much. The team did not manage to transform their experience into action, there was no real team learning. The project introduced “The wall” in this phase to get a better overview of the project status. Every task was then visible on the wall, and categorized into “not started”, “in progress” and “finished”. “The wall” made it visible to everyone that they were working on a lot of tasks in parallel, however they did not change the process. One month before the final deadline, it became apparent to everyone that the team was delivering too slowly and could not meet the deadline. The scrum-master said: “We found a solution to the problem. We agreed on postponing the deadline, keeping the functionality, and then isolate the team.” The scrum-master decided that the team was not even allowed to receive phone calls, while in isolation. This was broadcasted generally in the company. The scrum-master now collocated with the team to help protecting them. The team also agreed on working overtime. Isolation of the team was not 100% effective, especially when the scrum-master was absent. One developer said: “The isolation works how it should do, but we end up in a dilemma. Like today, it’s crazy in the other project, where the customers are starting to use the system this week. And I’m the only one who can fix problems. Then I just need to help if they are having problems. I do not like to decide which project Challenges to Teamwork: A Multiple Case Study of Two Agile Teams 153 Fig. 1. The team with “The wall”, giving an overview of project status will not meet its deadlines, because that is what it is all about. But now the scrummaster has decided what to prioritize. However I feel I need to do it anyway; during the day or before I go home. There is no time allocated to this kind of support, and there are several people expecting me to solve the problems.” The isolation was most effective when the scrum-master was in the area, but the developers also felt it easier to say “No, I'm busy” when asked about something. The scrum-master also commented: “I can see that the team is working harder and more focused. Earlier, they seemed relaxed the first week of the sprint. Now they are relaxing the first day, but then they start to feel the pressure. But I do not know how long we can do this, how long the effect will last.” 4.2 South Project The project in South had two teams, one worked on maintenance and new development of the CMS-system, while the other worked with SharePoint development. The project had two project leaders, one functional and one technical. The product owner in the project was located in another country. The CMS team has been the focus of this study. This team consisted of nine developers and one technical project leader who also had the role as the team leader. Most of the developers were working 80-90% of their time on this project. Some of the developers had been on the project since the start. Before we started our study this project switched from Scrumbased development, which is time-boxed, to flow-based development, in their case Kanban. We were told that the motivation for doing this was the need for handling frequent changes to the plan, like interruptions from the customers and solving bugs. 4.2.1 Team Orientation Team orientation requires that the team members know what the project plans and goals are. However, most of the team members in the South project did not know the project plans, nor did they have a clear understanding of the project long-term goals 154 V.G. Stray, N.B. Moe, and T. Dingsøyr and vision. One developer said: “I don’t know how the release goals are defined. We get them in an e-mail from the project leader. The decisions on what to solve are not taken by the people who will work on it, but in collaboration between the project leaders and the product owner. We almost don’t know what to do until we see the task on the board”. The fact that the product owner was located in another country, made it hard for the team members to communicate with him directly. One developer said: “Often, if I want to say something I write an e-mail to the project leader in English, and then he takes it further to the product owner”. At the time we observed the South project they ran the project using a flow-based development process, Kanban, but they still conducted daily standup-meetings, which is a scrum practice. These daily meetings were held every morning at 9 o’clock by the interactive white board located in the middle of the office space, and lasted from 2 to 15 minutes. The daily meetings were seen as important for exchange of information and the intention was to make sure the developers communicated about their work at the start of their day. Even if this meeting was experienced as the most important meeting during the day people often came late. We were also told that some people disliked these meetings and we saw people acting uncomfortable and being silent. One person complained it was too early in the morning. The interviews also revealed that some team members did not pay attention to what others were saying. They found the meeting of low interest because the issues discussed were not seen as relevant to their own work. This was a bit surprising since the meeting only discussed what was going on in the project. This was a clear indication of low team orientation. The team had an interactive white board where everyone could see all tasks in prioritized order given by the product owner. This white board showed all the change requests and bugs for the next release and made the status of the project visible for everyone. The team members were supposed to pick the task with the highest priority. However, we experienced that team members often chose tasks according to their interest and area of expertise. The team members often felt it was obvious who should do what, and they seldom broke this pattern. This made them even more specialized and the amount of redundancy was very low. One project manager said: “We are very sensitive to the specialist competence. Today one of the developers has five tasks on the board. I asked him if there are any of them anyone else can solve, but there weren’t. So we clearly have trouble transferring knowledge. But the project is so big that everyone cannot know everything.” We also observed that some tasks did not get picked, even when it had the highest priority. The result was that the team leader had to delegate those tasks. The specialization resulted in own goals becoming more important than team goals. However we also observed that the team members often helped each other when one got a problem he or she could not solve. A daily challenge was the pressure of working on tasks not on the board. Accordingly, tasks not prioritized by the product owner or by the team. These tasks were often related to operation issues, customer requests and support. The team members found it difficult to say no to the customer. One developer said: “It often happens that the client goes directly to a developer and says: ``We have to do something about this now!” But I guess that is OK since it obviously must be a high priority task. The problem is that often the result of this is that we have to go past the limit we have set for maximum number of tasks we are supposed to have in progress.” Challenges to Teamwork: A Multiple Case Study of Two Agile Teams 155 Performing many tasks not agreed on by the team is an indication of problems with the team orientation. 4.2.2 Team Learning The daily meeting was seen as the most important forum for information flow in the project. The meeting was not working as intended, which was confirmed through the interviews. Several interviewees complained that they did not get enough information about what was going on in the project. Some felt that only a few people, often the people that had been on the project for the longest time, got a full overview of the project. One developer said: “The information flow has been poor since the start of the project ten years ago. We should have done something about it.” In the project the team had a positive attitude towards learning and appreciated the retrospective meetings, which were the primary means for discussing problems. Problems were identified, however they had difficulties solving them, for instance improving the daily meeting. They never found an approach that satisfied all team members. They had tried several ways; one of them was to focus on each individual in the team. They forced everyone to talk, by passing a ball around. A person was then supposed to talk when he or she got the ball. Unfortunately, not all team members followed what the team had agreed on doing, and started throwing the ball around to be funny. The team then stopped using the ball. They then tried to make the meeting go faster by only focusing on the obstacles slowing or stopping their progress. However if the team members said “no” when asked if they had any problems, the team leader said “back to work” and the meeting was over after about 2 minutes. When this happened there was almost no exchange of information. The third way of running the meeting was that the team lead pointed to specific tasks at the board asking for status. We observed that not all team members were satisfied with this way either, but this was the method in use when our data collection ended. Because of the request from people outside the team, measures were taken to protect the team members. This did not work out as intended. One project leader said: “We have tried to isolate people by making them pair program. We thought that maybe we could remove noise by having people sit together to produce on a task. It is much more difficult to reply to e-mails and answering the phone when you sit together with someone. We believed in this, but it was very hard to establish. There was no culture for doing it. I think you have to push really hard for it to work, maybe so much that it gets uncomfortable. People slide back to their usual patterns.” While the team focused on solving their challenges, they forgot to pay attention to what was actually working well. One effect was the team stopped doing their regular learning workshop. In the interviews, almost everyone claimed that they missed this workshop. Kanban focuses on limiting the amount of work in progress and visualizing work on the board. The team was satisfied with trying to keep the “work in progress” at a low level because they felt that when they managed to do this it made them more effective. We were also told that the product owner appreciated this way of coordinating work, since he now could constantly reprioritize and add tasks, instead of having to come up with a list of items for the next iteration every other week. 156 V.G. Stray, N.B. Moe, and T. Dingsøyr Fig. 2. A daily meeting, focusing on specific tasks 5 Discussion We have described teamwork in projects North and South with two and ten years of agile experience, Table 3 summarizes the key findings. Even though we report on their problems, we want to emphasize that the projects were perceived as successful by the customers, team members and management. Still there are several possibilities to improve the team performance. In the following, we discuss the two cases in light of our research question. Then we give some suggestions for practice. Table 3. Summary of key observations Team orientation Team learning Observations People running in and out of meetings Product owner giving priority to other tasks and projects Meetings without a clear agenda Topics discussed exclude developers in meetings Scrum master delegating tasks directly to developers Unrealistic product backlog and sprint plans Missing understanding of project plans and goals Product owner in another location Team members not paying attention in the daily meeting Picking tasks according to own priorities Working on unplanned tasks Not managing to transform lessons learned into action Isolation of team members to avoid interruptions Not paying attention to what is working well Project status information altered to show progress North X X X X X X X X X X X X X X South X X X X X X X X X Challenges to Teamwork: A Multiple Case Study of Two Agile Teams 157 5.1 Three Problems Our research question is “why do many software teams find it hard to follow the task priority list, experience lack of communication, and in releasing the potential of learning?”. These three problems were manifested in both cases: Following the task priority list was a challenge in both projects for several reasons. Specialization of team members in South, and unrealistic plans in the North project, was an important reason why the team did not always work on the tasks with the highest priority. When a team-member finished a task he picked a new one related to his own priorities. The specialization led to little involvement in other people’s tasks. In both projects, they did not pay enough attention to the “truck factor”, meaning that if one the developers gets hit by a truck, other team members should be able to pick up on the work of any developer. This resulted in little knowledge sharing and lack of redundant knowledge in the team. Both in North and South, there were tasks that were communicated directly to developers, which obstructed the progress of the team on the common goals. These tasks were either directly from the customer in the current project, or support requests from previous projects. In addition, there was little commitment to an overall plan, which is an obstacle for achieving team orientation. The teams were not sufficiently able to give everyone in the team insight in and ownership to plans and goals. Most developers in South expressed they knew little about the overall plan, and in North, we observed planning meetings as a discussion between the product owner, scrum-master and project manager, with little involvement by the developers. In North the project constantly had to fight for resources, which lowered team members motivation. Fully agile teams are supposed to have a flat team structure with peers. In North a small core of the teams, product owner and scrum-master, covered up issues rather than make them more transparent and empower others to participate. The project status information was altered to show management more progress than they really had. In South the scrum master had to delegate tasks directly to developers. This violates the flat structure of agile teams. Lack of communication was shown in the daily meetings in South. Team members seemed to dislike the daily meetings, and people were not paying attention to what others presented as it was seen as irrelevant to them, also people were not present from the beginning of these meetings. In North, project meetings were frequently disturbed because key persons went in and out. Further, communication with the product owner in both projects was cumbersome, as this person was not collocated with the team and was primarily reached by email. The unreleased potential of learning was shown through some of the problems the teams experienced. In North, the team was aware that they lost resources and that plans were unrealistic, but they did not do much to solve the problems until the very last phase of the project when they started isolation. The fact that support work was not a part of the official assignment of resources in North, although sprint burn down charts visualized that resources drifted away, shows problems with team learning. In South, they were aware of problems with the daily meetings, tried several practices to solve it, but these did not satisfactorily improve the situation. Also, in South, some practices that were working well gradually fell out of use. 158 V.G. Stray, N.B. Moe, and T. Dingsøyr 5.2 Suggestions for Practice This section will give some suggestions for practice on the basis of our observations, structured according to transition phase processes, action phase processes and interpersonal processes [16], as described in Section 2: Transition phase processes: Mechanisms to facilitate team orientation and team learning were missing in the planning meetings in North, resulting in few common goals and a lack of shared mental models. The meeting culture in North made involvement by the whole group difficult, and limited access to the product owner made the transition phases cumbersome. We observed that if the plans were perceived as unrealistic by the team members, their motivation for actually finishing all the tasks in the sprint decreased because they knew they couldn’t make it. In South, the team did not have to deal with unrealistic product backlogs and sprint plans because they used Kanban and therefore did not have to commit to a plan or spend time on planning in detail. Instead, they solved tasks that were constantly prioritized by the product owner. This made the project more flexible and less dependent on the product owner attending meetings at specific times. However, a consequential challenge was that the team members did not have a clear understanding of the vision and long-term goals of the project. This leads to the following suggestions for practice in the transition phase: • Allocate enough time, resources and facilitation in this phase in order to establish team orientation and make grounds for team learning. • Consider moving to more flow-based development if the sprint plan is often unrealistic. Action phase processes: In North, the productivity increased when they isolated the team. Moreover, both the teams in South and North had developed a culture of helping each other and had established an open dialogue. The policy in South was to not have more than 14 “work in progress” tasks, but we observed that they often struggled to keep below this number. In both North and South they had the challenge that team members chose tasks according to their interest and expertise instead of following the priority list. However in South this behaviour was more visible because of the visual white board. Also low redundancy became visible on the board when the team exceeded the “work in progress” limit and at the same time one person had too many tasks, and no one was able to help that team member. This leads to the following suggestions for practice in the action phase: Protect the team from external tasks during the action phases. Consider ways of limiting “work in progress”. Create a culture for collaboration when solving tasks and problems. The use of visual boards such as an interactive whiteboard makes low team orientation visible, and improves shared mental models. • Find ways to increase the amount of redundancy in the team. • • • • Challenges to Teamwork: A Multiple Case Study of Two Agile Teams 159 Interpersonal processes: Some conflicts were not dealt with in the teams, like customers getting priority by talking to developers directly, or when team members did not follow team decisions. In hectic periods, forums for discussing interpersonal issues, like daily meetings and retrospective meetings were abandoned. In South, the team was good at giving both negative and positive feedback to each other when testing and reviewing the code of each other. In North, most of the feedback to developers was on code not working correctly. This leads to the following suggestions for practice for interpersonal processes: • Provide forums for conflict resolution. Discuss deviations between agreed processes and practice, and adjust accordingly. • Encourage team members to give feedback to each other, especially positive feedback. 6 Conclusion This study investigated teamwork, in particular team orientation and team learning, in two software development teams that used agile methods. We identified many challenges related to team orientation, such as a lack of understanding of project plans and goals, and trouble with running the daily meeting in a satisfactory way. We also observed in both projects that team members chose tasks according to their area of interest and expertise instead of following the priority list, which made the redundancy low because the developers had little competence to solve tasks outside their specific area. To overcome this problem, the team leader had to delegate tasks not chosen by anyone. This meant that one of the principles of self organizing teams was violated. Two challenges related to team learning were the problem of transforming experience into action and lack of paying attention to what was working well. Some of the challenges we observed were related to the choice of the specific agile method. Successful sprint planning meetings in Scrum depends very much on the product owner. In North, the product owner and managers frequently discussed topics that were irrelevant to the sprint planning in these meetings, which resulted in plans that the developers found unrealistic. This had a negative effect on their team orientation. With Kanban development in South, the team did not have to spend time on planning in detail but could solve tasks that were constantly prioritized and added by the product owner. This made the project more flexible and less dependent on the product owner to attend meetings at specific times. However, a challenge resulting from this was that the team members had no clear understanding of the vision and long-term goals of the project. Based on our observations we provide some suggestions for practice. For example, if the sprint plans are unrealistic and change frequently during the sprint, one should consider moving from time-boxed development to flow-based development. If team orientation is low, consider using visual boards such as an interactive white board to improve shared mental models. 160 V.G. Stray, N.B. Moe, and T. Dingsøyr In the future we would like to see more studies of software engineering practice making use of existing teamwork literature. In particular, one should investigate team leadership, self-managing teams, shared leadership and mechanisms for team learning and increase of team motivation. These are areas that may have a profound impact on the effectiveness and efficiency of software engineering. Acknowledgments. This work was supported by the Research Council of Norway through grant 193236/I40. References 1. Dybå, T., Dingsøyr, T.: Empirical Studies of Agile Software Development: A Systematic Review. Information and Software Technology 50, 833–859 (2008) 2. Moe, N.B., Dingsøyr, T., Dybå, T.: A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology 52, 480–491 (2010) 3. Moe, N.B., Dingsoyr, T., Dybå, T.: Overcoming Barriers to Self-Management in Software Teams. IEEE Software 26(6), 20–26 (2009) 4. Moe, N.B., Dingsøyr, T., Dybå, T.: Understanding Self-organizing Teams in Agile Software Development. In: 19th Australian Conference on Software Engineering. IEEE Computer Society, Perth (2008) 5. Good, J., Romero, P.: Collaborative and social aspects of software development. International Journal of Human-Computer Studies 66(7), 481–483 (2008) 6. Guzzo, R.A., Dickson, M.W.: Teams in organizations: Recent research on performance and effectiveness. Annual Review of Psychology 47, 307–338 (1996) 7. Cohen, S.G., Bailey, D.E.: What makes teams work: Group effectiveness research from the shop floor to the executive suite. Journal of Management 23(3), 239–290 (1997) 8. Sapsed, J., et al.: Teamworking and knowledge management: a review of converging themes. International Journal of Management Reviews 4(1), 71–85 (2002) 9. Mathieu, J., et al.: Team Effectiveness 1997-2007: A Review of Recent Advancements and a Glimpse Into the Future. Journal of Management (34), 410–476 (2008) 10. Katzenbach, J., Smith, D.: The discipline of teams. Harvard Business Review 71, 111 (1993) 11. Sandberg, Å.: Enriching production: perspectives on Volvo’s Uddevalla plant as an alternative to lean production. MPRA Paper (1995) 12. Langfred, C.W.: The paradox of self-management: Individual and group autonomy in work groups. Journal of Organizational Behavior 21(5), 563–585 (2000) 13. Burke, C.S., et al.: What type of leadership behaviors are functional in teams? A metaanalysis. Leadership Quarterly 17(3), 288–307 (2006) 14. Hoegl, M., Gemuenden, H.G.: Teamwork Quality and the Success of Innovative Projects: A Theoretical Concept and Empirical Evidence. Organization Science 12(4), 435–449 (2001) 15. Salas, E., et al.: Fostering Team Effectiveness in Organizations: Toward an Integrative Theoretical Framework. In: 52nd Nebraska Symposium on Motivation, Lincoln, NE (2007) 16. Marks, M.A., Mathieu, J.E., Zaccaro, S.J.: A temporally based framework and taxonomy of team processes. Academy of Management Review 26(3), 356–376 (2001) Challenges to Teamwork: A Multiple Case Study of Two Agile Teams 161 17. Moe, N.B., Dingsøyr, T., Røyrvik, E.A.: Putting Agile Teamwork to the Test – An Preliminary Instrument for Empirically Assessing and Improving Agile Software Development. In: Abrahamsson, P., Marchesi, M., Maurer, F. (eds.) XP 2009. LNBIP, vol. 31, pp. 114–123. Springer, Heidelberg (2009) 18. Morgan, G.: Images of Organizations, p. 504. SAGE publications, Thousand Oaks (2006) 19. Nonaka, I., Takeuchi, H.: The knowledge-creating company: how Japanese companies create the dynamics of innovation, vol. XII, p. 284s. Oxford University Press, New York (1995) 20. Nerur, S., Balijepally, V.: Theoretical reflections on agile development methodologies. Communications of the ACM 50(3), 83 (2007) 21. Dickinson, T.L., McIntyre, R.M.: A conceptual framework of teamwork measurement. In: Brannick, M.T., Salas, E., Prince, C. (eds.) Team Performance Assessment and Measurement: Theory, Methods, and Applications, pp. 19–43. Psychology Press, NJ (1997) 22. Salas, E., Sims, D.E., Burke, C.S.: Is there a ”big five” in teamwork? Small Group Research 36(5), 555–599 (2005) 23. Lynn, G., Skov, R., Abel, K.: Practices that support team learning and their impact on speed to market and new product success (1999) 24. Yin, R.K.: Case study research: design and methods, vol. xiv, p. 219s. Sage, Thousand Oaks (2009) 25. Walderhaug, S., et al.: MAFIIA – an Architectural Description Framework: Experience from the Health Care Domain. In: Konstantas, D., et al. (eds.) Interoperability of Enterprise Software and Applications, pp. 43–54. Springer, Geneva (2005)