2013 ACM / IEEE International Symposium on Empirical Software Engineering and Measurement Obstacles to Efficient Daily Meetings in Agile Development Projects: A Case Study Viktoria Gulliksen Stray, Yngve Lindsjørn and Dag I.K. Sjøberg Department of Informatics University of Oslo, P.O. Box 1080 Blindern, NO-0315 Oslo, Norway {stray, ynglin, dagsj}@ifi.uio.no We have identified a few studies on meeting behavior in the field of small group research. The topics of investigation were: team meeting interaction [9], cultural differences in meeting norms [10], team meeting attitudes [11], public meeting facilitation [12] and how meetings are designed [13]. Abstract—Context: Most of the software organizations that use agile methods organize daily team meetings. Aim: Our aim was to understand how daily meetings are conducted and identify obstacles that reduce their efficiency. Method: We observed 56 daily meetings and conducted 21 interviews in three different teams in two countries. We used the repertory grid technique in the interviews and to analyze the results. Results: We identified thirteen obstacles. The four most prominent ones were: (1) The daily meetings lasted too long (on average, 22 minutes instead of the scheduled 15 minutes). (2) In the meetings that were not self-organized, team members reported to the Scrum Master instead of sharing information among all team members. (3) The interruption caused by daily meetings required substantially more time than the actual meeting time due to overhead before and after the meetings. (4) Several team members had negative attitudes towards the daily meetings. Conclusion: Organizers of daily meetings should evaluate whether the obstacles we have identified are present in their organization and consider our suggestions to remove or reduce these obstacles. In the literature on agile development, several studies indicate that daily meetings are vital to project success [1, 14-16]. However, there is little evidence to support software companies on how to conduct daily meetings. Given the increasing popularity of agile methods, the question of how to conduct such meetings in an effective way becomes even more pertinent. In one of our earlier studies, we found that the daily meetings were not efficiently performed because team members wasted time on defending decisions and convincing other team members that a great deal of work had been accomplished since the last meeting [17]. In another study, we found that most of the time was spent on elaborating problem issues and discussing possible solutions [18]. According to the agile literature [19], such discussions should be held after the daily meeting. Keywords—stand-up meetings; Daily Scrum; agile software development; collaboration; coordination; communication I. INTRODUCTION In addition to our own earlier research, we found only one case study that investigated the performance of daily meetings in agile projects [20]. That study found that many meetings did not start at the defined time and did not have a defined length. Some attendees were regularly late, and some were unfocused during the meetings. According to the developers, only the business team members benefitted from the meetings [20]. Communication and coordination are important but challenging success factors in software development projects [1-4]. Regular communication has been found to be a good way to build trust in teams [5]. Communication delays and breakdowns have been identified as a reason for schedule and cost overruns in software projects [6]. The daily meeting is a means to achieve regular communication among team members in agile software development projects. In these meetings, the team members inform each other, coordinate activities and discuss problems they face. The daily meeting is a mandatory practice in both Extreme Programming (XP) and Scrum. Daily meetings are also referred to as “Stand-up meetings” because people are recommended to stand in these meetings. In Scrum, daily meetings are often referred to as “Daily Scrum”. The purpose of the field study reported in this paper is to complement previous research by examining obstacles to efficient daily meetings. We interviewed 21 project members and observed 56 daily meetings over a period of 26 months. Obviously, there are positive aspects of conducting daily meetings, which were also revealed in collected data. However, given our focus on improving the ways daily meetings are conducted, an analysis of the positive aspects is beyond the scope of this paper. The remainder of this article is organized as follows. Section 2 provides an overview of the research method used. Section 3 reports the obstacles that we identified and their consequences. Section 4 discusses possible solutions to alleviate the obstacles. Section 5 describes potential limitations. Section 6 concludes. Even though general meeting activity in organizations continue to rise, few empirical studies on the effect of meetings are reported in the literature [7]. In particular, according to Bang et al. [8], there are few field studies of the association between actual meeting behavior and team effectiveness. The literature describes mostly approaches to and techniques for achieving effective meetings but without empirical support. 978-0-7695-5056-5/13 $26.00 © 2013 IEEE DOI 10.1109/ESEM.2013.30 95 TABLE I. No. of team members 8 10 14 Team name Mars Saturn Jupiter SAMPLE OF TEAMS No. of interviewees 6 5 10 TABLE II. Technique Volume Interview 21 Observation of daily meetings 56 Observation of other meetings More than 100 TABLE III. Team name Mars Saturn Jupiter All interviews N Avg. age Avg. years in company 41 47 33 11 13 2.2 DATA COLLECTION The topic in our case was obstacles to efficient teamwork. We asked the interviewees about issues that they perceived hindered effective teamwork. Using a five point rating scale, they positioned each of the issues with respect to three constructs that we had defined: “not serious vs. serious”, “seldom vs. often” and “easy vs. difficult to fix”. Description We conducted semi-structured interviews with open ended questions. All of the interviews were transcribed. We made notes from all the daily meetings we observed. Fifteen meetings were audiotaped, thirteen of these were transcribed. We had informal conversations with project members, and observed other meetings, including planning and retrospective meetings. We found that the repertory grid technique made it easier for the interviewees to talk about negative aspects of teamwork. The interviewees were encouraged to think aloud, which gave us valuable insight in the choices made by the interviewees. In three of the interviews, we did not find it necessary to apply the repertory grid technique because the interviewees already had said so much in the first part when they responded to the specific questions. LENGTH OF INTERVIEWS (MINUTES) 6 5 10 Mean 66 49 62 Median 61 48 66 Stdev. 21 11 17 Max 45 32 34 Min 96 60 87 21 60 60 17 32 96 II. technique [25] to obtain additional information. This is a technique where the main objective is to elicit the interviewee’s perception of a topic. Examples or instances of the topic experienced by the interviewee are called elements. The elements are rated (usually on a five or seven point scale) according to certain criteria, which are called personal constructs or only constructs. D. Observations of Daily Meetings Information recorded during the observations included, among others, attendee names and roles of attendees, type of discussions, leadership and facilitation of the meeting, number of participants present in each location and the atmosphere of the meeting. The length of the meeting was measured in minutes. RESEARCH METHOD The research reported in this paper is a multiple case study [21] in which three teams in one software company were studied over a period of 26 months. The first author took notes either in the meeting or wrote down notes directly after the meeting. On many occasions, also the second author was present to check reliability of the information captured. A. The Company For the purpose of anonymity, we do not reveal details about the company. It was selected because it used agile methods, conducted daily meetings on a regular basis, and allowed researchers (the authors) to observe their way of working. We studied two teams located in Norway (Teams Mars and Saturn) and one team located in Asia (Team Jupiter). All teams had used Scrum with all the recommended practices for more than two years. The sprint length in Saturn and Mars was three weeks; in Jupiter it was two weeks. B. Data Collection Table 2 shows the techniques that we used for data collection. We collected data from multiple sources guided by a protocol developed according to the general recommendations of qualitative research, e.g., [21-24]. C. Interviews The interviewees had a variety of roles, including developers, testers, product owners and project leaders. All the 21 interviews were audiotaped and transcribed. The interviews were conducted by two or three researchers. One of them asked questions; the other one(s) took notes and asked questions at the end. Table 3 shows the number of interviews conducted in each team, and the length of the interviews. The first part of the interviews was semi-structured with a set of planned question about teamwork, including daily meetings. In the last part of the interviews we used the repertory grid Fig. 1. 96 Constructs and issues in the repertory grid E. Data Analysis The repertory grid sessions produced 131 issues. Fig. 1 shows an example of the result of a repertory grid session from one interview. The issues relevant to daily meetings that were identified by this interviewee were: (1) “Daily meetings (interruption of workflow)”, (2) “Conference phone (bad sound quality)”and (3) “You don't “see” your colleague when working distributed.” III. This section discusses the 13 obstacles and their consequences. Table IV gives an overview. A. Temporal 1) Starting promptness We observed that people often arrived late in the daily meetings. For some months, team members in Mars were fined 20 NOK (approximately € 2.50) for arriving more than one minute late. In Saturn, the Scrum Master or a team member often went out to gather missing team members. Such search for people disturbed other people who should not attend the meeting and wasted time to those who arrived on time. Not starting on time leads to people arriving late also the next time [26]. In Jupiter, everyone almost always met on time. We also analyzed all the semi-structured interviews and observation notes from the daily meetings using Nvivo, which is a tool for qualitative analysis (www.qsrinternational.com). We identified 13 obstacles from the interviews, repertory grid sessions and observations. Ten of the obstacles were identified from two or three of the data sources. Thus, data triangulation was achieved for most of the obstacles. 2) Ending promptness Many of the meetings lasted longer than the 15 minutes scheduled time slot. People often lost focus when this happened. For example, we observed that people doodled on their notepad and played with their cell phones. Sometimes the Scrum Master criticized a team member for not paying attention. Another aspect is that it was sometimes unclear when the meeting actually ended. Sometimes one Scrum Master stated that the meeting was “officially over” after each of the team members had given their status. The team members were then allowed to leave but still felt obliged to stay. When more than two thirds of the team members stayed in the meeting, we included this additional time as part of the daily meeting. The obstacles were categorized into the four dimensions temporal, physical, procedural and attendee as defined in [13]. Five obstacles were concerned with meeting characteristics identified in [13]: ending promptness, starting promptness, temperature comfort, space arrangement and number of attendees. Seven obstacles were concerned with six other characteristics: length of meeting, frequency, time of day, equipment, language, information flow and meeting attitudes. We identified consequences of the obstacles on the basis of all the three data sources. TABLE IV. Characteristic of meeting Temporal No OBSTACLES OF DAILY MEETINGS Obstacle 1 Starting promptness Meetings did not start on time. 2 Ending promptness 3 Length of meeting 4 Frequency Meetings did not end on time. The duration of the meetings were perceived to be too long. Team members perceived that the meetings were held too often. The meetings were held at an unsuitable time of the day. 5 Time of the day Physical Temperature 6 comfort 7 8 Equipment Space arrangement 9 Language Procedural 10 Information flow Information distribution Attendee Number of 12 attendees 11 13 Meeting attitudes IDENTIFIED OBSTACLES AND THEIR CONSEQUENCES The temperature in some meetings became too high and the air quality poor. Conference equipment that did not work properly. The Scrum Master was always sitting, while many team members had to stand. Team members had to talk their second language. Perceived consequence Team Time was wasted for those who arrived on time, and search for attendees disturbed other people. After the scheduled time slot, team members lost focus. The longer meetings were considered a waste of time (and money). M, S M, S M, S, J The attitudes towards the meetings became negative. M, S Time was wasted before and after the meetings. M, S Meeting attendees lost focus and became tired. M, S, J Distributed people had trouble hearing what was said in the meeting, and the connection was frequently lost. The meetings lasted longer. The team members who were standing became tired. The quality of the communication was reduced. M, S M, S J Team members often perceived the information given in the meetings as irrelevant and saw the meetings as a waste of time. M, S Unbalance of team member contribution. M, S Too many attendees were present at the meetings. Team members perceived the information as irrelevant. S, J Some team members had negative attitudes towards the meetings. Difficult to observe a direct consequence, but the literature suggest that it effects time spent in meetings, team potency and perceptions of team meeting effectiveness. M, S The focus of meetings tended to be reporting from team members to the Scrum Master instead of sharing information among each other. Team members with certain roles received more attention in the meetings. 97 ventilation, which lead to a lack of fresh air. In Jupiter’s meeting room, the temperature became often too high. The consequence was that the attendees became tired and stopped paying attention in the meeting. 3) Length of meeting TABLE V. Team name Mars Saturn Jupiter Team means All meetings N 24 18 14 19 56 LENGTH OF MEETINGS (MINUTES) Mean 25 20 18 21 22 Median 24 19 15 19 18 Stdev. 10.5 4.8 9.0 8.1 9.0 Max 45 30 40 38 45 Min 10 15 7 11 7 7) Equipment One challenge in the distributed meetings was that the conference phone did not work satisfactory. People on the phone often dropped out, became quiet or unintentionally made noise due to technical problems with the equipment. Time was wasted for all the attendees when reestablishing the lost connection. We defined the start of the meeting as the point of time when the first person arrived the meeting room after scheduled start time. Table V shows that the observed daily meetings lasted between 7 and 45 minutes with a mean of 22 minutes; that is, the cost in time of the meeting was 47% more than planned. Still, it may be the case that the meetings are so useful that longer duration than planned can be justified. However, in our study, many of the interviewees complained that the meetings lasted too long. One team member expressed: “What doesn’t work with the meeting is that it often drifts into a technical discussion, and, consequently, it takes too long.” Furthermore, the people on the phone often had difficulties hearing what was said in the meeting because many team members were standing too far away from the microphone. It was generally easy to hear what the person on the phone said. The poor equipment negatively affected the meeting quality and the team members’ attention in the meeting. One developer said: “If I would point out a challenge of the daily meetings it would be the technical equipment. I think the conference call system we have is the biggest source of frustration.” 8) Space arrangement On average, only half of the members in Mars and Saturn were standing during the meetings. In these teams, the Scrum Master was always sitting, while many team members were standing. One consequence was that the meeting lasted longer since the Scrum Master did not get tired when sitting down. However, we observed that standing during the whole meeting was tiring for the standing team members. They groaned, crouched and looked exhausted, especially in the cases where the meeting lasted 30-40 minutes. One of team member expressed the imbalance: “I think the standup-meetings are not that good because someone is sitting and someone is standing. My opinion is that either should everyone be allowed to sit or everyone should stand. Maybe one solution is to lift the table and use bar chairs. It will be more comfortable than standing, but more effective than sitting down by a lower table.” 4) Frequency The daily meeting was a mandatory practice. Many team members perceived the meeting as an interruption of their workflow and would prefer fewer meetings. One study suggests that people are affected by the number of meetings more than the length of the meetings [27]. What makes meetings interruptions demanding is not simply the change of activity, but also the fact that the thought processes are affected [27]. 5) Time of the Day Some articles report that people often use the daily meeting to start the working day and that team members tend not to work on backlog tasks until the meeting is held [28, 29]. All the teams we studied held their daily meetings in the morning; Mars and Jupiter at 10:00 a.m., Saturn at 10:30 a.m. We observed that team members who arrived at work close to the meeting start time, did not work on job tasks before the daily meeting. In Saturn, many of the team members often went to lunch almost directly after the meeting because they felt that there was too short time between the meeting and lunch to do anything useful. In Jupiter, the participants were always standing. One team member expressed: “There is one thing we have never changed and that is that we really stand up. I think that is good.” 9) Language In Jupiter, the team members had different native languages. Because of company policy, English was used as the formal language. Most of the team members had English as their second language, and, consequently, some of them had difficulties expressing their opinions and taking part in the discussions. Important information was often left out. Generally, the quality of the communication was somewhat reduced. The team members who were confident in their second language were slightly more dominant in the meetings. On the other hand, the difficulty of expressing themselves also resulted in less small talk and thereby more focused and formal meetings than was the case in Mars and Saturn. This might be one reason for why the meetings were shorter in Jupiter than in Mars and Saturn. Due to rush hour, the team members appreciated flexibility regarding work hours. The daily meeting challenged this flexibility. Time difference is an additional challenge when deciding what time of day to conduct the meeting. Saturn and Jupiter worked on the same product, but decided to have separate daily meetings because both teams wanted the meeting to be held in the morning. B. Physical 6) Temperature comfort Physical characteristics such as temperature and noise affect the functioning of a meeting and the attendees’ ability to focus on the meeting tasks without distraction [26, 30]. In Mars and Saturn, the meetings were held in small rooms with insufficient 98 Fig. 2. Conversation map there. They are just doing their own stuff. They have matured and started to understand the essence of Daily Scrum.” C. Procedural 10) Information flow In Saturn, and for some time in Mars, the Scrum Masters were also leaders, both formally and in practice. Consequently, they acted more as leaders than as facilitators in the meetings. It often seemed that the purpose of the meeting was not for the team members to communicate, but to report to the Scrum Master. Quoting one of the Scrum Masters may illustrate this point: “[Name of team member], you can start the meeting so I can see that you have done anything” 11) Information distribution The meetings in Jupiter were more self-organized than the ones in Mars and Saturn. In Jupiter, it was consensus that the order of who was talking started in one corner, continuing clockwise. In Mars and Saturn, the Scrum Master decided in which order the team members were allowed to talk in the meeting. One consequence was that testers, documentation writers and support staff received less attention than others. This resulted in unbalance of team member contribution in the meetings. One team member explained: “The documentation writers are usually last. I think the Scrum Master chooses the person to talk based on the tasks that are important to the Scrum Master. The Scrum Master starts with the people working on that task, usually the developers.” Some members of Mars and Saturn expressed that many daily meetings was a waste of time because they perceived that the information given was not relevant to them. In some daily meetings, we drew a map of the conversation flow. If one person talked to another person, the observer drew a line between those two persons. Fig. 2 shows a conversation map of a self-organizing team and of a team where they reported to the Scrum Master. We often perceived that the atmosphere and communication in the self-organized meetings were better than in the meetings chaired by the Scrum Masters. D. Attendee 12) Number of attendees Table VI shows the number of attendees in the daily meetings that were physically present or attended by phone. In Mars and Saturn, some of the team members often worked from home. In Saturn, one team member was located in another city. In Jupiter, after a while, the daily meetings were more about informing team members about what was relevant for the whole team rather than reporting status to the Scrum Master, which was the case to begin with. One manager explained how they went from reporting to informing each other: “The first day I came into the organization, I was asked, "Can you show us how to do the Daily Scrum the right way?" So they were not sure. So even when you see that they were conducting Daily Scrums it was very robotic. They would do it just because the process says so. They didn’t really understand the essence of why it is important, why you do it. It is very different now. They discuss about problems, they don’t report to the PO they don’t report to the Scrum Master and they don’t care if the managers are The team members perceived the information given in the daily meetings often as irrelevant. We believe that this was partly due to too many people attending the meetings. Some research suggests that five is the optimum group size in meetings and that more than seven persons might lead to complicated group dynamics, unequal participation of attendees and lower commitment to tasks [31]. Furthermore, too many attendees may serve as a detraction, lead to additional inefficiencies, and in general create the feeling that time is not being used effectively [13]. 99 TABLE VI. Team name Mars Saturn Jupiter Mean Physical Phone Total Physical Phone Total Physical Phone Total No. of meetings 24 18 14 NUMBER OF ATTENDEES Mean Median Stdev. Max Min 5.8 1.1 6.9 6.7 1.9 8.6 10.6 0 10.6 6 1 7 6.5 1.5 8.5 12 0 12 1.7 0.9 1.3 1.8 1.5 2.2 2.1 0 2.1 9 3 9 10 4 14 13 0 13 2 0 4 4 0 5 6 0 6 (3) Write a line on the whiteboard when someone arrives late. Three lines by a persons name will have a consequence. Sixth, to avoid late start of meetings with distributed team members, establish the connection before the meeting starts. This was a successful practice in Saturn. Other possible solutions are shown in Fig. 3. One solution to overcome the obstacle that meetings do not end on time is to set a timer to count down the scheduled time. If it is generally perceived that longer meetings are useful, then one should agree on a longer time slot than 15 minutes. Some research indicates that stand-up meetings are faster than meetings where the attendees are sitting without lowering the quality of the produced decisions in the meeting [30]. Our study supports this finding. We observed no difference in the quality of the discussions or decision making with respect to whether people were standing or sitting. We also observed that when one of the developers in Saturn became the Scrum Master, the team became more self-organized, the content of the meetings more relevant and the meetings shorter (on average, from 25 to 19 minutes). Therefore, another means to reduce the duration of the meeting may be to rotate the Scrum Master role. Yet another means is to reduce the number of attendees. We found a medium (non-significant) to large (significant) correlation between number of attendees in the meeting and duration (Mars: ρ = 0.33, p = 0.18; Saturn: ρ = 0.35, p = 0.23; Jupiter: ρ = 0.63, p = 0.03). In Jupiter, if the team members were unable to attend the daily meeting, the Scrum Master communicated their status to the team. Status was sent by e-mail to the Scrum Master in advance. In Mars and Saturn, status was rarely given from absent team members. 13) Meeting attitudes Several team members lost focus in the daily meetings and considered them as a waste of time, which in turn caused a negative attitude towards the meetings. One team member in Mars described the situation as follows: “No one in the team really wants to be at the status meeting. We are mostly programmers and testers, so our job is not administration. Most people think it is a little unnecessary use of time. I think three or even two days a week would be fine.” Developers’ perception of daily meetings as a waste of time with little value was also found in [20]. If team members perceive daily meetings to be held too often, the teams should simply consider whether it is worthwhile to meet every day. To suggest having meetings more seldom, for example, three times a week, is a drastic solution because we are questioning the whole concept of daily meetings. It was difficult to observe a direct consequence of this obstacle, but another study found that team meeting attitudes had direct effects on time spent in team meetings, perceptions of team meeting effectiveness and team potency [12]. A negative attitude may also affect general job satisfaction [32, 33]. Overhead time is consumed before and after meetings. Therefore, one should consider carefully what time of the day one should conduct daily meetings to reduce this overhead. We believe that the teams that we studied would benefit from following the agile recommendation of scheduling the daily meetings in the morning. The Scrum Masters in Mars and Saturn were the interviewees who were most positive towards the daily meetings. This is consistent with another study that found that individuals who considered themselves as meeting facilitators reported a significantly greater perceived meeting quality than those who did not [13]. IV. Daily meetings are often held in rooms that are easily accessible and need no booking. However, if the rooms are poor with respect to temperature and air quality, it may be valuable to hold the meetings in a larger room even if this would require some extra overhead. For the many IT companies that have open-plan offices, a straightforward solution is to hold the meetings there if one does not disturb other people. ALLEVIATING THE OBSTACLES In this section, we propose solutions to the thirteen identified obstacles; see also Fig. 3. Several solutions may alleviate the challenge that the meetings do not start on time. First, use an alarm to signal meeting start time. Second, start the meeting regardless of who has arrived. Even if not everybody is present, it is important to consistently start on time to encourage future punctuality [26]. Third, schedule the daily meetings at an odd time. For example, deciding that the meeting starts at 9:07 a.m. emphasizes the importance of being on time. Fourth hold the meetings in the open-plan office space, because it will then be visible to the team members that the meeting is about to start. Fifth, make lateness visible, for example: (1) Give a fine for coming late, as they did for some time in Mars. (2) Place a glass for each person labeled with their names The ones who arrive on time place a green marble in their glass, the ones arriving after meeting start time has to place a red marble in the glass. Daily meetings in teams with not every team member physically present require video or audio conference equipment of satisfactory quality. High quality conference equipment may be expensive, but we observed that Skype worked well. One may also consider whether it is strictly necessary that the distributed team members attend the meeting. People generally find it more comfortable to sit than stand. Holding the meeting in a room or part of a room without chairs will make people stand, also the Scrum Master. 100 To reduce the tendency of reporting to the Scrum Master instead of sharing relevant information among all the team members, one should consider rotating the Scrum Master role. In Jupiter, they voted for the Scrum Master every tenth week among the ones that had not had the role yet. Many interviewees mentioned this practice as positive for the team, because, being a Scrum Master made them more responsible for the whole team and familiar with the project processes: “Being a Scrum Master helps you see the big picture.” Some team members consider their Scrum Master as a traditional manager to whom they need to report status. If the Scrum Master does not make eye contact with the person talking, this person will probably find someone else on the team to make eye contact with, thus reducing the tendency to report to the Scrum Master. When the Scrum Master decides the order of people speaking, this reinforces the tendency of reporting. To help reduce the manager role of the Scrum Master, the order of people speaking may be decided by the team members themselves, for example, by passing a token (e.g. a soft ball) to the next person to speak. If the passing is performed in a randomized order, people may become more alert because they do not know who will be next. Both rotating the role of Scrum Master and passing a token to decide the speaking order may help alleviate the obstacle that some team members receive more attention in the meetings than others. To tackle the challenge that there are too many people in the meetings, using visual aids, such as physical board and backlog on a screen, may help increasing the attention of the attendees. Of course, one may also consider reducing the number of attendees by not including team members to whom the topic of the meeting is irrelevant. In large teams, one may divide the team and have separate meetings that discuss tasks that are relevant to the team members. Fig. 3. To alleviate the challenge of a negative attitude towards daily meetings, one may reduce the frequency of meetings if they are considered a waste of time. Rotating the role of Scrum Master may involve more team members in the project processes. People who find the information discussed in the meetings irrelevant may be allowed to not attend some of the meetings. Finally, teams should agree on a purpose for the meeting because it positively affects the meeting [8]. In general, conducting more effective meetings will positively affect the attitude towards the meetings. Suggested solutions to obstacles The problem that some people may have to talk a foreign language may be alleviated by using a physical board in the meeting or showing tasks from the backlog on a screen. The information given may become more understandable and relevant. The team members in Jupiter appreciated that tasks were made visible on the screen: “It requires some skills to carry out a good standup meeting. We have changed over time; we have used our retrospective meetings to improve the daily meetings. The content of what you say in the meeting is very important. We don’t want to know the details of what you did yesterday, but something that is useful for the whole team. We had to change the mindset and find out what to say in the meeting. We practiced a lot and improved. In the beginning we had a feeling that everyone just came in and talked and then everyone left and we didn’t see how that was related to the project. Now we bring up the backlog every day to actually relate it to each thing we talk about.” V. POTENTIAL LIMITATIONS We studied only three teams in one company. Other companies and teams may encounter other obstacles to the organization of efficient daily meetings; that is, we do not claim our findings to be representative. Furthermore, the teams that we studied had used daily meetings for more than two years. Beginners may encounter more and other obstacles. The presence of researchers in the meetings may be intrusive, causing unnatural behaviour of the meeting attendees. This effect was only noticeable in the first meetings in each team. Since we observed fourteen or more meetings in each team, we consider this effect to be minimal in our study. 101 When using observations and interviews as data collection techniques, there is a risk of researcher bias. To reduce the effect of such a bias we were several researchers during the observations and interviews. VI. [11] B. Jensen and A. Zilmer, "Cross-Continent Development Using Scrum and XP," Extreme Programming and Agile Processes in Software Engineering, Springer Berlin Heidelberg, pp. 146-153, 2003. [12] T. A. O´Neill and N. J. Allen, "Team Meeting Attitudes: Conceptualization and Investigation of a New Construct," Small Group Research, vol. 43, no. 2, pp. 186-210, 2012. [13] M. A. Cohen, S. G. Rogelberg, J. A. Allen, and A. Luong, "Meeting Design Characteristics and Attendee Perceptions of Staff/Team Meeting Quality," Group Dynamics: Theory, Research, and Practice, vol. 15, no. 1, pp. 90-104, 2011. [14] P. Middleton and D. Joyce, "Lean Software Management: BBC Worldwide Case Study," IEEE Transactions on Engineering Management, vol. 59, no.1, pp. 20-32, Feb. 2012. [15] L. Pries-Heje and J. Pries-Heje, "Why Scrum works: A case study from an agile distributed project in Denmark and India," Agile Conference (AGILE´2011), IEEE, 2011. [16] O. McHugh, K. Conboy, and M. Lang, "Using Agile Practices to Build Trust in an Agile Team: A Case Study," in Information Systems Development, Springer, pp. 503-516, 2011. [17] V. G. Stray, N. B. Moe, and T. Dybå, "Escalation of Commitment: A Longitudinal Case Study of Daily Meetings," in Agile Processes in Software Engineering and Extreme Programming, Springer Berlin Heidelberg, pp. 153-167, 2012. [18] V. G. Stray, N. B. Moe, and A. Aurum, "Investigating Daily Team Meetings in Agile Software Projects," 38th EUROMICRO Conference on Software Engineering and Advanced Applications, pp. 274-281, 2012. [19] K. Schwaber and M. Beedle, Agile software development with Scrum, Prentice Hall, 2002. [20] N. Nikitina and M. Kajko-Mattsson, "Historical Perspective of Two Process Transitions," Fourth International Conference on Software Engineering Advances, IEEE, pp. 289-298, 2009. [21] R. K. Yin, Case Study Research: Design and Methods, SAGE Publications, 2009. [22] M. B. Miles and A. M. Huberman, Qualitative Data Analysis: an Expanded Sourcebook, SAGE Publications, 1994. [23] P. Runeson and M. Höst, "Guidelines for conducting and reporting case study research in software engineering," Empirical Software Engineering, vol. 14, no. 2, pp. 131-164, 2009. [24] A. Strauss and J. M. Corbin, Basics of Qualitative Research: Grounded Theory Procedures and Techniques: SAGE Publications, 1990. [25] F. Fransella, D. Bannister, and R. Bell, A Manual for Repertory Grid Technique, Wiley, 2004. [26] D. J. Leach, S. G. Rogelberg, P. B. Warr, and J. L. Burnfield, "Perceived Meeting Effectiveness: The Role of Design Characteristics," Journal of Business and Psychology, vol. 24, no. 1, pp. 65-76, 2009. [27] S. G. Rogelberg, D. J. Leach, P. B. Warr, and J. L. Burnfield, ""Not Another Meeting!" Are Meeting Time Demands Related to Employee Well-Being?," J. of Applied Psychology, vol. 91, no. 1, pp. 86-96, 2006. [28] H. Robinson and H. Sharp, "XP Culture: Why the twelve practices both are and are not the most significant thing," in Proceedings of the Agile Development Conference (ADC´2003), IEEE, pp. 12-21, 2003. [29] J. Yip, "It's Not Just Standing Up: Patterns for Daily Stand-up Meetings", http://martinfowler.com/articles/itsNotJustStandingUp.html, Aug. 2011. [30] A. C. Bluedorn, D. B. Turban, and M. S. Love, "The Effects of Stand-Up and Sit-Down Meeting Formats on Meeting Outcomes," Journal of Applied Psychology, vol. 84, no. 2, pp. 277-285, 1999. [31] N. C. Romano Jr and J. F. Nunamaker Jr, "Meeting Analysis: Findings from Research and Practice," Proceedings of the 34th Hawaii International Conference on System Sciences, IEEE, 2001. [32] S. G. Rogelberg, J. A. Allen, L. Shanock, C. Scott, and M. Shuffler, "Employee Satisfaction with Meetings: A Contemporary Facet of Job Satisfaction," Hum. Resour. Man., vol. 49, no. 2, pp. 149-172, 2010. [33] S. G. Rogelberg, C. Scott, and J. Kello, "The Science and Fiction of Meetings," MIT Sloan Man. Review, vol. 48, no. 2, pp. 18-21, 2007. CONCLUSION There is little evidence in the agile literature on how to conduct daily meetings in an effective way. The results of this case study indicate that there are several challenges when conducting daily meetings in software projects. We identified thirteen obstacles for effective meetings. Suggestions for overcoming these obstacles were given based on analyses of observation notes, interview transcripts and repertory grids. The identified obstacles should be evaluated by practitioners conducting daily meetings to identify which of the obstacles may be present in their organization. Subsequently, our suggested solutions to these obstacles should be considered to improve the efficiency of the meetings. Some of our obstacles and solutions may seem trivial. However, if people are not regularly evaluating their processes, even simple improvements are not performed. We hope that our paper will help the software industry become more conscious about the way daily meetings are held. ACKNOWLEDGMENTS This work was supported by the Research Council of Norway through grant no. 193236/I40. REFERENCES [1] M. Pikkarainen, J. Haikara, O. Salo, P. Abrahamsson, and J. Still, "The impact of agile practices on communication in software development," Empirical Software Engineering, vol. 13, pp. 303-337, 2008. [2] F. P. Brooks, "No silver bullet: Essence and Accidents of Software Engineering," IEEE computer, vol. 20, pp. 10-19, 1987. [3] S. D. Teasley, L. A. Covi, M. S. Krishnan, and J. S. Olson, "Rapid Software Development through Team Collocation," IEEE Transactions on Software Engineering, vol. 28, no. 7. pp. 671-683, July 2002. [4] D. E. Strode, S. L. Huff, B. Hope, and S. Link, "Coordination in colocated agile software development projects," Journal of Systems and Software, vol. 85, no. 6, pp. 1222-1238, 2012. [5] K. Henttonen and K. Blomqvist, "Managing distance in a global virtual team: the evolution of trust through technology-mediated relational communication," Strategic Change, vol. 14, pp. 107-119, 2005. [6] C. Poile, A. Begel, N. Nagappan, and L. Layman, "Coordination in Large-Scale Software Development: Helpful and Unhelpful Behaviors," Technical Report MSR-TR-2009-135, Microsoft Research, Sept. 2009. [7] S. G. Rogelberg, L. R. Shanock, and C. W. Scott, "Wasted Time and Money in Meetings," Small Group Research, vol. 43, no. 2, pp. 236-245, 2012. [8] H. Bang, S. L. Fuglesang, M. R. Ovesen, and D. E. Eilertsen, "Effectiveness in top management group meetings: The role of goal clarity, focused communication, and learning behavior," Scandinavian Journal of Psychology, vol. 51, pp. 253-261, 2010. [9] J. A. Allen, S. J. Sands, S. L. Mueller, K. A. Frear, M. Mudd, and S. G. Rogelberg, "Employees´ feelings about more meetings: An overt analysis and recommendations for improving meetings," Management Research Review, vol. 35, no. 5, pp. 405-418, 2012. [10] M. Hoegl and H. Gemuenden, "Teamwork Quality and the Success of Innovative Orojects: A theoretical Concept and Empirical Evidence," Organization Science, vol. 12, no. 4, pp. 435-449, 2001. 102