ThesisPDF Available

An Empirical Investigation of the Daily Stand-Up Meeting in Agile Software Development Projects

Authors:

Abstract and Figures

Agile methods have in recent years become common in software development projects. The daily stand-up meeting (DSM) is the most used agile practice, but the practice has garnered scant research attention. On the basis of four case studies and one grounded theory study, this thesis explores how the DSM is used and perceived by members of agile software teams. Most views and claims on the DSM are based on only anecdotal evidence; this thesis is the first thorough empirical investigation. DSMs were studied in four companies located in Malaysia, Norway, Poland and the United Kingdom. Qualitative data from 81 interviews and participant observations of 83 DSMs constitute the main data sources. The DSM is often considered as a fairly simple practice to successfully implement. Unfortunately, this is not the case. This thesis identifies both positive and negative aspects of DSM. The most prominent positive aspects are that team members obtain an overview of what others in their team are doing and all team members get an opportunity to discuss and solve problems. The most prominent negative aspects are that team members may report status progress that is not relevant for the whole team, the meeting requires too much time and it interrupts the workflow. Considering the popularity of the DSM, it is surprising that the interviewed DSM participants, on average, have an almost neutral attitude towards the meeting, slightly more positive than negative. Relatively few grounded theory studies have been conducted in the field of software engineering. This thesis thoroughly describes how such a study may be undertaken in the context of agile methods. A theory of the DSM is proposed, consisting of seven constructs and six propositions. In order to overcome the negative aspects identified, a modified set of guidelines on how to conduct the DSM is proposed to support software companies in realizing its potential benefits.
Content may be subject to copyright.
An Empirical Investigation of the Daily Stand-Up
Meeting in Agile Software Development Projects
Viktoria Stray
Thesis submitted for the degree of Philosophiae Doctor
Department of Informatics
Faculty of Mathematics and Natural Sciences
University of Oslo
August 2014
© Viktoria Stray, 2014
Series of dissertations submitted to the
Faculty of Mathematics and Natural Sciences, University of Oslo
No. 1550
ISSN 1501-7710
All rights reserved. No part of this publication may be
reproduced or transmitted, in any form or by any means, without permission.
Cover: Hanne Baadsgaard Utigard.
Printed in Norway: AIT Oslo AS.
Produced in co-operation with Akademika Publishing.
The thesis is produced by Akademika Publishing merely in connection with the
thesis defence. Kindly direct all inquiries regarding the thesis to the copyright
holder or the unit which grants the doctorate.
iii
Abstract
Agile methods have in recent years become common in software development
projects. The daily stand-up meeting (DSM) is the most used agile practice, but the
practice has garnered scant research attention. On the basis of four case studies and
one grounded theory study, this thesis explores how the DSM is used and perceived
by members of agile software teams.
Most views and claims on the DSM are based on only anecdotal evidence; this
thesis is the first thorough empirical investigation. DSMs were studied in four
companies located in Malaysia, Norway, Poland and the United Kingdom.
Qualitative data from 81 interviews and participant observations of 83 DSMs
constitute the main data sources.
The DSM is often considered as a fairly simple practice to successfully
implement. Unfortunately, this is not the case. This thesis identifies both positive
and negative aspects of DSM. The most prominent positive aspects are that team
members obtain an overview of what others in their team are doing and all team
members get an opportunity to discuss and solve problems. The most prominent
negative aspects are that team members may report status progress that is not
relevant for the whole team, the meeting requires too much time and it interrupts the
workflow. Considering the popularity of the DSM, it is surprising that the
interviewed DSM participants, on average, have an almost neutral attitude towards
the meeting, slightly more positive than negative.
Relatively few grounded theory studies have been conducted in the field of
software engineering. This thesis thoroughly describes how such a study may be
undertaken in the context of agile methods. A theory of the DSM is proposed,
consisting of seven constructs and six propositions. In order to overcome the
negative aspects identified, a modified set of guidelines on how to conduct the DSM
is proposed to support software companies in realizing its potential benefits.
v
Acknowledgments
I am indebted to many people for the research included in this thesis. First and
foremost, I extend enormous gratitude towards my principal supervisor Professor
Dag Sjøberg for giving me wholehearted guidance, encouragement and support and
significantly impacting my development as a researcher. I also extend sincere
gratitude towards my second supervisor Chief Scientist Tore Dybå for providing me
with invaluable support and academic guidance.
I am forever thankful to Nils Brede Moe who has been a constant source of
encouragement and enlightenment. Our collaboration has been extremely valuable
and inspiring. I am deeply grateful to Yngve Lindsjørn who has provided me with
continuous support and positivity. I also owe considerable thanks to Torgeir
Dingsøyr for our collaboration.
I greatly appreciate the courtesy shown by Professor Aybüke Aurum at
University of New South Wales, by giving me the opportunity to experience an
inspirational six months of collaboration and providing me with warm and helpful
support throughout my stay in Australia.
I also thank Øystein Ingebrigtsen and my colleagues at PSE. My fellow students
Gunnar Bergersen, Henning Berg and Kjetil Kjernsmo deserve special thanks for
making my time as a PhD candidate both fun and interesting.
I am overwhelmingly grateful to all of the participants of the studies, who so
generously welcomed me into their organizations and patiently gave me their time to
share their experiences and insights. I am also thankful to the Research Council of
Norway for funding my PhD position.
Finally, I am grateful to my family and friends for their wonderful support and
encouragement. Especially, I thank my husband Petter for his love and friendship
and for inspiring me with never-ending calmness and a positive attitude. The last
words are for Isabelle, my beautiful little daughter who always makes me smile.
vii
List of Papers
The following papers are included in this thesis:
1. Challenges to Teamwork: A Multiple Case Study of Two Agile Teams
Viktoria Gulliksen Stray, Nils Brede Moe and Torgeir Dingsøyr
In Proceedings of the 12th International Conference on Agile Processes in
Software Engineering and Extreme Programming, Springer Berlin
Heidelberg, pp. 146–161, 2011
2. Escalation of Commitment: A Longitudinal Case Study of Daily
Meetings
Viktoria Gulliksen Stray, Nils Brede Moe and Tore Dybå
In Proceedings of the 13th International Conference on Agile Processes in
Software Engineering and Extreme Programming, Springer Berlin
Heidelberg, pp. 153–167, 2012
3. Investigating Daily Team Meetings in Agile Software Projects
Viktoria Gulliksen Stray, Nils Brede Moe and Aybüke Aurum
In Proceedings of the 38th Euromicro Conference on Software Engineering
and Advanced Applications, pp. 274–281, 2012
4. Obstacles to Efficient Daily Meetings in Agile Development Projects: A
Case Study
Viktoria Gulliksen Stray, Yngve Lindsjørn and Dag I. K. Sjøberg
In Proceedings of the 2013 ACM/IEEE International Symposium on
Empirical Software Engineering and Measurement (ESEM), pp. 95–102,
2013
5. The Daily Stand-Up Meeting: A Grounded Theory Study
Viktoria Stray, Dag I. K. Sjøberg and Tore Dybå
Submitted to The Journal of Systems and Software, 2014
My contributions
As first author, I took the overall responsibility for all five papers. Paper 1 was a
collaborative effort, including joint data analysis and writing, with Nils Brede Moe
and Torgeir Dingsøyr. I collected the data in one of the investigated companies; Moe
and Dingsøyr collected the data in the other company. Paper 2 was a collaborative
effort with Nils Brede Moe and Tore Dybå. Moe and I collected data in 2011, while
Moe and Dybå provided additional data from 2008. Moe and I analyzed the data
while we were staying in Australia. Tore Dybå contributed to the writing process.
viii
Paper 3 was a collaborative effort with Nils Brede Moe and Aybüke Aurum. I
collected the data in one of the investigated companies; Moe collected the data in the
other company. During the analysis we had frequent discussions with Aybüke
Aurum who also contributed to the writing process. We received comments from my
supervisor Dag Sjøberg. Paper 4 was a collaborative effort with Yngve Lindsjørn
and Dag Sjøberg. I collected the data with Lindsjørn and Øystein Ingebrigtsen
(master student). The co-authors contributed to the analysis and writing process.
Paper 5 was a collaborative effort with Dag Sjøberg and Tore Dybå. I collected the
data with Lindsjørn, Ingebrigtsen and Moe. I performed the analysis of the paper
over several years throughout the study while having frequent discussions with
Sjøberg and Dybå who also contributed to the writing process.
ix
Contents
Summary ................................................................................................................................ 1
1Introduction ....................................................................................................................... 1
1.1Research Problem and Questions .............................................................................. 2
1.2Research Setting ........................................................................................................ 2
1.3Contributions ............................................................................................................. 3
1.4Thesis Structure ......................................................................................................... 3
2Background ....................................................................................................................... 6
2.1Meetings .................................................................................................................... 6
2.2Agile Software Development .................................................................................... 7
2.3DSM in Agile Teams ................................................................................................. 8
2.4Daily Meetings in other Disciplines ........................................................................ 10
3Research Methods ........................................................................................................... 11
3.1Research Context ..................................................................................................... 11
3.2Research Perspective ............................................................................................... 12
3.3Research Approach .................................................................................................. 12
3.4Case Studies ............................................................................................................ 15
3.5Grounded Theory .................................................................................................... 16
3.6Role of the Researcher ............................................................................................. 17
3.7Data Collection ........................................................................................................ 18
3.8Data Analysis .......................................................................................................... 19
3.9Use of Theories ....................................................................................................... 20
4Results ............................................................................................................................. 22
4.1RQ1: What are the Characteristics of DSMs? ......................................................... 22
4.2RQ2: What are the Key Positive and Negative Aspects of Using DSMs? .............. 26
4.2.1Team Characteristics ........................................................................................ 28
4.2.2Physical Characteristics ................................................................................... 28
4.2.3Team Information Sharing ............................................................................... 29
4.2.4Discussing and Solving Problems .................................................................... 29
4.2.5Reporting Progress ........................................................................................... 29
4.2.6Temporal Characteristics ................................................................................. 30
5Discussion ....................................................................................................................... 30
5.1The DSM in Agile Projects ..................................................................................... 30
5.2Implications for Research ........................................................................................ 31
5.2.1Evaluating the Grounded Theory ..................................................................... 32
5.3Implications for Practice .......................................................................................... 33
5.4Normative Definition Based on the Empirical Findings ......................................... 36
5.5Limitations ............................................................................................................... 37
6Concluding Remarks ....................................................................................................... 37
References ............................................................................................................................. 38
Paper 1: Challenges to Teamwork: A Multiple Case Study of Two Agile Teams ........ 45
1Introduction ..................................................................................................................... 46
2Teamwork ....................................................................................................................... 47
2.1Team Orientation ..................................................................................................... 47
x
2.2Team Learning ......................................................................................................... 48
2.3Team Processes ........................................................................................................ 48
3Research Design and Method ......................................................................................... 48
4Case analysis ................................................................................................................... 50
4.1North Project ............................................................................................................ 50
4.1.1Team orientation .............................................................................................. 50
4.1.2Team learning ................................................................................................... 52
4.2South Project ............................................................................................................ 53
4.2.1Team orientation .............................................................................................. 53
4.2.2Team learning ................................................................................................... 54
5Discussion ....................................................................................................................... 56
5.1Three Problems ........................................................................................................ 57
5.2Suggestions for Practice .......................................................................................... 58
6Conclusion ...................................................................................................................... 59
References ............................................................................................................................. 60
Paper 2: Escalation of Commitment: A Longitudinal Case Study of Daily Meetings .. 63
1Introduction ..................................................................................................................... 64
2Background ..................................................................................................................... 65
2.1Decision Making in Agile Software Development .................................................. 65
2.2Escalating Commitment .......................................................................................... 66
3Research Method ............................................................................................................. 67
3.1Case Study Design ................................................................................................... 67
3.2Study Context .......................................................................................................... 68
3.3Data Collection and Analysis .................................................................................. 68
4Results ............................................................................................................................. 69
4.1The Team Justifying Their Decisions to the Product Owner. ................................. 69
4.2Team Members Justifying Their Decisions to Each Other ...................................... 71
5Discussion ....................................................................................................................... 73
5.1Psychological Self-justification ............................................................................... 74
5.2Social Self-justification ........................................................................................... 75
5.3Implications for Practice .......................................................................................... 76
6Conclusions and Further Work ....................................................................................... 76
References ............................................................................................................................. 77
Paper 3: Investigating Daily Team Meetings in Agile Software Projects ...................... 79
1Introduction ..................................................................................................................... 80
2Background ..................................................................................................................... 80
2.1Meetings .................................................................................................................. 81
2.2Daily Meetings in Agile Software Projects ............................................................. 81
3Research Design and Methodology ................................................................................ 82
3.1Study Context .......................................................................................................... 82
3.2Study Design, Data Sources, and Analysis .............................................................. 83
4Results ............................................................................................................................. 85
4.1Meeting Characteristics ........................................................................................... 85
4.2Percentage of Words Devoted to Each Category .................................................... 85
4.3Sequences of Categories .......................................................................................... 87
5Discussion ....................................................................................................................... 88
x
i
5.1Interaction Categories and Processes at Daily Meetings ......................................... 89
5.2Decision Making in Daily Meetings ....................................................................... 90
6Limitations ...................................................................................................................... 91
7Conclusion and Further Work ......................................................................................... 92
References ............................................................................................................................. 93
Paper 4: Obstacles to Efficient Daily Meetings in Agile Development Projects ........... 95
1Introduction ..................................................................................................................... 96
2Research Method ............................................................................................................ 97
2.1The Company .......................................................................................................... 97
2.2Data Collection ........................................................................................................ 98
2.3Interviews ................................................................................................................ 98
2.4Observations of Daily Meetings .............................................................................. 98
2.5Data Analysis .......................................................................................................... 99
3Identified Obstacles and Their Consequences ................................................................ 99
3.1Temporal ............................................................................................................... 101
3.2Physical ................................................................................................................. 102
3.3Procedural .............................................................................................................. 103
3.4Attendee ................................................................................................................. 104
4Alleviating the Obstacles .............................................................................................. 106
5Potential Limitations ..................................................................................................... 109
6Conclusion .................................................................................................................... 109
References ........................................................................................................................... 110
Paper 5: The Daily Stand-Up Meeting: A Grounded Theory Study ............................ 113
1Introduction ................................................................................................................... 114
2Background ................................................................................................................... 115
2.1Meetings in General .............................................................................................. 115
2.2DSM in Agile Software Development .................................................................. 116
3Research Method .......................................................................................................... 116
3.1Data Collection ...................................................................................................... 119
3.1.1Interviews ....................................................................................................... 120
3.1.2Participant Observation .................................................................................. 121
3.1.3Questionnaire ................................................................................................. 121
3.2Data Analysis Techniques ..................................................................................... 122
3.2.1Coding ............................................................................................................ 122
3.2.2Constant Comparative Method ...................................................................... 122
3.2.3Memoing ........................................................................................................ 123
3.2.4Quantitative Measurement of Meeting Attitude ............................................ 123
3.3Analysis in Phase 1: Identifying the Core Category ............................................. 123
3.3.1Open Coding .................................................................................................. 123
3.3.2Selecting the Core Category .......................................................................... 123
3.4Analysis in Phase 2: Refining the Core Category ................................................. 124
3.4.1Selective Coding ............................................................................................ 124
3.4.2Determining Theoretical Saturation ............................................................... 125
3.5Analysis in Phase 3: Developing the Theory ........................................................ 125
3.5.1Theoretical Sorting ......................................................................................... 125
3.5.2Writing up the Theory .................................................................................... 126
x
ii
4Results ........................................................................................................................... 127
4.1Team Characteristics ............................................................................................. 129
4.2Physical Characteristics ......................................................................................... 130
4.3Reporting Progress ................................................................................................ 133
4.4Team Information Sharing ..................................................................................... 134
4.5Discussing and Solving Problems ......................................................................... 134
4.6Temporal Characteristics ....................................................................................... 135
4.7Attitude towards DSMs ......................................................................................... 138
5Discussion ..................................................................................................................... 140
5.1Implications for Research and Practice ................................................................. 140
5.2Limitations ............................................................................................................. 144
5.3Future work ............................................................................................................ 145
6Conclusion .................................................................................................................... 145
Appendix A Interview guide .............................................................................................. 146
Appendix B Observation protocol ...................................................................................... 147
References ........................................................................................................................... 148
1
Summary
1 Introduction
Software engineering involves methods and techniques to develop software systems
and includes specifying, designing, developing, deploying and maintaining software
systems. To build useful products, not only must good programming practices be
present in the development process but also good communication practices (Vliet,
2008).
Common to all agile methods is an emphasis on communication and the human
side of software development (Merisalo-Rantanen et al., 2005). Conducting a daily
stand-up meeting (DSM) was introduced in the agile methods Scrum and Extreme
Programming to improve communication in software projects. The DSM is now the
most popular agile practice (VersionOne, 2013) and a team practice that often
distinguishes agile from non-agile teams (Murphy et al., 2013).
So far, no empirical studies, other than those presented in this thesis, have
focused on the use and the positive and negative aspects of the DSM. However,
experiences with DSMs are often mentioned in studies reporting on other agile
practices. For example, the DSM has been found to keep project members aware of
the project status and help developers resolve design issues faster (Pikkarainen et al.,
2008) and to help reveal problems early and bring transparency between sites
(Paasivaara et al., 2008). McHugh et al. (2012) reported that DSMs assisted agile
teams in functioning more cohesively and Moe et al. (2010) observed that DSMs
were mostly used by the Scrum Master to obtain an overview of what was
happening in the project.
Summary
2
The DSM is claimed to have many benefits. According to Schwaber and Beedle
(2002, p. 40), the DSM improves communication, eliminates other meetings,
identifies and removes impediments to development, highlights and promotes quick
decision-making and improves everyone’s level of project knowledge. Furthermore,
the DSM is supposed to support people in team-based, intense and cooperative
development. However, many of the claims made by the agile community lack
scientific support (Dybå and Dingsøyr, 2008). The DSM is no exception; no reliable
evidence exists that the DSM has all the claimed benefits. Schwartzman (1989, p.
50) noted that meetings have often been the research tool to study other phenomena
such as decision-making processes, group conflict, communication and other small-
group dynamics, but meetings have not themselves been the primary topic of
interest. This might be one reason why the DSM has not previously been the topic of
in-depth investigations.
1.1 Research Problem and Questions
The focus of this thesis is to empirically investigate how the DSM is conducted in
agile software projects. The thesis addresses the overall research problem of how to
improve the way the DSM is conducted, which is divided into the following
research questions:
RQ1: What are the characteristics of DSMs in present agile software development
projects?
RQ2: What are the key positive and negative aspects of using DSMs in agile
software development projects?
This thesis consists of five papers that all address the overall research problem.
More specifically, RQ1 is addressed in Papers 3, 4 and 5 and RQ2 in Papers 1, 2, 4
and 5.
1.2 Research Setting
The research presented in this thesis has mainly been conducted within the context
of the TeamIT research project, which was funded by the Research Council of
Norway through grant no. 193236/I40. TeamIT’s primary objective was to achieve
effective teamwork across software development project teams in the Norwegian
and global IT industry by providing research-based knowledge and innovations. To
achieve the primary objective, the project aimed to establish effective autonomous
teamwork practices and mechanisms for coordination within and across teams in the
participating companies and to develop research-based methods, techniques and
guidelines.
The field studies of this thesis were conducted in four companies: Alpha, Beta,
Gamma and Delta (pseudonyms). The first three companies were part of the TeamIT
project. Delta was part of a project called Evisoft, which was funded by the
1 Introduction
3
Research Council of Norway through grant no. 174390/I40. The main goal of the
Evisoft project was to achieve improved business processes in the IT sector by
establishing a scientific basis for process innovations.
1.3 Contributions
The research reported in this thesis is based on four case studies and one grounded
theory study conducted in four companies altogether. The studies increase the
research community’s knowledge of the DSM. More specifically, the main
contributions are as follows:
A thorough investigation of the DSM. The DSM is often considered to be a
fairly simple practice to implement and to have many benefits. This thesis
confirms some of the benefits, but numerous pitfalls are also identified,
which are rarely discussed in the literature.
The use of grounded theory as a methodology in the field of software
engineering. Relatively few researchers have conducted pure grounded
theory studies in software engineering. This thesis demonstrates in depth
how grounded theory was applied.
A theory of the DSM. An initial theory of DSMS is proposed as a starting
point for understanding the key constructs and relationships of DSMs in
agile software development projects. The resulting theory consists of seven
constructs and six propositions.
Guidelines for conducting DSMs. New evidence-based guidelines on how to
conduct DSMs are proposed. The guidelines aim to support software
companies in organizing their use of DSMs.
1.4 Thesis Structure
This thesis is organized as follows:
Summary: Section 1 introduces the research topic of this thesis and the thesis
papers. Section 2 presents background. Section 3 describes the research methods
applied in this research. Section 4 summarizes the results of the research. Section 5
discusses the results. Section 6 presents concluding remarks.
Papers: Five papers are included in this thesis, each of which is briefly described
below.
Paper 1, “Challenges to Teamwork: A Multiple Case Study of Two Agile Teams”
(Stray et al., 2011), discusses two concepts related to teamwork: team orientation
and team learning, which are challenging in agile software development. Observed
indications of low team orientation were that developers were interested in the DSM
only to a low extent and they did not pay attention to what others were saying in the
meeting. A challenge related to team learning was that the developers found it
Summary
4
difficult to solve identified problems; for example, problems with the way they
conducted the DSM. The abstract states:
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.
Paper 2, “Escalation of Commitment: A Longitudinal Case Study of Daily
Meetings” (Stray et al., 2012a), addresses how the DSM may affect escalating
commitment, a phenomenon in decision-making. The abstract states:
Escalating commitment is a common and costly phenomenon in software
projects in which decision-makers continue to invest resources to a failing
course of action. We conducted a longitudinal case study exploring the
effect of daily meetings on escalating commitment. This was done in an
agile project building software for the oil and gas industry. By analyzing
data collected over a period of four years, and drawing on concepts from
self-justification theory we found that daily meetings contributed to
maintain a situation of escalating commitment. This especially occurs if the
meeting becomes a place for reporting and defending decisions with team
members feeling that they have to justify their choices towards the project
management or fellow team members. Early signs of escalation such as
rationalizing continuation of a chosen course of action must therefore be
taken seriously.
Paper 3, “Investigating Daily Team Meetings in Agile Software Projects” (Stray et
al., 2012b), reports on an analysis of the team interaction in DSMs. The abstract
states:
An increasing amount of time is being spent at organizational meetings.
One common type of meeting in software projects is the daily team
meeting, which is the most important forum for coordinating and planning
daily work. To better understand how software teams make decisions,
communicate, and coordinate their work, we must uncover the micro-level
1 Introduction
5
interaction processes among the team members at these meetings. We
analyzed transcriptions of eight daily meetings from two software
development teams. The agile literature states that the daily meeting should
focus on answering questions such as “What have I done? What will be
done? What obstacles are in my way?” However, on average, only 24% of
each of the meetings that we studied focused on this task. We found that
35% of the meeting was spent on elaborating problem issues and discussing
possible solutions. Very little time was used for coordinating tasks. Our
results indicate that many project decisions are made in daily team meetings
and that this quick decision making requires team members to be experts.
These experts need to have a shared understanding of who is responsible
for what and of the information and requirements needed to solve the tasks.
Paper 4, “Obstacles to Efficient Daily Meetings in Agile Development Projects: A
Case Study” (Stray et al., 2013), describes thirteen obstacles that reduce the
efficiency of the DSM. The abstract states:
Most of the software organizations that use agile methods organize daily
team meetings. Our aim was to understand how daily meetings are
conducted and identify obstacles that reduce their efficiency. 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.
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.
Paper 5, “The Daily Stand-up Meeting: A Grounded Theory Study” (Stray et al.,
2014), describes how the DSM is conducted, what the attitudes towards it are, how
challenges of conducting the DSM can be overcome and how its benefits can be
realized. The paper presents a grounded theory of the DSM. The abstract states:
The daily stand-up meeting is one of the most used agile practices.
However, it has rarely been the subject of empirical research. The present
study aims to identify how daily stand-up meetings are conducted and what
the attitudes towards them are. A grounded theory study of the daily stand-
up meeting was conducted with twelve software teams in three companies
located in Malaysia, Norway, Poland and the United Kingdom. We
Summary
6
interviewed 60 people, observed 79 daily stand-up meetings and collected
supplementary data from other sources. The two factors that contributed the
most to a positive attitude towards the daily stand-up meeting were
information sharing with the team and the opportunity to discuss and solve
problems. The two factors that contributed the most to a negative attitude
were status reporting to the manager and spending too much time; both the
frequency and duration of the meeting were perceived to be too much.
Based on our results, we developed a grounded theory of daily stand-up
meetings and proposed evidence-based guidelines on how to organize
them. Organizations should be aware of the factors that may affect attitude
towards daily stand-up meetings and should consider our proposed
guidelines as a means to improve the way they are conducted.
2 Background
This section describes the concept of the meeting, the ideas behind agile software
development and the DSM in the context of agile teams. A comment on daily
meetings in other disciplines is given to close the section.
2.1 Meetings
Meetings are necessary for teamwork to be successful (Kauffeld and Lehmann-
Willenbrock, 2012). Meetings provide a venue for information exchange, decision
making, coordination, planning and monitoring progress, each of which is an
essential component of the team processes associated with team performance
(O’Neill and Allen, 2012). Employees spend a lot of time in meetings, and the
amount has increased over the last decades (Rogelberg et al., 2006).
There are two common definitions of a meeting. First, according to Schwartzman
(1989, p. 7), a meeting is “… a communicative event involving three or more people
who agree to assemble for a purpose ostensibly related to the functioning of an
organization or a group, for example, to exchange ideas or opinions, to solve a
problem, to make a decision or negotiate an agreement, to develop policy and
procedures, to formulate recommendations, and so forth. A meeting is characterized
by multiparty talk that is episodic in nature, and participants either develop or use
specific conventions (…) for regulating this talk.”
Second, according to Boden (1994, p. 84), a meeting is “… a planned gathering,
whether internal or external to an organization, in which the participants have some
perceived (if not guaranteed) role, have some forewarning (either longstanding or
quite improvisational) of the event, which has itself some purpose or ‘reason,’ a
time, [a] place, and, in some general sense, an organizational function.” Meetings
have characteristics related to the organization of talk and interaction. Boden (1994,
p. 82) says that meetings are not just talk but also involve who talks when, to whom
2 Background
7
and for how long. Meetings can be “too short” to cover the given agenda or “too
long” for the subject matter or the patience of participants (Boden, 1994, p. 83).
2.2 Agile Software Development
Agile is an umbrella term for several iterative and incremental software
development methods that values short development iterations and frequent delivery
of software, active customer engagement throughout the whole development
process, direct and frequent communication between developers and customers, and
responsiveness to change.
In agile software development, there is a substantial focus on teams. The teams
are presumed to be self-managing; that is, the team members follow a shared vision
and social norms to achieve a common purpose. Brodbeck (2002) uses the term self-
managing synonymously with self-organizing. Self-organizing agile teams are
described as teams that can organize their own workload (Cockburn and Highsmith,
2001) and determine how best to accomplish their goals (Sutherland and Schwaber,
2013a). Guzzo and Dickson (1996) use the term self-managing teams synonymously
with the terms autonomous work groups and empowered teams. The concept of
autonomous work groups emerged out of the Norwegian Industrial Democracy
Program in 1962 and was successfully adapted by organizations in Japan (Røyrvik,
2013). When I refer to self-managing or self-organizing teams in this thesis, I use
the definition of Guzzo and Dickson (1996): “Teams of employees who typically
perform highly related or interdependent jobs, who are identified and identifiable as
a social unit in an organization, and who are given significant authority and
responsibility for many aspects of their work, such as planning, scheduling,
assigning tasks to members, and making decisions with economic consequences
(usually up to a specific limited value).”
The projects reported on in this thesis used one of two agile methods, Scrum and
Kanban. Both Scrum and Kanban use pull scheduling, which means that the teams
decide how much work to commit to and pull work when they are ready rather than
having it “pushed” in from the outside (Kniberg and Skarin, 2010). Scrum is more
prescriptive than Kanban, as illustrated in Table 1.
Scrum is the most popular agile method. Scrum or Scrum variants are used by
72% of those employing agile methods (VersionOne, 2013). Scrum prescribes short,
fixed-length iterations called sprints. During a sprint, which usually lasts two to four
weeks, the development teams work on the sprint backlog.
Kanban software development is based on the idea that work in progress should
be limited and the workflow should be visualized with the use of a Kanban board.
Kanban encourages delayed commitment on both prioritization of new work and
delivery of existing work.
Summary
8
Table 1: Differences between Scrum and Kanban (Kniberg and Skarin, 2010)
Scrum Kanban
Daily stand-up meetings Prescribed Optional
Timeboxed iterations Prescribed Optional
Team commits to a specific
amount of work for an
iteration
Prescribed Optional
Default metric for planning
and process improvement
Velocity Lead time
Team Self-organizing and cross-
functional teams prescribed
Self-organizing teams
prescribed, cross-
functional teams optional,
specialist teams allowed.
Work-in-Progress limit Indirectly (per sprint) Directly (per workflow
state)
Board A sprint backlog is owned by
one specific team. The
Scrum board is reset between
sprints.
A Kanban board may be
shared by multiple teams
or individuals. The board
is persistent.
Roles Prescribes 3 roles: Product
Owner, Scrum Master and
team member
None prescribed
2.3 DSM in Agile Teams
One of the main characteristics of agile teams is the DSM. According to a survey
conducted by Murphy et al. (2013), use of the DSM was the team practice that
varied the most between agile and non-agile teams in 2011. The survey found that
agile teams were 48% more likely to use DSMs than non-agile teams. The DSM is
supposed to be a brief gathering of team members and satisfies both of the
definitions of a meeting given in Section 2.1, because the event is planned and has a
pre-arranged time and place, and a purpose. These characteristics distinguish the
DSM from incidental social encounters at work. DSMs, like other types of meetings,
are fitted into the rhythm of the organization and have slots within the ongoing
temporal patterning of work; they also have their own place in clock time, duration
and location. When the DSM was first introduced in Scrum, all of the team members
were supposed to answer the following three questions in the meeting (Sutherland,
2004):
(1) What did you do yesterday?
(2) What will you do today?
(3) What obstacles got in your way?
A survey from 2009 reported that 69% of agile practitioners adhered to these three
questions (VersionOne, 2009). In Scrum, the DSM is referred to as the daily Scrum
meeting (Sutherland and Schwaber, 2013a); in Extreme Programming, it is referred
to as the daily stand up meeting. Other names are the Scrum meeting (Rising and
2 Background
9
Figure 1: The percentage of agile practitioners employing the techniques DSM, test
driven development and pair programming (VersionOne, 2007–2014)
Janoff, 2000), frequent, short meetings (Rising, 2002), the morning roll call
(Anderson, 2004), the daily huddle meeting (Paez et al., 2005) and the daily meeting
(Pikkarainen, 2008). Throughout this thesis, I use the names DSM and daily meeting
(early papers).
Despite being the most commonly used agile practice (VersionOne, 2013), the
DSM has been overlooked as a topic of study. The two most thoroughly investigated
agile practices are pair programming and test-driven development (Dingsøyr et al.,
2012). Figure 1 compares the adoption rate over time of the DSM, test-driven
development and pair programming. The use of the DSM by agile practitioners
increased from 55% in 2007 to 85% in 2013. Test-driven development had no
increase (38% in both 2007 and 2013). Pair programming increased from 24% in
2007 to 30% in 2013.
The DSM is defined as a mandatory practice in Scrum. The originators of Scrum
conceived the idea of a daily meeting from a paper (Coplien, 1994) that reported on
the software project that developed Borland’s Quattro Pro, in which architecture,
design and interface issues were discussed in daily meetings (Schwaber and Beedle,
2002, p. 12). Being an apparently simple practice to implement, the DSM has
garnered increasing interest in terms of adoption and diffusion. Recommendations
such as “The best way to begin implementing Scrum is to establish daily Scrum
status meetings” (Schwaber, 2003), is one possible explanation for the popularity of
the DSM. The DSM was a way for software organizations to show that the
organization had joined the agile movement and to be able to use new jargon such as
“Daily Scrum.”
The DSM is not a mandatory practice in Kanban, but many teams that practice
Kanban nevertheless use DSMs; for example, the Kanban teams reported in Sjøberg
$
$
$
$
$
$
$
$
$
!$
$
   !    






Summary
10
et al. (2012) and the Kanban teams studied in this thesis. According to Kniberg and
Skarin (2010), Kanban teams tend to use a more board-oriented format in which
they focus on bottlenecks on the Kanban board instead of a format in which every
person reports one by one.
The DSM relates to decision-making in agile teams. Moving from plan-driven to
agile development can be seen as moving from rational to naturalistic decision-
making (Moe et al., 2012). Rational decision-making describes a process in which
decision makers are fully informed and rational, and problems are well defined and
have a set of alternative solutions and assumed consequences (Simon, 1979). With
rational decision-making, the decision-makers’ rationality is assumed to be restricted
by the information they have, their cognitive limitations and the types of problems
they face. With naturalistic decision-making, the decision-making is assumed to be
driven by knowledge gained through experience (Lipshitz et al., 2001). The
naturalistic decision-making process was expanded to include the stage of
perception and recognition of situations, as well as generation of appropriate
responses, not just choosing from given options (Klein, 2008).
With agile development, much of the decision-making has moved from the
project manager to the development team, and the decision-making process has
changed from individual and centralized to shared and decentralized. According to
Schwaber and Beedle (2002, p. 40), the DSM highlights and promotes quick
decision-making. When teams conduct decision-making in DSMs, they may have
insufficient time to explore ideas and generate alternatives and thus need to make
decisions based on their individual knowledge and experience; that is, they may
follow a naturalistic decision-making process.
2.4 Daily Meetings in other Disciplines
The majority of teaching hospitals conduct morning meetings, often called morning
reports. Despite widespread use, the meetings have rarely been examined in
research, and studies are lacking to document their effectiveness (Amin et al., 2000).
The morning meetings usually last for an hour, and the primary purpose is education
(Amin et al., 2000). Thus, these meetings are very different from the DSM discussed
in this thesis. However, some hospitals have introduced so-called surgical morning
meetings, which are more relevant because they aim to improve the communication
among the staff, and each meeting involves a discussion of the patients (Aston et al.,
2005). An analysis of these meetings identified four areas of impact: predictability
(a nice way to start the day), knowledge and perspective (learning from each other),
relationship and support (getting to know you) and desired outcomes (making a
difference to staff, children and families) (Aston et al., 2005).
Some types of organizations have meetings at the beginning of every shift; for
example, hospitals, police stations and restaurants. In these meetings, there is an
explicit hand off of work from one shift to the next, which is quite different from the
DSM. These meetings would correspond to meetings in software projects in which
3 Research Methods
11
teams in one location continue work from another location, also called follow-the-
sun development (Carmel and Agarwal, 2001).
3Research Methods
This section describes the setting and methodology of the research reported in this
thesis.
3.1 Research Context
Alpha is a Norwegian IT consulting firm with 350 employees. The Kanban project I
studied had two distributed, closely collaborating teams; one located in Norway, the
other in Poland. The project members worked on maintenance and extensions of a
content management system. Beta is an international telecommunications software
company with 700 employees. In Beta, I studied two Scrum teams in Norway and
five Scrum teams in Malaysia. The teams were working on different projects.
Gamma is a medium-sized software company with approximately 150 employees in
four organizational units. I studied one team in Norway and one in the United
Kingdom. The goal of the Scrum project was to develop an engineering software
product for the oil and gas industry. Delta is a Norwegian software company with
140 employees. The company develops software systems for archiving and for
planning and coordinating excavation work. The goal of the Scrum project that I
investigated was to develop a system that combined textual user interfaces and map
functionality. Figure 2 illustrates which company or companies were investigated in
each study. Study 1 is reported in Paper 1, Study 2 in Paper 2 and so forth. I
observed DSMs in two teams from Alpha, three teams from Beta, three teams from
Gamma and one team from Delta, as shown in Table 2. In addition, another four
teams in Beta were interviewed but not observed.
Figure 2: Companies investigated in the five studies
Alpha
Beta
Gamma
Delta
Study 1
Study 3
Study 4
Study 2
Study 5
Summary
12
Table 2: The investigated teams
Comp-
any
Location Team Team
mem-
bers
Inter-
viewed
Obser-
ved
Distri-
bution
Time
of
DSM
Alpha
Norway 1 10 Co-located 09:00
Poland 2 9 Co-located 09:00
Beta*
Norway 1 9.5 Distributed 10:30
Norway 2 8.5 Co-located 10:00
Malaysia 3 10 Co-located 10:00
Malaysia 4 3 Co-located NA
Malaysia 5 8 Co-located 10:00
Malaysia 6 6 Co-located NA
Malaysia 7 9 Co-located NA
Gamma
Norway 1 10 Co-located 09:45
UK 2 9 Distributed 09:30
UK 3 8 Distributed 09:45
Delta Norway 1 8 Co-located 09:00
*Teams 1 and 2 in Beta shared one team member.
3.2 Research Perspective
This thesis adheres to the theoretical perspective of the interpretive research
paradigm. Interpretive research focuses on understanding human experiences and
actions within the context of the studied phenomenon. Findings are considered fully
dependent on researchers, and knowledge creation is assumed to occur through
social interaction between the researchers and individuals within the study (Klein
and Myers, 1999). The choice of an interpretive paradigm was suitable since I
wanted to investigate participant perspectives to gain a better understanding of the
DSM.
3.3 Research Approach
By conducting five empirical studies, the concept of DSM was investigated through
social interaction with DSM participants. Järvinen’s (2008) classification of research
approaches is depicted in Figure 3. Both case studies and grounded theory studies
are classified as theory-developing studies. This study type typically suggests
qualitative research, which involves the analysis of text acquired from interviews,
observations and documents (e.g. company reports, memos, meeting minutes and
presentations).
Figure 4 describes the research process. The general area of interest that I started
with was “effective teamwork in agile software development projects,” which was
the focus of Study 1. As my PhD process evolved, my particular interest became “a
study of the DSM in agile software development projects.” I found case studies to be
3 Research Methods
13
Figure 3: Taxonomy of research approaches (Järvinen, 2008). Blue indicates the
selected research approach for this thesis
well suited in combination with grounded theory. This approach is supported by
Glaser (2001, p. 97), who stated that much may be learned from case studies by
doing secondary grounded theory analysis. Consequently, grounded theory
researchers may start with data and results from existing case studies, then
iteratively compare and generate categories and finally construct a grounded theory
with general implications.
Investigating the DSM in different national and organizational cultures helped
me understand the general perceptions and nature of the practice. The process of
data collection and analysis was iterative, and I went back and forth between the
companies, which enabled a study of the DSM from different viewpoints and in
different phases of the projects. Both the data collection and analysis involved
multiple researchers who analyzed the data systematically, adding more interviews
and different data sources to the analysis. I continue by discussing in more detail
theory and my applications of case studies, grounded theory, data collection and data
analysis.
All studies
Studying the real world
Innovation-building
studies
Innovation-evaluating
studies
Natural/social sciences,
"value-free" studies
(how and why things are)
Design science,
"value-laden" studies
(utility of innovation)
Theoretical studies
on reality
Empirical studies
on reality
Theory-testing studies Theory-developing
studies
Mathematical studies
Summary
14
Figure 4: The research process
Constant comparative method
Open coding
Selecting core
category:
Daily stand-up meeting
Data collection using
theoretical sampling
Determining saturation
Theoretical sorting
Selective coding
Data collection using
selective sampling
Selecting theme:
Effective teamwork in
agile software projects
Norway, Poland, UK, Malaysia
(Alpha, Beta, Gamma)
Code:
"Communication
interrupting workow"
Concept:
"Interruptions"
Phase 2:
Rening the
core category
Phase 3:
Developing the
theory
Category:
"Reporting"
Code:
"Demonstrating
progress"
Concept:
"Manager monitoring"
Category
"Fragmented work"
Examples of open coding
Examples of selective coding
Phase 1:
Finding the
core category
Writing up the theory
Example of sorting
Teamwork and
meeting literature
Cross-referencing
with literature
Norway
(Alpha)
InterviewsObservations
Questionnaires InterviewsObservations
Constant comparative method
Norway
(Delta)
InterviewsObservations
Analysis using
teamwork concepts
Data collection via
selective sampling
Analysis of
transcripts using
constant
comparative
method
Paper 3
Paper 4
Paper 5
Analysis using
constant
comparative method
Analysis using
meeting concepts
Paper 1
May 2011
Grounded theory phases:
September 2012
October 2013
July 2014
Paper 2
May 2012
3 Research Methods
15
3.4 Case Studies
According to Yin (2009, p. 18), case studies are the preferred research method if the
researcher wants to gain in-depth understanding of a real-life phenomenon. When
conducting case studies, Yin proposes the five-step process as follows:
1. Case study design: Objectives are defined, and the case study is planned.
2. Preparation for data collection: The procedures and protocols for data collection
are defined.
3. Collecting evidence: Data on the studied case is collected.
4. Analysis: The collected data is analyzed.
5. Reporting: The results are reported.
Case study research can be based on both quantitative and qualitative data.
Interviews are the most important source of information but should ideally be
supplemented with other data, for example, data collected from participant
observation and surveys (Walsham, 2006). When conducting a case study, the
researcher can choose either a single or multiple case study design, and either a
holistic (single unit of analysis) or embedded (multiple unit of analysis) design. Yin
(2009, p. 47) lists five rationales for choosing a single-case design; the case is
critical, unique, representative, revelatory or longitudinal. A multiple-case design is
preferred over a single-case design because the conclusions may be more powerful
and the study less vulnerable.
I chose case study methodology for four of the studies because it is an
appropriate research method if the researcher wants to answer “why” and “how”
questions and understand a phenomenon in depth (Yin, 2009, p. 13). Study 1 was a
multiple-case study consisting of two holistic cases. A single-case holistic design
was chosen for Study 2. An important feature of this study was that it was a
longitudinal study with data collected over four years, which allowed the
Table 3: Three principles of data collection in case studies (Yin, 2009, p. 114–124)
Principle Description
1: Use multiple
sources of
evidence
Triangulation of data sources increases construct validity. The six main
sources of case study evidence are documentation, archival records,
interviews, direct observation, participant-observation and physical
artifacts.
2: Create a case
study database
A case study database increases the reliability of the case study. Case
study notes are likely the most common component of the database and
must be stored in a manner such that it is possible to efficiently retrieve
them at a later date. The documents in the database should be
organized, categorized and complete.
3: Maintain a
chain of
evidence
Maintaining a chain of evidence increases both the reliability of the
information in the case study and the construct validity. An external
observer should be able to trace the steps from the research questions to
the case study conclusions. The reported case study should cite relevant
portions of the case study database, for example, citing specific
observations and interviews.
Summary
1
6
evolvement of DSM to be studied over time. A single-case design was chosen for
Studies 3 and 4 because the projects under investigation represented typical cases.
The case studies were embedded with two teams as the units of analysis. In all the
case studies, I adhered to the three principles of collecting data shown in Table 3.
3.5 Grounded Theory
Grounded theory is defined as “a general methodology of analysis linked with data
collection that uses a systematically applied set of methods to generate an inductive
theory about a substantive area” (Glaser, 1992). The first formal description of the
grounded theory approach was published in The Discovery of Grounded Theory by
Glaser and Strauss (1967). Because the two authors later developed different
perspectives, grounded theory evolved into two versions, known as the Glaserian
and the Straussian methods of grounded theory, respectively (Goulding, 1998). In
addition, these main approaches have different versions, which have their own
terminology and processes; however, all versions of grounded theory share the
following characteristics (Charmaz, 2014, p. 7):
Having simultaneous involvement in data collection and analysis
Constructing analytic codes and categories from data, not from preconceived
hypotheses
Using the constant comparative method, which involves making
comparisons during each stage of the analysis
Advancing theory development during each step of data collection and
analysis
Memo-writing to elaborate categories and define relationships between
categories
Sampling aimed toward theory construction (theoretical sampling), not for
population representativeness
Conducting literature review after developing an independent analysis
The Glaserian and Straussian grounded theory approaches differ with respect to
formulation of research problems, data analysis and coding techniques, among other
things. According to Strauss and Corbin (1990, p. 34), a researcher should begin a
grounded theory study by defining a research problem. In contrast, Glaser advises
the researcher to move into an area of interest without a research problem (Glaser,
2001, p. 21). Furthermore, Glaser describes selective coding as occurring early in
the analysis, when the core category has been identified, while Strauss and Corbin
describe selective coding to as occurring towards the end of the analysis with the
purpose of selecting the core category (Glaser, 1992, p. 75). Glaser argues that the
theory should only explain the phenomenon under study, while Strauss and Corbin
describes coding matrices as explaining the phenomenon beyond the immediate field
of study (Goulding, 1998). Glaser (1992, p. 62) criticizes the use of these coding
matrices because, he claims, they lead to theories based on preconceptions because
data is “forced” into categories.
3 Research Methods
17
Table 4: Grounded theory techniques used throughout the research (Glaser, 1992,
2001):
Term Description
Constant
Comparative
Method
Comparing codes and concepts to produce a higher level of abstraction.
The constant comparative method has two important procedures:
1) Comparing codes to codes and codes to concepts for similarities and
differences.
2) Asking the neutral question “What does this statement indicate?”
Memoing Writing notes, called “memos,” to record reflections on the data. A way to
capture ideas as they emerge and create a basis for deeper analysis.
Open coding The initial stage of comparative analysis. The analyst starts with no
preconceived codes. Open coding sets the direction of the research by
identifying a core category.
Theoretical
sampling
The selection of new interviewees and where to observe are directed by
the results of the coding process. The aim of theoretical sampling is to
ensure that new data contribute to theory development.
Selective
coding
Succeeds open coding. The coding is limited only to categories related to
the core category.
Theoretical
saturation
The researcher decides that no more data need to be collected because the
core category and its connections to other relevant categories are
sufficiently elaborated.
Theoretical
coding
Detecting relationships between codes, concepts and categories. Use of
theoretical coding families and existing theories assists researchers in
conceptualizing how categories and their properties may relate to each
other and increase completeness and relevance for the grounded theory.
Theoretical
sorting
Sorting of memos, which is the key to present the theory in words and
writings.
I chose grounded theory because it is a suitable research method for areas that
are under-explored and when the researcher is interested in understanding the
experience of a phenomenon by asking “what is going on here?” (Glaser, 1978).
Because of the substantial differences between the Glaserian and Straussian
grounded theory approaches, it is important that researchers explicitly state which
approach they use. I decided to follow Glaser’s approach since I wanted to approach
the field with no research questions but rather a general area of interest; that is, I
wanted to let the concepts and categories emerge from the data. Furthermore, I
found the Glaserian approach more attractive because it is less prescriptive than the
Straussian approach. Table 4 describes the grounded theory techniques that I used
throughout the research process.
3.6 Role of the Researcher
Acknowledging researcher bias is an initial step in grounded theory, and generally
important in interpretive research. Since I am the principal researcher in all the
studies in this thesis, I will describe my experience and knowledge, because they
may influence the study results. Before entering the research field, I worked for
three years in the industry as a consultant in a project that used agile methods.
DSMs were successfully used in that project, and I experienced some of the
Summary
18
advantages of using DSMs. Soon after starting on my PhD I became a certified
Scrum Master to obtain insights into how Scrum Masters are trained and what they
learn about DSM.
Additionally, I am a certified coach with more than 350 hours of training. I
believe that this education has helped me to approach situations with an open mind
and to be sensitive to what may bias my interpretations. The interpersonal skills of
communication and listening are critical to data collection. When conducting the
interviews, I attempted to be aware of what I could do to gain trust and to be
sensitive to the participants’ answers and non-verbal communication. My coaching
experience was valuable both when I was the one who asked the questions and when
I listened to an interviewee and asked follow-up questions. The skills were also
valuable when observing and interpreting the data collected. Another way of
reducing researcher bias was that I collaborated with a different set of researchers
for each of the studies, which meant that the collected data and subsequent analysis
were discussed from different angles.
3.7 Data Collection
All five studies used at least three different data sources to obtain triangulation of
the data. Table 5 shows that the major data sources were interviews (of people with
different roles) and participant observations (in DSMs, retrospective meetings,
planning meetings, individual work and informal conversations). Observing
retrospective meetings was especially valuable because they often included
discussions of DSMs. Supplemental data sources used in the studies were
questionnaires and project documents (product backlogs, sprint backlogs, burn down
charts, presentations and reports). I wrote field notes and took pictures. The
interviews lasted from 30 to 90 minutes and were always audio-recorded and
transcribed. Details about the interviewees are given in the papers of this thesis.
In some of the interviews, I used the repertory grid technique (Fransella et al.,
2004) to obtain additional information. This technique was used because it is
Table 5: Main data sources
Study Company Main data sources
1 Alpha 8 interviews (all new), participant observations
Delta 5 interviews (all new), participant observations
2 Gamma 20 interviews (all new), participant observations
3 Beta Transcribed DSM observations
Delta Transcribed DSM observations
4 Beta 21 interviews (all new), participant observations
5 Alpha 15 interviews (7 reused, 8 new), participant observations
Beta 33 interviews (17 reused, 16 new), participant observations
Gamma 12 interviews (9 reused, 3 new), participant observations
3 Research Methods
19
suitable for interpretive research and grounded theory (Edwards et al., 2009). The
main objective of the technique 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 5- or 7-point scale) according to
certain criteria, which are called personal constructs or simply constructs. I found
that identifying elements and rating them on a scale made it easier for the
interviewees to talk about negative aspects of teamwork. The interviewees were
encouraged to think aloud, which gave valuable insight into the choices that they
made. The repertory grid sessions produced a total of 131 issues (elements).
3.8 Data Analysis
Following the commonly given advice to analyze data early (Miles and Huberman,
1994, p. 50), I began the data analysis as soon as the first interviews had been
conducted. Figure 4 shows how the process of data collection and analysis was
iterative and ongoing. The data analysis for the grounded theory study was
performed simultaneously with the analysis of the data from the four case studies.
The grounded theory data analysis followed Glaser’s two sequential stages of open
coding and selective coding. In the open coding process, I analyzed the entire
transcripts in detail. In the selective coding process, I coded only the passages of th