1 A Case Study From An Agile Distributed Project in India
1 A Case Study From An Agile Distributed Project in India
net/publication/224256381
Why Scrum Works: A Case Study from an Agile Distributed Project in Denmark
and India
CITATIONS READS
44 4,744
2 authors:
Some of the authors of this publication are also working on these related projects:
Same group of authors same topic two correlated researches View project
All content following this page was uploaded by Lene Pries-Heje on 19 May 2014.
Abstract—Scrum seems to work extremely well as an agile approaches are often referred to as high-speed development
project management approach. An obvious question is why. To [6], an approach for dealing with change [7] characterized by
answer that question, we carried out a longitudinal case study iterative processes [8]. A prominent example of agile
of a distributed project using Scrum across Denmark and processes is Scrum [9].
India. In our analysis of case study data we used three selected
theoretical frameworks. We conclude that Scrum works so well
Today, more and more companies are adopting Scrum
because it provides communication, social integration, control, for agile software project management. In Denmark, the
and coordination mechanisms that are especially useful for authors have regularly been teaching professional IT project
distributed and agile project management. management courses, and recently – since 2008 – it has been
obvious that more and more people know Scrum and are
Keywords – Distributed; Agile; Project management; Scrum; working in organizations using Scrum or at least parts of
Boundary objects, Social capital, Articulation Theory Scrum. Out of 100 project managers, approximately 1/4 were
from organizations using Scrum in 2009, and in 2010 the
number had risen to 1/3. These numbers are based on “raise-
I. INTRODUCTION your-hand if you use it.” Nevertheless, the authors believe
that these numbers give a clear indication that Scrum has
Driven by increasing time-to-market pressure as well as gained surprising momentum recently.
cost saving incentives, more and more software projects are Based on the trend towards distributed and global
becoming global [cf. 1] with project participants distributed software development and the fact that Scrum seems to work
in different places. This means that work is being done by extremely well as an agile project management approach, we
anyone who does it better, cheaper, or faster. It also means phrase the obvious question, “Why does Scrum work?” as
that a company may have many projects characterized by our research question.
rapidly assembled project teams, geographically dispersed,
but with highly specialized professionals who perform A. SCRUM
specific projects. Thus, distributed teams and distributed Scrum was first described as The Rugby Approach in
projects will be very common in the future. Harvard Business Review [10], emphasizing that small
Software development includes activities such as cross-functional teams produce better results. Jeff Sutherland
analysis, design, coding and testing. A project management and Ken Schwaber used the Scrum approach in their
approach prescribes processes for carrying out management companies in the mid-1990s, and they worked together to
of software development activities. In the mid 1990s formalize the Scrum approach [11]. Jeff Sutherland
software development approaches were effective in large- continued to study distributed projects using Scrum [cf. 11,
scale, long-term development efforts that employed stable 12].
and disciplined processes [2]. In contrast, many software In short, Scrum is an iterative approach where an
projects involved rapid changes in requirements and iteration lasting two to four weeks is called a Sprint. The
unpredictable complexity. Software development approaches wished-for functionality is written as User Stories and
achieving a balance between flexibility and discipline were prioritized in a Product Backlog by a Product Owner
needed [3, 4] – and thus agile approaches were invented. representing the customer view. The highest prioritized
These approaches have received much attention from functionality becomes the target functionality for a Sprint.
both the practitioner and researcher community over the last The Sprint starts with a Sprint Planning Meeting where the
10-15 years - first as a novelty and later as a development targeted functionality is broken down and estimated (sized).
approach that has become widely used in practice [5]. Agile Every day the project team meets in a Daily Stand-up
Meeting that takes place in front of a Scrum Board. The daily above, it is mainly the behavioral competences that need to
meeting is not supposed to take more than 15 minutes and is be adapted. Especially: (1) Spreading energy and enthusiasm
chaired by a Scrum Master responsible for the process. [14, p.90ff "Engagement and Motivation" competence] at a
During the meeting every team member answers four distance and possibly through some computer-supported
questions. (1) What did you do yesterday? (2) What are you media is more difficult. (2) Teambuilding, developing a team
doing today? (3) Problems encountered? (4) Innovations? spirit [14, p.52], and building personal relations and
They work on four columns. The Scrum Board has estimated networks can be a lot more difficult if people are not
(sized) tasks in the first column, and the tasks in progress are physically together. (3) “Help ensure effective
in the second column – that is where team members move communications with the project team …” [14, p. 106] will
tasks that they have taken on. When a team member believes be more challenging when communication needs reach
a task is finished it is moved to the third column called Done, across distances and cultures.
and when another team member has quality assured the task In general, studies of distributed and global software
it is moved to the fourth column called Done Done. Finally, development have shown that what you need to deal with are
when a task is finished it is registered on a Burn-Down Chart the three “C”s: communication, coordination and control
where you can see expected versus realized production. [15-17]. We have answered the research question of why
After the two to four week iteration, the Sprint produces Scrum works by analyzing a longitudinal case study of a
a deliverable of value to the customer(s) represented by the distributed software development project using Scrum to
Product Owner. In the concrete, the produced functionality is ensure in-depth knowledge.
demonstrated to the Product Owner who then recognizes the The remainder of the paper is organized as follows. We
value of the deliverable. Last but not least, the team looks describe the study and our analysis in section II. Then
back and carries out a Retrospective where they try to learn follows sections III - VII accounting for our findings in three
from the Sprint just completed: What worked for us? What areas: social team capital, boundary objects, and articulation
did not work? What changes will we implement in the next theory, the three areas where our analysis reveals that Scrum
Sprint? works and provides value in distributed projects. Plus two
sections on Control, social integration and motivation.
B. The challenges of distributed projects
Finally, our conclusion in section VII lists the nine answers
We define a distributed project as one where the project we found that together explain why Scrum works.
team is separated by geography, time zones and/or culture,
but nevertheless has to work together as a team.
Distributed projects will typically - as traditional projects II. RESEARCH METHOD
– have a project manager. The majority of project To obtain detailed qualitative data for analysis and to
management work will be the same in a traditional or a answer our research question of why Scrum works, we
distributed project. But some things will be different or more looked for a case of software development that we could
challenging when managing distributed projects. The follow in detail and over a period of time.
question is of course: What will be different? Danske Bank gave us the opportunity to follow a
Project management knowledge has recently been distributed project team using Scrum. Group IT of Danske
gathered and presented by two organizations worldwide. One Bank, has approximately 2500 IT people employed, of which
is the Project Management Institute (PMI) [13]. They have 80% is located in Denmark and 20% is located in India.
published a book of knowledge with nine areas, each Danske Bank uses a staff augmentation strategy for
containing the processes that together make it possible to outsourcing meaning in which most projects have team
achieve effective project management. Analyzing these areas members from both Denmark and India. In India, the team
for a distributed project, we find that: (1) it becomes harder members are employed by an Indian company, ITC Infotech,
to obtain a common understanding of the Project Scope. (2) but they work for the Danske Bank account.
Human resource management becomes harder, as you cannot We found a project using the agile method Scrum with
“pat your people on the shoulder” when they are doing a participants distributed across the two countries: Seven in a
good job. (3) It is difficult to communicate at a distance. Scrum team in Denmark and eight in a Scrum team in India.
Building trust at a distance is a further issue. (4) More focus For ease of reference, we call the project DELHI.
on early and fixed work breakdown structure (WBS) is The DELHI project started in May 2010. We interviewed
needed to be able to distribute work to distributed team the Project Manager for the first time right from the
members. (5) As quality is the fulfillment of expectations beginning of the project when he was appointed project
and because expectations may be culturally influenced and manager. Shortly after the first interview the project manager
therefore different, quality may be harder to manage. went to India and initiated a Scrum team there. The set-up in
The other organization is the International Project the project as a whole consisted of two Scrum-teams, one in
Management Association (IPMA) who published a so-called Denmark and one in India, with daily Scrum-of-Scrums
Competence Baseline [14] for project management. In meetings where the Project Manager and the two Scrum
addition to the challenges in distributed projects identified Masters met virtually, either by a phone conference or using
a tool called e-meeting. As part of setting up the Indian use of the Scrum Board, a daily Scrum-of-Scrums, and a so-
Scrum team, the Danish Project Manager planned a one- called ‘All Hands’ meeting where all team members from
week visit to India where the purpose was partly to diffuse both Denmark and India were present in a video conference
knowledge and skills on Scrum, and partly to do some towards the end of a Sprint.
classic team building. For both Danish and Indian second round interviews, we
Our first interview guide - used in the first few interviews used a semi-structured interview guide with the following
- was based on our conceptual analysis of project content:
management knowledge areas [13] and competence [14]
approaches. We used an open interview guide asking about • Your background: Education / Experience?
the use of Scrum, communication, coordination and control • The project? Scope? / Organization? / Roles?
[cf. 15]. We interviewed the project manager before and after • Denmark – India? People on-site in Denmark? /
his visit to India. The ‘after’ interview focused on whether You? / Use of Liaison Officers?
his expectations and plans had been fulfilled. • Communication: What? / Daily? / Regularly? /
At this point, we gathered our data and analyzed them Challenges? / Hindrances & obstacles?
applying some coding procedures from Grounded Theory - • Teambuilding: How do you build team? Education /
an inherently flexible methodology in which the researcher Experience
“should simply code and analyze categories and properties • Networking: Here? / Across to DK? / Community
with theoretical codes which will emerge and generate their here at ITC? Bangalore?
complex theory of a complex world”[18]. We used the • Project Management, Coordination and Control:
Strauss and Corbin [19] school of thought where GT analysis Formal control and follow-up? / Common vision? /
is composed of three groups of coding procedures called Informal? / Coordination Mechanisms?
open, axial and selective coding. Open coding reveals the • Examples: Surprises? Special & different about
core ideas found in the data by labeling phenomena and working here in general?
discovering categories. Axial coding develops a deeper
understanding of how the identified categories are related. B. Coding and categorizing
And finally, selective coding involves the integration of the
The research methodology we adopted in analyzing our
categories that have been developed to form the initial
data after the second round of interviews can be described
theoretical framework.
as a contextualized, interpretive one, using the technique of
When coding, we came up with categories such as: social
case study research [22, 23]. Our research can be
integration, common vision, common language, networking,
characterized as being interpretive research in that we
and building trust. We soon realized that a lot of what we
attempted to understand the distributed project using the
were finding could be captured by the concept of Social
agile Scrum “phenomena” and the problems therein through
Capital [20] which has three dimensions, namely, structural,
the meanings that people assigned to the issues we brought
relational, and cognitive. The structural dimension equals
up in the interviews. Thus, our access to reality is through
the relationships possessed by group members; the relational
social constructions, such as language, consciousness, and
dimension is about nature and quality of the relations; and
shared meanings [24].
the cognitive dimension concerns shared language and
Our data analysis followed the interpretive tradition,
meaning [20].
using hermeneutics [25]. Interview minutes and observation
A. The second round of interviews and a visit to India documents were coded and analyzed. Careful qualitative data
Based on our first round of coding, we decided to analysis [26] uncovered a number of underlying themes: one
change our interview guide to include social capital. In being social capital, but others were communication,
doing this, we used a framework by Evans & Carson [21] coordination and control, as well as motivation and
that uses couple social capital as a moderator for “three embedded quality assurance. In the following sections III –
common group processes for group effectiveness: VII we give an account of our findings.
communication, social integration, and coordination” – two
of the three “C”s we had in our first interview guide. We III. CASE ANALYSIS AND SOCIAL TEAM CAPITAL
interviewed the project manager three times: after the first
two Sprints had been finished, after something had been The concept of Social capital is relatively new and is an
released to the customer, and after the project was finished attempt to bring together a number of concepts such as
end of March 2011. informal organization, trust, culture, social support, social
Furthermore, in November 2010, we went to the DELHI exchange, social resources, embeddedness, rational
site in India for three weeks. Here, we interviewed the Indian contracts, social networks, and inter-firm networks [27].
part of the team (Scrum Master, Task Manager, Business Social capital has three dimensions, namely, a structural,
Developer, IT Developer, and Professional Tester) for about relational, and cognitive dimension [21, 27].
an hour each. We also observed daily Scrum meetings, the
A. The structural dimension As we see it, Scrum contributed to the development
The structural dimension involves the network of ties and (virtual) network ties because it more or less prescribed an
relationships possessed by individuals. When a new project internal network within each of the distributed Scrum team,
is established all team members enter the project with a and ties between the Scrum teams related to roles. Thus,
social network developed prior to the project, and they within each of the Scrum teams strong and redundant ties
continue to develop their network as the project is between all participants were emphasized, as well as strong
progressing. Thus, when analyzing the DELHI project, the ties between the Scrum Master for each team and the project
primary focus was on the development of social ties between manager. The All Hands meeting at the end of each sprint
participants within the project and secondarily on network provided an opportunity to form at least some sort of (initial)
ties to individuals outside the project team, but within the tie between members of the two Scrum teams.
two organizations. Hence, by prescribing and emphasizing ties within the
When the DELHI project started in May 2010 two Scrum teams and between people possessing specific roles
completely new Scrum teams were established, one in within the overall project organization, Scrum created
Denmark and one in India. A Project Manager for the project attention and an opportunity for ties to manifest themselves.
and its two Scrum teams was appointed, namely, an The quality of any tie, however, depends on the individuals
experienced Project Manager with some prior experience having trust in each other and being motivated to maintain
managing Scrum projects. the ties which is connected to the relational dimension of
As colleges of the same affiliation, the team members in social-capital.
Denmark had some prior knowledge about each other and B. Relational dimension and trust
some common work experience, although working in a
The relational dimension of social capital concerns the
Scrum team was new to them. Hence, weak network ties
nature and quality of the relationship between individuals in
within the Danish team existed from the outset. The Indian
the network. Trust is essential for developing strong ties, that
team members, however, had very limited knowledge about
is, ties of high quality. Four types of trust are suggested by
each other and no experience working together, thus,
Sabherwal [28]: calculus-based trust, knowledge-based trust,
virtually no network ties existed within the team prior to the
identification-based trust and performance trust, as being
project.
important for IT outsourcing projects. The four types of trust
The Indian Scrum Master and the Project Manager knew
are discussed in greater detail below.
each other beforehand, as the Indian Scrum Master had
First, calculus-based trust relies on explicit or implicit
worked 1½ years in Danske Bank in Århus, part of the time
perceived rewards and punishments associated with a
working on a project with the Project Manager. From the
particular contractual relationship. In the interviews we did
outset, the only tie between the Danish and Indian Scrum
not hear about any rewards or punishments that had or could
teams was the relation between the Project Manager and the
have influenced the quality of the relations between
Indian Scrum Master.
individuals within in the project or between project members
A project kickoff was performed in India (partly as a
and the surrounding organization.
Scrum sprint exercise) with participation of the Indian Scrum
Knowledge-based trust relies on personal knowledge
team, the Project Manager, and the Danish Scrum Master,
(experience) about the individual or second hand knowledge
which helped develop network ties within the Indian team, as
about prior merits. Knowledge based trust may exist prior to
well as ties between the Indian team members and the
starting a project if participants have a history together. In
Project Manager and the Danish Scrum Master. During the
the case organization, very limited knowledge-based trust
interviews the participants explained that this event was very
existed when the project started. The relation between the
important for developing ties among the participants. As the
Indian Scrum Master and the Danish Project Manager was,
project progress ties were strengthened, the ties between
however, an exception. The Project Manager noted in an
individuals in Denmark and India were developed. The
interview, “I have very high trust in the Indian Scrum
Business developer in the Indian Scrum team explained in an
Master, I have worked with him in Denmark and trust him, I
interview “I [now] have a virtual network in Denmark, and I
trust he knows what he is doing.” Observing the DELHI
know that Morten [in Denmark] is a ‘Viking’ [winter bather]
project work and conducting interviews in India in
in his spare time.” In the final interview with the Project
November 2011, it was clear to us (the researchers) that a
Manager he commented, “Strong ties have been developed
high degree of trust had been developed between the
within each Scrum team and the ties between the teams are
different participants. The Indian team members expressed
well developed.” He further explained that an Indian
trust in each other, but the Indians also felt confident and
software developer from the Indian Scrum team (who never
comfortable when interacting with the Danes. The trust
met face-to-face with his Danish colleges) at a recent visit to
concerned both professional capabilities and trust as human
Denmark walked around the organization with small
beings.
chocolate gifts and talked to the people he knew – at a
Looking at the two Scrum teams in the DELHI project,
distance from the project.
we find that using Scrum supported developing knowledge
trust (knowledge about each bother) because the daily Scrum IV. ARTICULATION THEORY FOR COORDINATION
meetings allowed all team members to interact and get to In addition to social capital, our second round interview
know what the others were doing. The all-hands meetings analysis had categories of data on the three “C”’s [15], the
provided knowledge about individuals across Scrum teams. first being coordination.
This setup provided ample opportunity for the team members Coordination was analyzed in the first team process. In
to get to know each other. order for multiple actors within a project to pursue a
Identification trust depend on both parties effectively common goal, they have to perform activities, which single
understanding and appreciating the others’ wants. Especially actors pursuing the same goals would not have to do; these
in the relation between the two Scrum teams, a respect for extra ordinary activities we call coordination. Thus,
the other party developed. Thus, during the interviews the coordination can be defined as “the additional information
interviewees expressed sympathy and understanding for the processing performed when multiple, connected actors
other party. When scheduling meetings, the times that fit pursue goals that a single actor pursuing the same goals
both sides were agreed upon, and strong ties in both India would not perform”[29]. One way to understand how
and Denmark developed based on personal/private coordination comes about could be by using the notion of
knowledge about each other. articulation [30]. Thus, in order for actors within a project
Finally, performance-based trust was established very to be able to collaborate and coordinate their effort, the tasks
quickly in the DELHI project. In an interview shortly after involved in pursuing the common goal need to be articulated,
the first release, the Project Manager told us that, in his and it should be established who is doing what, when they do
opinion, the first release went very well and he expressed it, and how and when to coordinate/align their work.
great confidence that the project would perform as intended. Strauss [30] argues that, analytically, it is useful to be
He also commented that the daily Scrum-of-Scrums allowed able to distinguish between two aspects of articulation: the
him to follow the performance closely. By using Scrum, articulation process and the articulation work. Articulation
performance trust was supported by frequent deliveries and work is a part of the overall articulation process; thus,
short feedback loop realized due to the fact that tasks were articulation process is the more inclusive set of actions.
relatively small and that someone else ensured quality Splitting articulation into two different constructs, however,
(testing the product). Between the two Scrum teams, allows an important distinction. The articulation process
performance trust was supported by demos/deliveries at the focuses on how work is actually performed by actors, while
end of each Sprint. Finally, performance trust was the articulation work has a more descriptive or prescriptive
established relatively fast between the Scrum team and the nature, focusing on “the specifics of putting together tasks,
project manager, based on the principle of daily Scrum-of- task sequences, task clusters.” It even aligns larger units,
Scrums meetings, the burn-down chart, and deliveries as the such as lines of work and sub-projects, in the service of a
result of each Sprint. workflow (ibid). The term articulation work has been
C. The Cognitive dimension adopted by a number of IS researchers and used in slightly
The cognitive dimension of social capital concerns different ways [31-34]. Here, we want to use Strauss’
shared vision and shared language and concepts. In the original definition of the constructs to analyze how Scrum, as
DELHI project, both the Project Manager and the team a project management and systems development paradigm,
members expressed that a shared vision for the project as influenced the articulation work and the articulation process
such was created quickly when using the product backlog as performed in a software development project. Second, we
the cornerstone. Breaking the product backlog down into a use Strauss’ work to discuss why Scrum also seems to be
release plan and sprint backlogs made the shared vision very very well suited for virtual teams, although it was originally
operational. Especially the participants in the Indian team intended for collocated project teams.
When interviewing project managers and members of the
were enthusiastic about this way of expressing a shared
vision. Using Scrum in the DELHI project also provided Scrum team, they pointed out that what they liked about
shared language and concepts concerning the developing working with Scrum was that Scrum helped them to
understand very clearly what work needed to be done within
process, as well as their roles and responsibilities.
Summing up, the analysis shows that the DELHI project the whole project and the specific Sprint; what they were
was very effective developing social capital. Ties within the expected to do themselves, what others were doing, and how
to coordinate work.
DELHI project’s Scum teams were established quickly and
developed into strong ties during the first couple of sprints. An analysis of the DELHI project with articulation
Developing ties between Scrum teams (sites) took a little theory indicates that articulation work, including
coordination, is performed in a very constructive manner
longer but was quickly started by the visit to India by the
Project Manager and the Danish Scrum Master. We found when using Scrum. When performing project work, it is
important to understand how to break down project work
that Scrum support developed social capital by creating
attention and opportunity for ties to manifest themselves. into tasks, sequencing the tasks, assigning the tasks to
specific individuals, deciding how to perform the tasks, and
recognizing the need for coordinating/aligning tasks.
How is this done when using Scrum? First, abstract tasks understanding of what is happening in relation to
(general user stories) are defined as part of the product communication.
backlog, without considering who or how to perform the When focusing on communication, the principle of short
tasks. Second, somewhat more detailed tasks are defined 15-minutes Daily Scrum meetings ensures an open channel
when establishing a Sprint backlog, and here the need for for communication, even if electronic media have to be used.
sequencing/coordinating tasks may also be addressed at an In the DELHI project, separate daily Scrum meetings were
abstract level. Thus, establishing the product backlog and the conducted on location in India and Denmark, followed later
sprint backlog allows reconciliation about the ‘what’ part in the day by a Scrum-of-Scrums meeting which was
(tasks) of the project work (between the product owner and conducted as an e-meeting (telephone line plus a shared
the project team) to take place without complicating it with electronic document showing the status of the Scrum Board
the ‘who’, ‘when’ and ‘how’ part. Third, tasks are defined in and the issues raised by the Scrum teams).
more detail when moving tasks from the sprint backlog into At the end of each Sprint an All Hands meeting was
the in progress column, and, at the same time, it is conducted as a video conference (live video of off-side
established who (in the team) is actually doing the work. participants), plus a shared presentation of documents, power
Thus, the need to coordinate with other tasks/people is points, product demo, and others.
addressed at a more detailed level. Finally, Daily Scrum Although meetings and boundary objects provide an
meetings and the Scrum Board provide a simple structure, opportunity to communicate, it may not result in open and
supporting the team and finalizing the articulation work. honest communication, as the building-up of social capital
In Danske Bank and the Delhi case it seems that Scrum obviously is more difficult to develop in virtual teams. But
allows articulation to take place just-in-time involving the also here some of the principles used in Scrum seem to be
actual participants in the work. Thus, using Scrum, the very powerful and help develop trust more or less for free.
articulation work takes place at a more and more detailed Hence, performance trust may be established quickly due to
level as the process progresses, and reconciliation of the frequent deliveries and quick feedback, knowledge trust
articulation work takes place when the people actually developed due to actually meeting every day, and calculus-
performing the tasks get involved. based trust formed from the Sprint Backlog which
The principle of making tasks, their sequence, and their established clear expectations about each delivery
status visible through the Sprint Backlog and the Scrum Apart from these observations on communication, in
board allows all team members to get an overview of the general, we found that we needed a more solid theoretical
tasks to be performed and those already performed, as well framework for explaining what went on when using Scrum
as to understand who is working on what tasks. This for distributed projects. To provide that theoretical
knowledge enables each team member to approach other perspective, we choose Boundary Object Theory which can
team members directly if a common issue has to be resolved. be used to provide a deeper understanding of communication
The daily Scrum meetings further allow team members to between key stakeholders. Boundary Objects are defined as
realize when coordination is needed. Thus, also in virtual “… objects which are both plastic enough to adapt to local
projects Scrum relies on mechanisms that enable team needs and constraints of the several parties employing them,
members to realize when coordination is needed instead of yet robust enough to maintain a common identity across
using pre-designed coordination mechanisms related to sites. They are weakly structured in common use, and
specific tasks. On the project level, coordination between become strongly structured in individual-site use. They may
more Scrum teams is provided by using common sprints be abstract or concrete. They have different meanings in
(common milestones) and all-hands meetings, and on the different social worlds, but their structure is common enough
day-to-day basis, the Scrum-of-Scrums meetings allow ad- to more than one world to make them recognizable means of
hoc coordination. translation” [35].
Hence, for Coordination, Scrum provides a framework In general a software development project will have four
that supports all parts of articulation work, and yet requires basic stakeholders. The intended users, developers, user
very little time trying to foresee and negotiate the work flow management and development management. Basically
and coordination mechanisms prior to actually conducting communication is needed between all four basic
the work. Four aspects of Scrum especially provide stakeholders, and often things go wrong because of mis-
coordination: the Product Backlog, the Sprint Backlog, the communication exactly at the boundaries between the four
Scrum Board and the Daily Scrum meetings. basic stakeholders. For example a user may say “I need
double entry bookkeeping”, but a developer, without
knowledge of the bookkeeping domain may say: “Let us
V. BOUNDARY OBJECTS FOR COMMUNICATION make it simple; you can have single entry bookkeeping”.
Communication is the second of the “C”-categories we This is a very bad idea, because all professional bookkeeping
analyzed. The analysis has two parts: 1) general factors has been double, ever since it was invented several hundred
influencing the communication in the DELHI project, and 2) years ago. Thus the developer clearly reveals (in the
the theory of boundary objects to provide a deeper and better
statement on single bookkeeping) his or her lack of Thus, our conclusion on boundary object and spanners
knowledge of the application domain. theory is that Scrum provides five different mechanisms that
However, lack of knowledge is common. Not only will work as such, and seem to work extremely well – based on
developers lack knowledge of the user domain, users may observations from the DELHI case.
also lack knowledge on what is technically possible. Further,
user representatives – i.e. user management – may not have
sufficient knowledge of the actual practice of the users, and VI. CONTROL
sellers may promise more than developers can deliver. The last “C” – Control - was also a category in our
Thus we need something plastic and adaptable to make findings. Best practice in distributed teams takes in common
the four basic stakeholders communicate, and that was milestones, frequent delivery, quick feedback, frequent
exactly what we found in Boundary Objects [35]. meetings, and frequent progress reports [16]. All these
In our analysis of the DELHI project, we found that practices can be found in Scrum as it was practiced in
Scrum offered three obvious boundary objects: (1) User DELHI. Sprints serve as common milestones, and each
stories, which bind together users (who can express their Sprint (which is relatively short) will bring a delivery.
needs in everyday-stories on use) and developers (who can Feedback on individual tasks is given when it is tested, and
understand the story and transform it easily to design feedback on a unit of tasks at the end of a sprint, which is
requirements). (2) Product Backlog, where the user performed at the end of a sprint to provide group
representative can prioritize tasks and thereby easily feedback/learning. Frequent meetings are implemented as
communicate to developers what is needed first. (3) Visible daily Scrum meetings and Scrum of Scrum meetings.
Scrum Board and burn-down charts, where the developers Progress can be read directly on the daily update of the
can easily express what value has been delivered and where scrum Board and the Burn-down chart.
Danske Bank management can quickly see whether the
project is on track.
Regarding communication, we also found that the two VII. SOCIAL INTEGRATION, QUALITY AND MOTIVATION
roles as Product Owner and Scrum Master in a way worked Evans and Carson [21] found social capital to moderate
as boundary objects or ‘bridge builders’ - as they were called coordination, communication and social integration. Thus,
in the DELHI project. A closer look at the literature shows we had a category in our analysis of DELHI data on social
that exactly these two roles can be classified as so-called integration.
Boundary Spanners [36]. In the concrete, Scrum can be said Social integration concerns the sense of belonging to a
to have pre-defined roles whereby individuals are nominated team, identifying with the team. In the interviews with the
in the two boundary spanning roles: (1) the Product Owner DELHI project manager, he expressed satisfaction with the
role that provides knowledge from the user-world to the team members not only for their motivation, their dedication
developer world, and (2) the Scrum Master role that ensures to the project, and their willingness to help each other, but
that the daily stand-up meeting runs smoothly and that also for helping the project to succeed and achieving their
knowledge is shared between developers and users goal. The team members interviewed expressed great
(represented by product owner). satisfaction working on this project, reporting that they were
We are not alone in seeing Boundary Objects as a good proud to be working on this project. We could not identify
theory for explaining what is going on in software design specific elements where Scrum supported social integration,
processes. A prominent example is Bergman et al. [37] who but together they had a shared vision with clear and
identify four essential features of boundary objects: (a) achievable goals. With much social capital, this provided a
Shared representation, (b) Transform design knowledge, (c) basis for social integration.
Mobilize for action, and (d) Legitimizing design knowledge. As for Quality, the Scrum Board division between Done
In our analysis of DELHI, we found the first three in Scrum. and Done Done ensured quality of the deliverables produced
User Stories and the Product Backlog are examples of (a) by the team. In the DELHI project, however, there was a
shared representations; the Sprint Planning Meeting is an specific role as Professional Tester, both in Denmark and
example of (b), transformation of design knowledge, and India, which ensured quality. We could see that Scrum was
shows – in our analysis – the closeness between articulation plastic enough to allow such roles to be part of the Scrum
theory and boundary objects, similar to what we discussed team.
in the section on Coordination above. The Scrum Board and Finally, when we asked the team participants how they
the Burn-Down Chart clearly mobilize for action (c). found working with Scrum, the answer was three-fold. First,
Finally, the prioritization of the Backlog by the Product they pointed to the closer contact with, and immediate
Owner brings “political” legitimacy (d) to the software feedback from the customer. Second, they felt increased
development process, as it grants "a legitimate status to a commitment and feelings of ownership. Third, they pointed
boundary object through validation of its content as to align to the energy released from being able to focus on and
with the stakeholders’ intent” [37, p. 551]. deliver quick results.
VIII. CONCLUSION [2] Harter, D., M. Krishnan, and S. Slaughter, Effects of process maturity
on quality, cycle time, and effort in software product development.
Based on the observation of Scrum gaining surprising Management Science, 2000. 46(4): p. 451-466.
momentum and being used for distributed projects, we [3] Cusumano, M.A. and D.B. Yoffie, Software development on Internet
phrased the research question: Why does Scrum work? time. IEEE Computer, 1999. 32(10): p. 60-69.
To answer this, we carried out a case study from which [4] Iansiti, M. and A. MacCormack, Developing Products on Internet
Time. Harvard Business Review, 1997(September-October): p. 108-
we obtained an in-depth understanding of the reasons for 117.
this. We analyzed the data gathered using first a grounded [5] Dybå, T. and T. Dingsøyr, Empirical studies of agile software
theory approach, followed by an interpretive hermeneutic development: A systematic review. Information & Software
approach. Our analysis shows why Scrum works in the Technology, 2008. 50(9-10): p. 833-859.
following ways: [6] Ågerfalk, P.J., B. Fitzgerald, and S. Slaughter, State of the Art and
Research Challenges. Information Systems Research, 2009. 20(3): p.
317-318.
• Scrum can build up relations and networks within
[7] Conboy, K., Agility from First Principles: Reconstructing the
and for the project team; Concept of Agility in Information Systems Development. Information
• Scrum has mechanisms for building trust – even at a Systems Research, 2009. 20(3): p. 329-354.
distance; [8] Austin, R.D. and L. Devin, Research Commentary--Weighing the
• Scrum gives the project team a common language Benefits and Costs of Flexibility in Making Software: Toward a
and target to aim for; Contingency Theory of the Determinants of Development Process
Design. Information Systems Research, 2009. 20(3): p. 462-a-477.
• Scrum is very useful for coordinating work in the
[9] Rising, L. and N.S. Janoff, The Scrum Software Development
project team; Process for Small Teams. IEEE Software, 2000(July/Aug): p. 26-32.
• Scrum makes a number of boundary objects and [10] Takeuchi, H. and I. Nonaka, The New New Product Development
boundary spanner roles available; Game. Harvard Business Review, 1986(January-February).
• Scrum includes a certain meeting structure that [11] Sutherland, J. and K. Schwaber, The Scrum Papers: Nut, Bolts, and
works well for communication in the project team; Origins of an Agile Framework. 2010, SCRUM Training Institute.
• Scrum includes simple but effective mechanisms for [12] Sutherland, J., et al. Fully Distributed Scrum: The Secret Sauce for
tracking project progress; Hyperproductive Offshored Development Teams. in Agile 2008.
2008.
• Scrum has simple mechanisms built in for ensuring
[13] Project Management Institute, A Guide to the Project Management
quality; and Body of Knowledge. 4 ed. 2008, Newtown Square, PA: Project
• the use of Scrum gives energy and motivation to the Management Institute.
team. [14] Caupin, G., et al., eds. ICB IPMA Competence Baseline Version 3.0.
3.0 ed. 2006, International Project Management Association: Nijkerk,
Together these nine answers form a comprehensive and The Netherlands.
profound explanation of the mechanisms in Scrum that [15] Carmel, E. and R. Agarwal, Tactical Approaches for Alleviating
affects how complex software projects are managed. This Distance in Glowal Software Development. IEEE Software,
2001(March/April).
contribution – we believe – is both more generalizable and [16] Paasivaara, M. and C. Lassenius, Collaboration practices in global
more useful than typical explanations which have just black- interorganizational software development projects. Software Process
boxed the Scrum method and thereby explain the success. Improvement and Practice, 2003. 8(4): p. 183-199.
[17] Krishna, S., S. Sahay, and G. Walsham, Managing Cross-Cultural
A. Validity Issues in Global Software Outsourcing. Communications of ACM,
Our findings were presented and discussed in a workshop 2004. 47(4): p. 62-66.
in India in January 2011. Further results were presented to [18] Glaser, B., Basics of grounded theory analysis. 1992, Mill Valley,
CA, USA: Sociology Press.
the Project Manager in January and in April 2011. The
[19] Strauss, A. and J. Corbin, Basics of Qualitative Research: Techniques
comments and critiques received have been worked into this and Procedures for Developing Grounded Theory. 2nd ed. 1998,
version of the paper. Beverly Hills, CA, USA: Sage Publications.
[20] Nahapiet, J. and S. Ghoshal, Social capital, intellectual capital, and
ACKNOWLEDGMENT the organizational advantage. Academy of Management Review,
1998. 23: p. 242-266.
The authors wish to acknowledge the valuable help of
[21] Evans, W.R. and C.M. Carson, A social capital explanation of the
Danske Bank Group IT, DCI, ITC Infotech, Linda Olsen, relationship between functional diversity and group performance.
Søren Gildsig and the many project team members who Team Performance Management, 2005. 11(7/8): p. 302-315.
allowed us access to their project. [22] Pettigrew, A.M., Longitudinal Field Research on Change: Theory and
Practice. Organization Science, 1990. 1(3): p. 267-292.
[23] Walsham, G., Doing Interpretive Research. European Journal of
IX. REFERENCES Information Systems, 2006. 15(3): p. 320-330.
[1] Hossain, E., M.A. Babar, and H.-y. Paik. Using Scrum in Global [24] Myers, M.D. and D. Avison, An Introduction to Qualitative Research
Software Development: A Systematic Literature Review. in Fourth in Information Systems, in Qualitative Research in Information
IEEE International Conference on Global Software Engineering. Systems - A Reader, M.D. Myers and D. Avison, Editors. 2002, Sage
2009. Limerick, Ireland. Publications: London. p. 3-12.
[25] Myers, M.D., Qualitative Research in Business & Management. 2009,
London: Sage Publications.
[26] Miles, M.B. and A.M. Huberman, Qualitative Data Analysis: An
Expanded Sourcebook. 1994, Thousand Oaks: Sage Publications Inc.
[27] Adler, P.S. and S.-w. Kwon, Social Capital: prospects for a new
concept. Academy of Management Review, 2002. 27(1): p. 17-40.
[28] Sabberwal, R., The role of trust in outsourced IS development
projects. Communication of ACM, 1999. 42(2): p. 80-86.
[29] Malone, T.W., What is Coordination Theory? 1988, National Science
Foundation Coordination Theory Workshop: Cambridge,
Massachusetts.
[30] Strauss, A., The Articulation of project Work: An Organizational
Process. The Sociological Quarterly, 1988. 29(2): p. 163-178.
[31] Gerson, E.M., Reach, bracket, and the limits of rationalized
coordination: Some challenges for CSCW, in Resources, Co-
Evolution and Artifacts. In: M.S. Ackerman, et al., Editors. 2008,
Springer: London, UK. p. 193-220.
[32] Star, S.L., The sociology of the Invisible, in Organization and Social
Process. 1991, Aldine De Gruyter: New York. p. 265-284.
[33] Strauss, A., Continual Permutations of action. 1993, New Your:
Aldine De Gruyter.
[34] Suchman, L., Supporting Articulation work. Computerization and
Controversy. 1991, San Diego: Academic Press. 407-423.
[35] Star, S.L. and J.R. Griesemer, Institutional Ecology, `Translations'
and Boundary Objects: Amateurs and Professionals in Berkeley's
Museum of Vertebrate Zoology, 1907-39. Social Studies of Science,
1989. 19: p. 387-420.
[36] Levina, N. and E. Vaast, The Emergence of Boundary Spanning
Competence in Practice: Implications for Implementation and Use of
Information Systems. MIS Quarterly, 2005. 29(2): p. 335-363.
[37] Bergman, M., K. Lyytinen, and G. Mark, Boundary Objects in
Design: An Ecological View of Design Artifacts. Journal of the
Association of Information Systems, 2007. 8(11): p. 546-568.