Keywords

1 Introduction

Agile methods introduced the daily stand-up meeting (DSM) as a practice to improve communication in software development projects. In Scrum, the meeting is mandatory, time-boxed to 15 min and team members address: (1) what they have done the previous work day, (2) what they will do today and (3) what obstacles are preventing them from making progress [1]. Scrum recommends that the DSM should not be used for discussing solutions to obstacles raised. However, empirical studies have found that spending time in the short meeting on discussing and solving problems is valuable [2, 3].

DSMs are task oriented, generally unrecorded, and members gather to focus on a narrow organizational goal. According to Boden [4], such meetings can be characterized as informal. The practice gives team members an overview of what other team members are doing and is therefore an important mechanism to increase information sharing and team awareness [5]. The meeting is often conducted standing up to keep it brief and avoid lengthy discussions, hence the term “stand-up meeting”. The practice is also called “frequent short meetings” [6], “morning roll call” [7], and “daily Scrum meeting” [1]. The DSM is an important practice for agile teams because it helps the team in monitoring and managing its performance, which is important for the team to self-manage [8]. Further, such meetings improve access to information that foster employee empowerment [9].

While DSM is a relatively straightforward practice to adopt, it is challenging to implement it successfully. Challenges include finding a suitable time of day, keeping the time limit and whether it should be held daily and standing up [10]. We have previously found DSMs to last 63% longer when team members sit rather than stand during the meeting [5]. Another challenge is members reporting their status to the team leader, resulting in team members not paying attention to each other [8].

Although the DSM is one of the most popular agile practices [11, 12] and the only daily team-based coordination mechanism, the practice has received little research attention. Further, because meeting satisfaction is part of overall job satisfaction [13], it is important to understand what makes this meeting valuable for team members. In a recent, qualitative study of thirteen teams (in Norway, Poland, UK and Malaysia) we found that the attitudes towards DSMs were slightly more positive than negative [5]. However, the level of satisfaction varied within the teams. Therefore, to understand how to implement DSM, it is important to explore satisfaction with the practice on an individual level. This leads to the following research question: “What are the characteristics of developers perceiving the daily stand-up meeting to be valuable compared to those who do not?”

Our work also answers a call for more empirical studies on the adoption rate of agile software development methods [14].

2 Method

The target population for this study was professional software developers. Accordingly, we posted the survey on Reddit, which is a social media website that allows scientists to recruit a targeted population [15]. We chose two programming-related subreddits (subforums) that provide news and discussions about computer programming (r/programming, 710 000 subscribers) and web development (r/webdev, 130 000 subscribers). The survey was administered using the Qualtrics software which prevents the survey to be completed more than once by the same respondent. Participation was voluntary. Further, no compensation was offered, which increase the quality of the data because the incentive to cheat is largely reduced [15]. The survey (available from https://figshare.com/s/a10006dd8f5f26141511) took about three minutes to complete.

We received 316 responses, of which 243 contained data that could be analyzed. Because we were interested in the opinions of software professionals currently working in teams, we removed students and those not working or not working in a team. In total, 221 responses were used for the reported results. The majority of responses were from the programming forum (n = 165). Nearly all the respondents were male (96.8%) with a mean age of 31 years (n = 204, sd = 6.86). Among the respondents who answered whether their team was distributed (n = 168), about two-thirds of the respondents (63.1%) reported working in co-located teams, whereas the remaining had team members distributed across sites (36.9%).

All Likert questions used a five-point scale. All nominal-scale questions were presented with a randomized order of categories because the order of response alternatives can influence results [16]. Some questions were not compulsory, which resulted in missing data for the reported variables. Analyses are reported using the R statistical software [17]. To err on the side of caution, we use two-tailed analysis and chose non-parametric statistical tests. The one-sample Wilcoxon test is used to check for statistically significant differences in distributions. When comparing frequencies between two dichotomous variables that contain count data (i.e., frequencies) we used Fisher’s exact test which reports the odds ratio (OR) effect size.

3 Results

In our study, the average number of DSMs conducted per week was five, which suggests that it is a daily meeting. Table 1 shows descriptive statistics. We found no difference regarding the frequency of meetings when it comes to being part of a distributed team or not, or to team size. Among all the respondents, one-third reported to work in teams with two to five members, one-third in teams with six to eight members and one-third in teams with nine or more members. We found a difference of 52% points with an odds ratio of 12.3 for agile teams using DSMs over non-agile teams (p < 0.001, 95% confidence interval for OR: 5.4–29.5).

Table 1. Descriptive statistics
Full size table

Overall, 70.6% report that they attend DSMs (n = 221). Those who attend and those who do not attend DSMs spend the same amount of hours in meetings (DSMs included) and report similar values for programming skills. However, those who attend DSMs spend almost one hour more each workday on programming (p = 0.046, attend: M = 6.5 h, sd = 2.1; not attend: M = 5.6 h, sd = 2.7). Further, those who attend DSMs work in larger teams (p = 0.03, attend: M = 6.90 members, sd = 4.7; M = 7.44 members, sd = 3.52); the median difference was 2 team members. Moreover, the practice is regarded as more valuable by those who attend DSMs than those who do not (p = 0.002, attend: M = 3.1, n = 123, not attend: M = 2.3, n = 29).

We now report on only those respondents who attend DSMs. While the mean perceived value by these respondents towards the practice was neutral (3.1), only 18.7% chose this middle category on the Likert scale. Most respondents were either positive (44.7%) or negative (36.6%). We coded responses of 4 and 5 as “positive”, responses of 1 and 2 as “negative”, and removed those who responded neutral to be able to better understand differences between these two groups. We found no relation between working in a co-located or distributed team and the perceived value of DSM. However, those positive were significantly younger (p = 0.008, positive: M = 29.6 years, n = 49; negative: M = 33.5 years, n = 42).

Figure 1 shows the characteristics of the respondents who attend DSMs according to whether they are positive (green, n = 55) or negative (red, n = 45) towards the meetings they attend. The left part of the figure shows that those positive and negative towards their DSMs spent about the same amount of time in meetings: 83 min for those positive versus 77 min for those negative. However, there was a significant difference in meeting frequency; those positive attended fewer meetings per day (DSMs included) than those negative. Those positive towards DSM report somewhat more time spent on programming per day (24 min) than those negative. Being positive towards DSMs was, to some extent, associated with working in smaller teams. As a post hoc analysis, we investigated differences in attitudes further and found that teams with 12 or more members were most strongly associated with negative attitudes towards DSMs.

Fig. 1.
figure 1

Characteristics of those positive and negative towards their DSMs being valuable. Significant differences are shown at the top and means are shown at the bottom of the figure (as numbers). Outliers are omitted. Error bars represent the standard errors of the mean. + is p < 0.10 and * is p < 0.05 (two-sided). (Color figure online)

Full size image

The right part of Fig. 1 shows a minor difference between how those positive and negative towards DSM rated their own programming skills. However, those positive rated the programming skills of their peers as significantly higher compared to how the negative rated their peers. Further, those negative also rated their own skills as significantly higher than that of their peers, whereas it was, to some extent, the opposite for those positive.

4 Discussion

The main explanation of the widespread use of DSM (70,6%) is the high adoption rate of agile development methods among our respondents. Table 2 shows that the agile adoption rate in our survey is higher than what was found by Rodríguez et al. [11]. Rodríguez et al. did not report the adoption rate of DSM but concluded that it was one of the most widely used practices. The last column in Table 2 shows the adoption rate of DSM in both agile and non-agile teams in our study. VersionOne [12] report the DSM to be the most employed agile practice with an adoption rate of 83%. VersionOne’s sample mostly consisted of agile practitioners. In comparison, our DSM adoption rate among those using agile or agile in combination with Lean was 87.3%. Our results indicate that the practice has spread to companies not using agile methods because 35.4% of the respondents who work in non-agile teams also report using DSM. Thus, being agile implies that DSMs are used to a large extent which supports that DSM is a practice that distinguishes agile from non-agile teams [17].

Table 2. Usage rates of agile methods and DSM adoption according to development method
Full size table

For our research question, “What are the characteristics of developers perceiving the daily stand-up meeting to be valuable compared to those who do not?”, our results indicate that those positive towards DSM are more junior developers. This inference is supported by age, how they rate their own programming skills and their self-reported skills compared to the perceived skill of their peers. Those positive towards DSM also participate in fewer meetings than those negative. The same variables also indicate that those negative towards DSM are more senior developers. One explanation for why a senior developer regards DSM as less valuable is because seniors may already know what goes on in the team and does not get any new information in the meeting. The personal gain from the meeting is thus reduced. Moreover, being able to have quick problem-solving discussions in the DSM make developers perceive the DSM as more valuable [5]. Senior developers often work on more complex tasks, and it might be that high complexity problems are seldom discussed at the meeting because they require too much time. It is more likely that the problems a junior developer encounter are more easily solved in a DSM.

A second explanation is that senior developers attend more meetings than junior developers. The DSM then becomes an additional daily interruption, which reduces the satisfaction with such meetings. Perceiving the meeting to have too high frequency negatively affects the attitude towards DSMs [5]. Moreover, meeting load affects employees well-being [18] so companies should be sensitive to the number of meetings the developers have to attend. While it has been claimed that DSMs eliminate the need for other meetings [1], we found no difference between hours spent in meetings for those who attend or do not attend DSMs.

In a self-managing team, the team goal should be more important than the individual goal, and then a developer should rate the DSM value depending on the team needs. One respondent commented: “I think some people need the daily stand-up format. So even though I personally don’t feel like I need it, I feel it benefits us all to do it because of the different personalities.” Because we do not know the perspective of the respondent we do not know if the respondents are considering the value from an individual or team perspective, or a mixture of the two views.

We found that larger teams are more likely to have DSMs. Paradoxically, the larger the team, the less is the satisfaction with DSM. Large teams using DSMs should therefore pay special attention to improving the quality of these meetings. In particular, developers were negative towards DSM when teams consisted of 12 or more team members. Previous research also found a negative correlation between the number of meeting participants and the attitude towards DSM [5].

The main limitation of this study concerns the representativeness. Although the distribution of self-reported programming skill in this study is nearly identical to our earlier study of programming skill of developers [19], the sample and target population may differ. For example, it is possible that only those who knew or had a strong (polarized) opinion of DSMs responded to the survey. This may bias results in favor of more respondents reporting using DSM and more variability in opinions than is actually present in the target population. Another potential concern is that we had subjects from two different programming forums, but the results we report still hold when analyzing the data from the two forums separately.

5 Conclusion and Future Work

The present study investigated the perceived value of daily stand-up meetings (DSMs) and reports the adoption rate of the practice. Among those who use agile methods, the majority conducts DSMs. Although it is a common practice, the perceived value of the meeting varies with junior developers being more positive and senior developers more negative towards the DSMs they attend. A possible explanation is that junior developers receive more relevant information and assistance in solving problems during the meeting. In contrast, senior developers often work with larger, more complex and independent tasks that are more difficult to share with team members on a daily basis. Agile teams are expected to be self-managed, and the need of the team should be more important than that of the individual. The value of the practice should, therefore, be evaluated according to the team needs. Consequently, senior developers should be made more aware that DSMs are beneficial for the junior developers as well as the team as a whole. Another result was that developers in larger teams see the meeting as less valuable than developers in smaller teams. Because the work in large teams is often loosely coupled, the information shared during the meeting may be less relevant for the individuals. Consequently, large teams in particular need to invest resources in improving the practice to make it valuable.

Future work should investigate other criteria of the participants, such as role and domain. Because the perceived value of meetings affects job satisfaction, there is a need to understand why senior developers and large teams do not perceive the meeting as more valuable. The DSM is a widely adopted practice and is an important mechanism for information sharing and team awareness, thus, how to apply the practice successfully in large teams should also be studied.