Conference PaperPDF Available

A Study of the Scrum Master’s Role

Authors:

Abstract and Figures

Scrum is an increasingly common approach to software development adopted by organizations around the world. However, as organizations transition from traditional plan-driven development to agile development with Scrum, the question arises as to which Scrum role (Product Owner, Scrum Master, or Scrum Team Member) corresponds to a Project Manager, or conversely which Scrum role should the Project Managers adopt? In an attempt to answer this question, we adopted a mixed-method research approach comprising a systematic literature review and embedded case study of a commercial software development team. Our research has identified activities that comprise the Scrum Master role, and which additional roles are actually performed by Scrum Masters in practice. We found nine activities that are performed by Scrum Masters. In addition, we found that Scrum Masters also perform other roles, most importantly as Project Managers. This latter situation results in tension and conflict of interest that could have a negative impact on the performance of the team as a whole. These results point to the need to re-assess the role of Project Managers in organizations that adopt Scrum as a development approach. We hypothesize that it might be better for Project Managers to become Product Owners, as aspects of this latter role are more consistent with the traditional responsibilities of a Project Manager.
Content may be subject to copyright.
A Study of the Scrum Master’s Role
John Noll1, Mohammad Abdur Razzak2, Julian M Bass3, and Sarah Beecham2
1University of East London, University Way, London, E16 2RD, UK
j.noll@uel.ac.uk
2Lero, the Irish Software Research Centre, University of Limerick, Ireland
{abdur.razzak,sarah.beecham}@lero.ie
3University of Salford, The Crescent, Salford, M5 4WT, UK
j.bass@salford.ac.uk
Abstract. Scrum is an increasingly common approach to software development
adopted by organizations around the world. However, as organizations transition
from traditional plan-driven development to agile development with Scrum, the
question arises as to which Scrum role (Product Owner, Scrum Master, or Scrum
Team Member) corresponds to a Project Manager, or conversely which Scrum
role should the Project Managers adopt?
In an attempt to answer this question, we adopted a mixed-method research ap-
proach comprising a systematic literature review and embedded case study of
a commercial software development team. Our research has identified activities
that comprise the Scrum Master role, and which additional roles are actually per-
formed by Scrum Masters in practice.
We found nine activities that are performed by Scrum Masters. In addition, we
found that Scrum Masters also perform other roles, most importantly as Project
Managers. This latter situation results in tension and conflict of interest that could
have a negative impact on the performance of the team as a whole.
These results point to the need to re-assess the role of Project Managers in or-
ganizations that adopt Scrum as a development approach. We hypothesize that it
might be better for Project Managers to become Product Owners, as aspects of
this latter role are more consistent with the traditional responsibilities of a Project
Manager.
Key words: Agile software development, Scrum, Scrum Master role, Empirical
Software Engineering
1 Introduction
Scrum [1, 2] is an increasingly common approach to software development adopted by
organizations around the world. According to the annual State of Agile Survey [3], 94%
of organizations surveyed practice agile development.
However, while the vast majority of organizations practice some form of agile de-
velopment, for most of these organizations, fewer than half of their teams have adopted
agile methods [3]. Therefore, as organizations transition from traditional plan-driven
development to agile development with Scrum, the question arises as to which Scrum
role (Product Owner, Scrum Master, or Scrum Team Member) is the Project Manager,
or conversely which Scrum role should Project Managers adopt?
arXiv:1712.01177v1 [cs.SE] 4 Dec 2017
2 John Noll et al.
In an attempt to answer this question, we used a mixed method research approach
comprising a systematic literature review and an embedded case study in a commercial
software development organization. Firstly, we reviewed the literature on agile soft-
ware development in order to identify which activities are conventionally performed
by Scrum Masters. We the n conducted observations and practitioner interviews in or-
der find out which activities are actually performed and which additional roles Scrum
Masters perform.
We found nine activities that are performed by Scrum Masters. Of these, only three
are conventional Scrum Master activities. Others would traditionally be considered the
responsibility of the Product Owner or Scrum Team. In addition, we found that Scrum
Masters also double in other roles, most importantly as Project Managers. This latter
situation results in tension and conflict of interest that could have a negative impact on
the performance of the team as a whole.
These results point to the need to re-assess the role of Project Managers in orga-
nizations that adopt Scrum as a development approach. We hypothesize that it might
be better for Project Managers to become Product Owners, as this latter role is more
consistent with the traditional responsibilities of a Project Manager.
The rest of this paper is organized as follows: in the next section, we present the
background related to Scrum and Scrum roles. Next, we describe our research method.
Following that, in ?? we present our results, and a discussion of those results in ??.??
ends with our conclusions.
2 Background
There are three key roles defined in the Scrum development approach: the self-organizing
development Scrum Team, the Scrum Master, and the Product Owner [2]. The Product
Owner represents the external stakeholder interests (customer, users, product manage-
ment) and so is the primary interface between these stakeholders and the software devel-
opment team [4]. The Scrum Team is responsible for the actual software development.
A further role, Product Manager, who “defines initial content and timing of the release,
then manages their evolution as the project progresses and variables change.. . [and]
deals with backlog, risk, and release content” was also described in the original de-
scription of Scrum [1]; this role is mostly performed by the Product Owner in modern
descriptions of Scrum [5].
The Scrum Master is responsible for facilitating the development process, ensuring
that the team uses the full range of appropriate agile values, practices and rules. The
Scrum Master conducts daily coordination meetings and removes any impediments that
the team encounters [2]. Six Scrum Master activities have been identified in a large-
scale distributed organisational context: process anchor, stand-up facilitator, impedi-
ment remover, sprint planner, scrum of scrums facilitator and integration anchor [6].
The process anchor nurtures adherence to agile methods. The stand-up facilitator en-
sures that team members share status and impediment information during each sprint.
The impediment remover ensures developers can make progress with their work. The
sprint planner supports the user story triage and workload planning that occurs prior to
development work starting in each sprint. The scrum of scrums facilitator coordinates
Scrum Master 3
work with the other scrum masters in the development program. The integration an-
chor facilitates the merging of code bases developed by cooperating teams working in
parallel.
According to Schwaber and Sutherland’s scrum guidelines, “the Scrum Master is a
servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum
Team understand which of their interactions with the Scrum Team are helpful and which
aren’t. The Scrum Master helps everyone change these interactions to maximize the
value created by the Scrum Team” [7]; in summary, the Scrum Master serves the devel-
opment team. This is in contrast to the Product Owner, who is responsible for maximiz-
ing the value of the product and the work of the Scrum Team. Schwaber and Sutherland
[7] state that although there is great flexibility in how this is achieved, the Product
Owner is the sole person responsible for managing the Product Backlog.
According to Schwaber and Sutherland [7], Product Backlog management tasks in-
clude: 1. “ordering the items in the Product Backlog to best achieve goals and missions;
2. optimizing the value of the work the Development Team performs; 3. ensuring that
the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum
Team will work on next; and, 4. ensuring the Development Team understands items in
the Product Backlog to the level needed. [7]”
Evidence from practice shows that the Scrum Master role is evolving. For example,
the role is sometimes shared, and activities performed by the Scrum Master are varied
and somewhat different from the original vision. This was observed by Gupta et al [8],
who found that the challenges of adapting scrum in a globally distributed team were
helped by more than one person sharing the Scrum Master and Product Owner roles.
Gupta et al developed a new Scrum Master taxonomy in which three new roles were
created to reflect the complexity involved in managing a global software development
team, and transitioning from Waterfall to scrum, the roles were: Scrum Master cum Part
Product Owner (where development leads were also acting in part as product owners),
Bi-Scrum Master (where a development leads worked remotely with the development
team) and Chief Scrum Master (fulfilling the need to co-ordinate among scrum teams).
According to the ISO/IEC/IEEE standard on user documentation in agile [9] the
Scrum Master and Product Manager have similar responsibilities when it comes to
explaining changing or new requirements. “The scrum master and information devel-
opment lead or project manager should provide guidance to the technical writers and
other members of the agile development teams on how to handle changing or new re-
quirements.” Perhaps this conflating of roles is largely due to organizations convert-
ing the traditional project manager role to a scrum master role, “As more and more of
our Project Managers become Scrum Masters and the Portfolio Managers becomes the
Group Scrum Master, our Portfolio Management Office needed to become Agile itself
[10].”
Adapting Scrum roles and creating new roles to manage large scale projects is ob-
served in other studies, where an ‘Area Product Owner’ (APO) role was created; this
APO role was shared by two people: a system architect and a product management
representative. The system architect worked closely with the team, while the product
management representative did not interact directly with the teams [11]. This combined
role (shared between two people) worked well for this organisation and was reported as
4 John Noll et al.
one of the successes of the project. However, in a later study, the same authors noted that
line managers had a double role: that of Scrum Master, and that of traditional line man-
agement duties involving personnel issues such as performance evaluation. Over use of
the Scrum Master role, who acted as a team representative at common meetings rather
than rotate the role, was found problematic. The team felt that these meetings were
a waste of time, and sent the scrum master instead of taking turns [12]. The frequent
meetings in Scrum were also a problem in [13]. A scrum master’s role is to facilitate
daily coordination meetings where coordination meetings are used to communicate sta-
tus of development work within the team and to product owners. However, the efficacy
of daily coordination meetings was often compromised by too many stakeholders at-
tending, or because the meetings were held too frequently to be beneficial for attendees
[13].
Corrupting the careful balance between Scrum roles leads to other problems. For
example Moe et al [14] observed that the scrum master also did estimates and did not
involve all the team in discussing a task. This lead to developers working alone, poor
team cohesion, and problems emerging at the end of the sprint rather than at the be-
ginning. A lack of thorough discussion was said to reduce the validity of the common
backlog “making the developers focus more on their own plan. Since the planning had
weaknesses and none of the developers felt they had the total overview, this probably
was one of the reasons for design-problems discovered later.”
Yet, in a recent survey that looked into whether project managers still exist in agile
development teams, Shashtri and Hoda were surprised to learn that 67% of organisa-
tions surveyed reported that they still had the Project Manager role. These authors call
for more research into why the Project Manager continues to be present on agile soft-
ware development projects, and how their role may have changed [15]. Conventional
wisdom suggests that Project Managers use a command and control style of manage-
ment, whereas Scrum Masters focus on leading and coaching [16]. As such, Scrum
masters are not line managers for their sprint team members. Further, scrum masters do
not assign work items to the members of their team, since the teams are self-organising
[6].
In summary, there is an emerging theme in the literature, namely that the original
balance of scrum master, product owner and team roles are being adapted, conflated,
and possibly corrupted, to suit the needs of organizations transitioning from waterfall
to Scrum, or scaling Scrum to large scale organisations. The extent to which the scrum
master role has changed is unknown. Therefore, in this study we now look to the wider
literature, and specifically ask two questions:
RQ1: What activities do scrum masters perform according to the empirical litera-
ture?
RQ2: What other roles do scrum masters perform in practice?
We ask these questions in order to establish a broader understanding of a key scrum
role that has clearly evolved since its inception in 1995 [17] and later refinement [7], and
consider whether adapting the theory proposed by Schwaber, Sutherland and Beedle is
something to be embraced or resisted.
Scrum Master 5
3 Method
In order to address our research questions, we adopted a mixed method approach com-
prising a systematic literature review and an embedded case study of a commercial
software development team [18]. We performed a systematic literature review [19] to
identify the set of activities and additional roles performed by Scrum Masters. Then, us-
ing observations and transcripts of semi-structured interviews we undertook as part of
an empirical study, we attempted to identify benefits or issues related to these activities
and roles.
3.1 Systematic Literature Review
Our review of the literature was conducted in four steps.
Fig. 1. Systematic literature review process
First, we defined two research questions:
1. What are the activities a Scrum Master performs?
2. What roles does the Scrum Master perform in addition to the Scrum Master role?
For expediency, we ran one search that combined both our research questions using
the following search string (or variants of the search string to fit the various databases):
(activit*OR task*OR responsibilit*OR action*OR role*OR job*)
AND ("Scrum Master")
We searched five well-established digital libraries listed in ?? for potentially relevant
publications. This search yielded 1,020 candidate publications.
Subsequently, we applied inclusion and exclusion criteria (see ??) to the titles and
abstracts of the initial set of 1,020 publications; this yielded a refined set of 122 publica-
tions. We again applied the inclusion and exclusion criteria to the full-text of these 122
6 John Noll et al.
Table 1. List of databases and number of publications.
Database # of publications
IEEEXplore 13
ACM Digital library 378
Scopus 30
Elesevier Science Direct 282
SpringerLink 317
Total 1020
Table 2. Inclusion and Exclusion criteria.
Inclusion criteria Exclusion criteria
IC1: Publication year: 2006-2017
IC2: Language: English
IC3: Full text available and acces-
sible
IC4: Focus on Scrum, in the field
of software engineering
IC5: Peer reviewed work
IC6: Answers one or more of the
research questions
EC1: Is an experience report, book, presen-
tation, or blog entry
EC2: Is a duplicated study (where authors
report similar results in two or more
publications–e.g. a journal paper that
is an extension of a conference paper);
exclude the least detailed paper, or if
unclear include the paper that is pub-
lished in the more notable venue.
publications, resulting in a final set of 33 publications. Two researchers were involved
in the systematic literature review process (see Figure 1).
Finally, from this final set of 33 publications, we extracted a list of Scrum Master’s
activities and additional roles, which are reported in ??.
3.2 Embedded Case Study
The company we studied, which we will call PracMed, is a medium-sized Irish-based
software company that develops practice and lab management software for the optical
industry.
Research Site PracMed employs approximately seventy staff members in its software
development organization, including support and management staff. PracMed’s annual
sales approach e20 million, from customers across the British Isles, continental Europe,
Scandinavia, North America and China.
Our study focused on TeamA, who are responsible for tailoring the company’s prod-
uct for a large customer in North America. The members of TeamA are distributed over
four countries on two continents, with up to eight hours difference in timezones between
locations. They are using Scrum to develop their software, with two weekly sprints. Ta-
ble 3 shows the distribution of team members; of these, two team members share the
Product Owner role, five are developers, one is the QA/Test lead, and one is Project
Manager. In TeamA, the Project Manager also plays role of Scrum Master. Also, the
Scrum Master 7
Product Owners report to the Product Manager, who is based in Spain and is responsi-
ble for the strategic direction of the product.
Table 3. Team Distribution.
Country Agile Roles No of Team Members
Ireland Product Owner 1
Software Developer 3
Quality Assurance 1
Canada Scrum Master (Project Manager) 1
Product Owner 1
Software Developer 1
USA Technical Lead (Software Developer) 1
Spain Product Manager 1
Data Collection We observed TeamA from January, 2016 through to March, 2017.
Specifically, one of the authors observed approximately 200 of TeamA’s Scrum cere-
monies, including daily standups, sprint planning, backlog grooming, and sprint retro-
spectives. Due to team members being distributed across Europe and North America,
the observations were made via video conference for each ceremony. The same au-
thor also conducted semi-structured interviews of each member of TeamA, which were
recorded and transcribed. The interviews took approximately one hour, and resulted in
136 pages of transcribed verbatim data. The interview protocol is available from [20].
The observer also made contemporaneous hand-written notes during both the cere-
mony observations and interviews. Finally, the interviewer summarized the interviews
using a mind-map, and presented the result to five interviewees in an online workshop
to validate the insights gained from the interviews.
Data Analysis Interview recordings and transcripts were carefully reviewed. An open
coding approach was used to identify topics in interview transcripts and contemporane-
ous notes of ceremonies. An approach informed by thematic analysis was used to group
codes into concepts [21].
4 Findings
In this section we summarise our results and in response to our research questions,
describe each of the Scrum Master’s activities identified in our data analysis. As noted
in our method, for consistency, where possible we adopt the activity name given in the
literature.
4.1 Systematic Literature Review
Our paper selection process identified a total of 33 publications that fit our search and
inclusion criteria (??).
8 John Noll et al.
Table 4. Publication by year.
Year 2006 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 Total
Publications 1113441826233
Table 5. Scrum Master activities.
Activities Ideal Scrum role Source
Process facilitation Scrum Master [6, 22, 23, 24]
Ceremony facilitation (including Scrum of
Scrums)
Scrum Master [6, 23, 25, 26, 27]
Impediment removal Scrum Master [6, 23, 28]
Prioritization Product Owner [29, 30]
Sprint planning Scrum Team [6, 31, 32, 33]
Sprint reviewing Scrum Team [34, 35]
Estimation Scrum Team Member [36]
Integration Scrum Team Member [6, 37]
Travelling none [26, 28]
Project management none [24, 29, 38, 39, 40]
Activities From these papers, we identified nine activities performed by Scrum Masters;
these are shown in ??. These activities are defined as follows:
Process facilitation involves guiding the Scrum Team on how to use Scrum to achieve
their objectives.
Ceremony facilitation involves moderation of the daily scrum, backlog grooming, sprint
planning, and sprint retrospective meetings that occur during each sprint.
Impediment removal is part of the Scrum Master as “servant manager” role: the Scrum
Master serves as a buffer between the Scrum Team and external pressures, and also
attempts to secure resources or remove blockers to progress that come from outside
the team.
Prioritization involves ordering stories on the product and sprint backlogs by order of
importance.
Sprint planning identifies those stories on the product backlog that will fit into a single
sprint, taking into account team velocity and capacity, and story estimates.
Sprint reviewing is part of the Sprint Retrospective ceremony where the team identifies
what went well, what could be improved, and might be added or removed from their
process to be more effective.
Estimation assigns a value in “story points” or ideal engineering time representing the
effort required to complete a story.
Travelling is an activity associated with distributed teams that involves visiting differ-
ent sites where teams are located, to facilitate communications [41]
Project management is a traditional management activity found in waterfall-style de-
velopment projects.
Scrum Master 9
Roles Fifteen papers mentioned other roles that Scrum Masters hold in addition to that
of Scrum Master. These are summarized in ??.
Table 6. Scrum Master additional roles.
Role Company-size Source
Project Manager Large-scale [42, 43, 44, 45, 46]
Product Owner unclear [29, 44]
Architect/Software Designer Large-scale [47, 48]
Project Lead Large-scale [49]
Developer/Senior Engineer Large-scale [30, 43, 49, 50, 51]
Team Leader Large-scale [42, 49, 52]
Test Lead unclear [43]
Head of Department/Dir. of Eng/Dev. Mgr. Large-scale [30, 43, 53, 54]
Of these eight roles, four (Architect/Software Designer, Developer/Senior Engineer,
Team Leader, and Test Lead) would be considered technical roles, and three (Project
Manager, Project Lead, Head of Department) are management roles. In total, nine of
fifteen papers reported the Scrum Master also taking on some kind of management
role, with six explicitly mentioning “Project Manager” or “Project Lead.
4.2 Embedded Case Study
We observed this tension and conflict of interest in our case study organization. On the
one hand, the Scrum Master performs project management duties:
So, we do all the traditional project management roles as in doing the scope
statement, the planning, change control process, communication management
plan and all that stuff. And, then internally [we act as] Scrum Master.
The planning part of this role has a waterfall characteristic:
When I got to start working on this project when there was a contract – there
is a very specific set of requirements. An analysis document is attached to that
contract. And there is a very specific set of actual deliverables .. . these are
actual things that we need to build and are doing. Umm, there is a very specific
budget for example, and the timeline is normally set as well in a high level. You
know it’s a one year project or six months. Then we get started and we start
with working with them then we create a scope statement, we create a brief we
you know create a charter [that] depends on the size of the project and really
how much of this spec we need to do.
In PracMed, project management for projects involving customization for large ac-
counts also involves interfacing with the customer:
So, remember with the client we got, the client facing role is the Project Man-
ager.
10 John Noll et al.
. . .let’s say I have both roles. Project manager is when I am dealing with our
clients and [customer] would be a great example.
The Scrum Master admits balancing these two roles creates tension:
. . .Madness! It’s hard. .. . if you know about one role not the other, I think it’s
easier because you do the best you can in your Scrum Master role or you do
the best in your Project Manager role ignoring the other. Now, the dilemma
is as a Project Manager I still know what the Scrum Master role is, I know
the Agile team – I know I am not supposed to break their rules and let them
be self-organizing and do all of that. At the end you have the client to answer
[to], you have management to answer to. So, you can’t just say oh well it’s in
the sprint or they plan for it or I don’t know when its gonna get done because
team is self-organizing. So, I think that’s why the challenges come. So, you have
responsibilities but yet you don’t have full on.
In particular, there is tension between the Project Manager as customer interface,
and the Scrum Master role:
. . . Yah, pressure will always be there . .. you cannot avoid that but it’s about
cause and effect type of thing I guess. An example would be, the client would
want to know a plan . . . they want to have a plan for everything that we are
going to do. Lets say, there are five change requests for example that’s in the
progress as we are still talking to them about what the requirement is. So, there
is no estimate on this. They want to know exactly when all are going to get
done. Now, in a Agile world there is no way that I could tell them when they
are going to get done until the estimates are there, until we started a sprint
planning, we don’t know this will go into this sprint or not, product owner
needs to be prioritize the things and product owner has other five epics on
the top list . . .so things like that which is very challenging and obviously with
a client it’s hard because I cannot just tell them we are doing Agile. So, it
won’t work this way. After I come back internally and pressure the guys . . .can
you first track change request. Can you do the estimate on it. If they do, they
are missing out something else they are supposed to do. So, I think that the
main challenge is the client but not internally because we all know, we are the
PracMed team, they know about it, they understand it. But, to the client it’s
hard to say and you cannot just say we are doing Agile. So, you have to wait
till the next planning or when there is a release plan. But, they want to know
every detail . . . they want to know every task, when it gets done then you can
test it.
5 Discussion
Scrum defines only three roles: Product Owner, Scrum Team Member, and Scrum Mas-
ter [2]. This results in a balance between the customer, user, and other stakeholder
interests, which are represented by the Product Owner, and the technical realities of
Scrum Master 11
software development, which are represented by the Scrum Team. The Scrum Master
facilitates the interaction between these two interests, and also serves to insulate the
team as a whole from external distractions (hence the description “servant-leader” that
is often used to describe Scrum Masters [5]).
Three Scrum Master activities (Process facilitation, Ceremony facilitation, and Im-
pediment removal) that formed part of our nine activities observed from the literature
would be considered “traditional” Scrum Master activities, as defined by Schwaber and
Beedle [2]. Prioritizing, on the other hand, is supposed to be the responsibility of the
Product Owner, and Estimation is supposed to be performed by the Scrum Team mem-
bers [2]. While the Scrum Master may facilitate these activities, he or she is not sup-
posed to perform them; this is because Scrum relies on a balance of power between
“business” and “technical” interests in order to set realistic sprint goals [2, 55]. Given
the Scrum Master’s role as facilitator, and mediator between the Product Owner and the
Scrum Team, overloading the Scrum Master role with project management introduces a
conflict of interest that can compromise the Scrum Master’s ability to ensure a balance
between the interests of external stakeholders and the Scrum Team: the Scrum Mas-
ter is supposed to insulate the team and remove impediments, but as Project Manager,
he or she would also have responsibilities to achieve objectives set by higher levels of
the organization. Stray and colleagues observed that when the Scrum Master is viewed
as a manager rather than facilitator, the daily scrum becomes a management reporting
exercise rather than a team communication meeting [13].
5.1 The Way Ahead
If tensions are created when the Scrum Master activities are combined with Project
Manager activities, which Scrum role is the right role to perform Project Manager ac-
tivities?
To answer this question, it’s useful to consider what project management involves
in Scrum, especially considering Scrum teams are supposed to be “self organizing.
Schwaber defines five project management activities that must be carried out when
undertaking development using the Scrum approach:
1. Vision management – establishing, nurturing, and communicating the product vi-
sion.
2. ROI management – monitoring the project’s progress against Return on Investment
goals, including updating and prioritizing the product backlog to reflect these goals.
3. Development iteration management – expanding items on the Product Backlog into
items for the Sprint Backlog, then implementing those items in order of priority.
4. Process management – facilitating ceremonies, removing impediments, and shield-
ing the team from outside interference.
5. Release management – deciding when to create an official release, in response to
market pressures and other investment realities.
Of these, only Process management is the responsibility of the Scrum Master; De-
velopment iteration management is the responsibility of the development team, and the
remaining activities (Vision management, ROI management, and Release management)
are the Product Owner’s responsibility.
12 John Noll et al.
This suggests that, when organizations decide to adopt Scrum, their existing Project
Manager’s should be assigned to the Product Owner role. The advantages are twofold:
first, as Product Owners, First, Project Managers could advocate for business require-
ments without feeling tension with their Product Owner responsibilities, since such
advocacy is consistent with the Product Owner role.
Second, the Scrum Master would be free to support the Scrum Team when business
requirements conflict with technical reality, and to support the Product Owner when
business priorities differ from Scrum Team Member preferences (for example, when
certain mundane functionality must be developed to keep the product roadmap pro-
gressing, at the expense of more technically interesting features), and to support both
when upper management pressure threatens to override or compromise the team’s own
decisions.
Our insights into the tensions and conflicts created by combining the Scrum Master
and Project Manager roles are based on observations of a single development team and
interviews of one Scrum Master/Project Manager. As such, we must be extremely cau-
tious about generalizing our results. However, our observations do suggest two propo-
sitions that can serve as the basis for further research:
P1: When adopting Scrum, teams will be more successful if the former Project
Manager adopts the Product Owner role rather than the Scrum Master role.
Conversely,
P2: When adopting Scrum, teams that combine the Scrum Master and Project Man-
ager roles will experience tension resulting from the conflict of interests between these
two roles.
6 Limitations
This research adopts a mixed method approach to compensate for the weaknesses of
each research approach used in isolation. Practitioner roles, such as that of scrum mas-
ter, are rapidly evolving over time and hence while literature is important it cannot be
solely relied upon for an up-to-date perspective. On the other hand, an empirical case
study conducted without recourse to previous literature would be weakened. Hence this
paper combines a systematic literature review with an empirical embedded case study
in a mixed method approach.
7 Conclusions
In this study, we adopted a mixed method research approach to investigate First, we
performed a systematic literature review related to the Scrum Master role and then an
embedded case study to uncover empirical evidence of what activities Scrum Master’s
actually perform, and what additional roles they take on. We found nine activities that
are performed by Scrum Masters, and eight additional roles that Scrum Masters also
play.
Combining the findings from literature with observations from a case study of a
medium-sized development organization, we identified tensions and conflicts between
Scrum Master 13
the Scrum Master role and the Project Manager role that are often combined in prac-
tice. As such, we hypothesize that, when adopting Scrum, organizations should appoint
existing Project Managers to the Product Owner role, rather than making them Scrum
Masters.
8 Acknowledgments
We thank the members of TeamA and members of the Project Management Team for
their generous and thoughtful collaboration on this study, and PracMed, for allowing
us to study their software development efforts. This work was supported, in part, by
Science Foundation Ireland grants 10/CE/I1855 and 13/RC/2094 to Lero - the Irish
Software Research Centre (www.lero.ie).
References
[1] Schwaber, K.: SCRUM development process. In Sutherland, J., Casanave, C.,
Miller, J., Patel, P., Hollowell, G., eds.: Business Object Design and Implemen-
tation, OOPSLA ’95 Workshop Proceedings, Springer-Verlag London (October
1995) 117–134
[2] Schwaber, K., Beedle, M.: Agile software development with Scrum. Volume 1.
Prentice Hall Upper Saddle River (2002)
[3] VERSIONONE.COM: 11th annual state of agileTM survey. Technical report,
VersionOne, Inc (2017)
[4] Schwaber, K.: Agile project management with Scrum. Microsoft press (2004)
[5] Cohn, M., Schwaber, K.: The need for agile project management. Agile Times 1
(January 2003)
[6] Bass, J.M.: Scrum master activities: process tailoring in large enterprise projects.
In: Global Software Engineering (ICGSE), 2014 IEEE 9th International Confer-
ence on, IEEE (2014) 6–15
[7] Schwaber, K., Sutherland, J.: The Scrum guide–the definitive guide to Scrum: The
rules of the game, july 2011. Available on-line at: http://www.scrum.org/
storage/scrumguides/Scrum%20Guide (2016)
[8] Gupta, R.K., Reddy, P.M.: Adapting agile in a globally distributed software de-
velopment. In: 2016 49th Hawaii International Conference on System Sciences
(HICSS). (Jan 2016) 5360–5367
[9] ISO/IEC/IEEE: Systems and software engineering – developing user documenta-
tion in an agile environment. Technical report, International Standards Organiza-
tion (March 2012)
[10] Tengshe, A., Noble, S.: Establishing the Agile PMO: Managing variability across
projects and portfolios. In: Agile 2007 (AGILE 2007). (Aug 2007) 188–193
[11] Paasivaara, M., Lassenius, C.: Scaling Scrum in a large distributed project. In:
2011 International Symposium on Empirical Software Engineering and Measure-
ment. (Sept 2011) 363–367
14 John Noll et al.
[12] Paasivaara, M., Lassenius, C.: Scaling Scrum in a large globally distributed orga-
nization: A case study. In: 2016 IEEE 11th International Conference on Global
Software Engineering (ICGSE). (Aug 2016) 74–83
[13] Stray, V.G., Lindsjorn, Y., Sjoberg, D.I.: Obstacles to efficient daily meetings in
agile development projects: A case study. In: Empirical Software Engineering
and Measurement, 2013 ACM/IEEE International Symposium on, IEEE (2013)
95–102
[14] Moe, N.B., Dingsyr, T., Dyb, T.: Understanding self-organizing teams in agile
software development. In: 19th Australian Conference on Software Engineering
(aswec 2008). (March 2008) 76–85
[15] Shastri, Y., Hoda, R., Amor, R.: Does the project manager still exist in agile
software development projects? In: 2016 23rd Asia-Pacific Software Engineering
Conference (APSEC). (Dec 2016) 57–64
[16] Berczuk, S., Lv, Y.: We’re all in this together. IEEE Software 27(6) (2010) 12–15
[17] Sutherland, J.V., Schwaber, K.: Business object design and implementation: Oop-
sla’95 workshop proceedings. the university of michigan. Technical report, ISBN
3-540-76096-2 (1995)
[18] Creswell, J.W.: Research Design: Qualitative, Quantitative, and Mixed Methods
Approaches. Fourth edn. SAGE Publications, Inc, Thousand Oaks, California
(2013)
[19] Kitchenham, B., Charters, S.: Guidelines for performing systematic literature re-
views in software engineering, v. 2.3. Technical Report EBSE-2007-01, Software
Engineering Group, School of Computer Science and Mathematics, Keele Univer-
sity (2007)
[20] Beecham, S., Noll, J., Razzak, M.A.: Lean global project interview proto-
col. Available at http://www.lero.ie/sites/default/files/
Lero_TR_2017_02_Beecham_Noll_Razzak-Lean%20Global%
20Project%20Interview%20Protocol.pdf (2017)
[21] Braun, V., Clarke, V.: Using thematic analysis in psychology. Qualitative Research
in Psychology 3(2) (January 2006) 77–101
[22] Andriyani, Y., Hoda, R., Amor, R.: Reflection in agile retrospectives. In: Interna-
tional Conference on Agile Software Development, Springer (2017) 3–19
[23] Baumgart, R., Hummel, M., Holten, R.: Personality traits of Scrum roles in agile
software development teams-a qualitative analysis. In: ECIS. (2015)
[24] Costa, N., Santos, N., Ferreira, N., Machado, R.J.: Delivering user stories for
implementing logical software architectures by multiple Scrum teams. In: In-
ternational Conference on Computational Science and Its Applications, Springer
(2014) 747–762
[25] Dorairaj, S., Noble, J., Malik, P.: Understanding team dynamics in distributed
agile software development. In: International Conference on Agile Software De-
velopment, Springer (2012) 47–61
[26] Alzoubi, Y.I., Gill, A.Q., Al-Ani, A.: Empirical studies of geographically dis-
tributed agile development communication challenges: A systematic review. In-
formation & Management 53(1) (2016) 22–37
Scrum Master 15
[27] Maranzato, R.P., Neubert, M., Herculano, P.: Moving back to Scrum and scaling to
Scrum of scrums in less than one year. In: Proceedings of the ACM international
conference companion on Object oriented programming systems languages and
applications companion, ACM (2011) 125–130
[28] Bless, M.: Distributed meetings in distributed teams. In: International Conference
on Agile Software Development, Springer (2010) 251–260
[29] Cajander, ˚
A., Larusdottir, M., Gulliksen, J.: Existing but not explicit-the user per-
spective in Scrum projects in practice. In: IFIP Conference on Human-Computer
Interaction, Springer (2013) 762–779
[30] Stray, V.G., Moe, N.B., Dingsøyr, T.: Challenges to teamwork: a multiple case
study of two agile teams. In: International Conference on Agile Software Devel-
opment, Springer (2011) 146–161
[31] Drury, M., Conboy, K., Power, K.: Obstacles to decision making in agile software
development teams. Journal of Systems and Software 85(6) (2012) 1239–1254
[32] Heikkil¨
a, V.T., Paasivaara, M., Rautiainen, K., Lassenius, C., Toivola, T., J¨
arvinen,
J.: Operational release planning in large-scale Scrum with multiple stakeholders–a
longitudinal case study at f-secure corporation. Information and Software Tech-
nology 57 (2015) 116–140
[33] Vlietland, J., van Vliet, H.: Towards a governance framework for chains of Scrum
teams. Information and Software Technology 57 (2015) 52–65
[34] Chamberlain, S., Sharp, H., Maiden, N.: Towards a framework for integrating ag-
ile development and user-centred design. In: International Conference on Extreme
Programming and Agile Processes in Software Engineering, Springer (2006) 143–
153
[35] Stray, V., Fægri, T.E., Moe, N.B.: Exploring norms in agile software teams.
In: Product-Focused Software Process Improvement: 17th International Confer-
ence, PROFES 2016, Trondheim, Norway, November 22-24, 2016, Proceedings
17, Springer (2016) 458–467
[36] Daneva, M., Van Der Veen, E., Amrit, C., Ghaisas, S., Sikkel, K., Kumar, R.,
Ajmeri, N., Ramteerthkar, U., Wieringa, R.: Agile requirements prioritization in
large-scale outsourced system projects: An empirical study. Journal of systems
and software 86(5) (2013) 1333–1353
[37] Alaa, G., Samir, Z.: A multi-faceted roadmap of requirements traceability types
adoption in Scrum: an empirical study. In: Informatics and Systems (INFOS),
2014 9th International Conference on, IEEE (2014) SW–1
[38] Baskerville, R., Pries-Heje, J., Madsen, S.: Post-agility: What follows a decade of
agility? Information and Software Technology 53(5) (2011) 543–555
[39] Caballero, E., Calvo-Manzano, J.A., San Feliu, T.: Introducing Scrum in a very
small enterprise: A productivity and quality analysis. In: European Conference on
Software Process Improvement, Springer (2011) 215–224
[40] Santos, R., Flentge, F., Begin, M.E., Navarro, V.: Agile technical management of
industrial contracts: Scrum development of ground segment software at the euro-
pean space agency. In: International Conference on Agile Software Development,
Springer (2011) 290–305
16 John Noll et al.
[41] Bass, J.M.: How product owner teams scale agile methods to large distributed
enterprises. Empirical Software Engineering 20(6) (2015) 1525 – 1557
[42] Gren, L., Torkar, R., Feldt, R.: Group development and group maturity when
building agile teams: A qualitative and quantitative investigation at eight large
companies. Journal of Systems and Software 124 (2017) 104–119
[43] Hoda, R., Murugesan, L.K.: Multi-level agile project management challenges: A
self-organizing team perspective. Journal of Systems and Software 117 (2016)
245–257
[44] Tuomikoski, J., Tervonen, I.: Absorbing software testing into the Scrum method.
In: International Conference on Product-Focused Software Process Improvement,
Springer (2009) 199–215
[45] Stray, V., Sjøberg, D.I., Dyb˚
a, T.: The daily stand-up meeting: A grounded theory
study. Journal of Systems and Software 114 (2016) 101–124
[46] Moe, N.B., Dingsøyr, T.: Scrum and team effectiveness: Theory and practice.
In: International Conference on Agile Processes and Extreme Programming in
Software Engineering, Springer (2008) 11–20
[47] D´
ıaz, J., P´
erez, J., Garbajosa, J.: Agile product-line architecting in practice: A
case study in smart grids. Information and Software Technology 56(7) (2014)
727–748
[48] Sekitoleko, N., Evbota, F., Knauss, E., Sandberg, A., Chaudron, M., Olsson, H.H.:
Technical dependency challenges in large-scale agile software development. In:
International Conference on Agile Software Development, Springer (2014) 46–61
[49] Diebold, P., Ostberg, J.P., Wagner, S., Zendler, U.: What do practitioners vary
in using Scrum? In: International Conference on Agile Software Development,
Springer (2015) 40–51
[50] Garbajosa, J., Yag ¨
ue, A., Gonz´
alez, E.: Communication in agile global software
development: An exploratory study. In: OTM Confederated International Confer-
ences” On the Move to Meaningful Internet Systems”, Springer (2014) 408–417
[51] Li, J., Moe, N.B., Dyb˚
a, T.: Transition from a plan-driven process to Scrum: a
longitudinal case study on software quality. In: Proceedings of the 2010 ACM-
IEEE international symposium on empirical software engineering and measure-
ment, ACM (2010) 13
[52] Galster, M., Angelov, S., Meesters, M., Diebold, P.: A multiple case study on the
architect’s role in Scrum. In: Product-Focused Software Process Improvement:
17th International Conference, PROFES 2016, Trondheim, Norway, November
22-24, 2016, Proceedings 17, Springer (2016) 432–447
[53] Alahyari, H., Svensson, R.B., Gorschek, T.: A study of value in agile software
development organizations. Journal of Systems and Software 125 (2017) 271–
288
[54] Vlaanderen, K., van Stijn, P., Brinkkemper, S., van de Weerd, I.: Growing into
agility: process implementation paths for Scrum. In: International Conference on
Product Focused Software Process Improvement, Springer (2012) 116–130
[55] Leffingwell, D.: Scaling software agility: Best practices for large enterprises. Ad-
dison Wesley, Boston, MA, USA (2007)
... • Operational definition -Leadership is played by a formal role (PMI and Agile Alliance, 2017; Noll et al., 2017. -The leader facilitates ceremonies, removes impediments, and shields the team from outside interference (PMI and Agile Alliance, 2017; Noll et al., 2017. ...
... • Operational definition -Leadership is played by a formal role (PMI and Agile Alliance, 2017; Noll et al., 2017. -The leader facilitates ceremonies, removes impediments, and shields the team from outside interference (PMI and Agile Alliance, 2017; Noll et al., 2017. -The leader is a "communication integrator" (Ganesh and Gupta, 2006). ...
... -The team planning the tasks (Karhatsu et al., 2010). -The leader protects the team (Noll et al., 2017; PMI and Agile Alliance, 2017). -The team has good communication with the client . ...
Article
Full-text available
Background: Measuring the organizational climate of agile teams is a challenge for organizations, mainly because of the shortages of specific instruments to agile methodologies. On the other hand, finding companies willing to participate in the preliminary validation of an instrument is a challenge for researchers of the organizational climate. The preliminary validation allows identifying problems and improvements in the instrument. Objective: We present the preliminary evaluation of TACT. TACT is an instrument to assess the organizational climate of agile teams. Its initial version comprises the Communication, Collaboration, Leadership, Autonomy, Decision-Making, and Client Involvement dimensions. Method: We planned and executed a case study considering three development teams. We evaluated TACT using open-ended questions, quantitative methods, and TAM dimensions of Intention to Use, Perceived Usefulness, and Output Quality. Results: TACT allowed to classify the organizational climate of the teams for the Communication, Collaboration, Leadership, Autonomy, Decision-Making, and Client Involvement dimensions. Some items were assessed negatively or neutrally, which represent points of attention. TACT captured the lack of agile ceremonies, the difficulty of the product owner in planning iterations, and the distance in leadership. In addition, TACT dimensions presented high levels of reliability. Conclusions: TACT captured the organizational climate of the teams adequately. The team leaders reported intention of future use. The items that compose TACT can be used by researchers investigating the influence of human factors in agile teams and practitioners who need to design organizational climate assessments of agile teams. By using an instrument adapted to assess the organizational climate of agile teams, an organization can better identify issues and improvement actions aligned with agile values, principles, and practices.
... Outros indicam o oposto, consideram que o PO não deve ser responsável por decisões técnicas e não deve se ocupar sobre "como" o produto será feito, mas apenas sobre o que deve ser feito (Sverrisdottir, Ingason, & Jonasson, 2014;Kristindottir, Larusdottir, & Cajander, 2016 As organizações possuem diversas limitações e, por isso, precisam realizar várias adaptações nas práticas, ritos e papéis das abordagens ágeis para adequá-los às suas respectivas realidades (Noll et al., 2017). Garcia et al. (2020) (Conforto et al., 2016). ...
Article
Full-text available
A abordagem de gerenciamento ágil de projetos inova ao estabelecer um conjunto de novas práticas de gestão, como planejamento iterativo, visão do produto e participação ativa do cliente no processo de desenvolvimento do projeto. A participação ativa do cliente é implementada por meio da figura do Product Owner. Porém, como proceder quando esse profissional não está presente ou não está comprometido? Como suas tarefas são distribuídas entre os membros da equipe? Essas tarefas são realmente feitas? Qual o impacto? Essa pesquisa analisa equipes que não contam com o papel específico de Product Owner. Para tal, empregou-se uma revisão das tarefas designadas pela literatura para esse papel e, a partir desses resultados, fez-se uma pesquisa do tipo estudo de caso em equipes que fazem uso das práticas do gerenciamento ágil sem a presença do Product Owner. O trabalho identificou que nos projetos com o Product Owner pouco atuante houve prejuízo maior que um projeto em que não havia este papel formalmente definido, sendo distribuído para outros profissionais. Os resultados apontam a proposição de que o Scrum Master poder ficar sobrecarregado quando o Product Owner não faz suas tarefas a contento. Por fim, apesar do entendimento da importância e necessidade desse papel, foi possível perceber que os projetos estudados tiveram sucesso para os clientes mesmo sem a presença Product Owner. Recomenda-se estudos futuros que possam generalizar estes resultados identificando a melhor forma de distribuir os papéis do Product Owner em situações de ausência.
... Team members who are not software developers cannot be expected to find their place in the process without process change. Noll et al. [82] observed an emerging theme in literature: the original balance of scrum master, product owner and team roles are being adapted, conflated, and possibly corrupted, to suit the needs of organizations transitioning from waterfall to Scrum, or scaling Scrum to large scale organizations. Therefore, it becomes crucial to distinguish between methods and practices that are neutral with regards to agility, and methods and practices that are not (findings 5, 6, and 8). ...
Preprint
Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders' collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15%). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.
Article
Full-text available
Scrum teams are at the heart of the Scrum framework. Nevertheless, an integrated and systemic theory that can explain what makes some Scrum teams more effective than others is still missing. To address this gap, we performed a seven-year-long mixed-method investigation composed of two main phases. First, we induced a theoretical model from thirteen exploratory field studies. Our model proposes that the effectiveness of Scrum teams depends on five high-level factors - responsiveness, stakeholder concern, continuous improvement, team autonomy, and management support - and thirteen lower-level factors. In the second phase of our study, we validated our model with a Covariance-Based Structural Equation Modeling (SEM) analysis using data from about 5,000 developers and 2,000 Scrum teams that we gathered with a custom-built survey. Results suggest a very good fit of the empirical data in our theoretical model ( CFI = 0.959, RMSEA = 0.038, SRMR = 0.035). Accordingly, this research allowed us to (1) propose and validate a generalizable theory for effective Scrum teams and (2) formulate clear recommendations for how organizations can better support Scrum teams.
Chapter
Agile methods have recently been popular by software development teams, with Scrum being the prominent process over the last decade. In Scrum, the Scrum Master serves the developers, the Product Owner, and the organization by coaching, leading, mentoring, planning, removing impediments, etc. Additionally, the Scrum Master is accountable for establishing the developer’s effectiveness. The global pandemic of Covid-19 changed the world unexpectedly in March 2020. Work has mostly shifted to a remote setting, and meetings have mostly transferred to being remote. People have had to adapt to these new circumstances worldwide. This research aimed to explore the changes that Scrum Masters and their teams have had to face during the first year of the Covid-19 period by increasing distributed working and the changes in the Scrum Master’s responsibilities. The results indicate that the most significant change has been decreasing communication with stakeholders and users after working more distributed. Additionally, not meeting socially, as the teams did before, has been a big challenge for the Scrum Teams.KeywordsScrum MasterStakeholder communicationDistributed work
Conference Paper
The most common interpretation of the meaning or even ‘key message’ of the term ‘agile’ is “mindset, set of principles and values”. Various research has shown that management generally lacks involvement in agile projects. However, the role of a project manager in agile projects is constantly evolving and needs to be redefined accordingly. The authors aimed to define which meta-components of the project leader profile are key and which agile mindset competencies are relevant to agile environments. In this study, the agile mindset competency profile of a project leader is elaborated on. The agile mindset competency profile of project leaders that resulted from the literature review and comprises 14 competencies was evaluated by practitioners. Moreover, four meta-components of the project leader profile in agile projects were defined and their importance was evaluated, too.
Article
Full-text available
Purpose This study aims to create a better understanding of how practitioners implement and work Agile while balancing the tensions arising between stability and change. Design/methodology/approach A grounded theory approach was used to explore what happens in practice when software development teams implement and work Agile. The empirical data consists of twenty semi-structured interviews with practitioners working in fourteen different organizations and in six different Agile roles. Findings As a result, a substantive theory was presented of continuously balancing between stability and change in Agile teams. In addition, the study also proposes three guidelines that can help organizations about to change their way of working to Agile. Research limitations/implications The inherent limitation of a grounded theory study is that a substantial theory can only explain the specific contexts explored in that study. Thus, this study's contribution is a substantial theory that needs to be further developed and improved. Practical implications The proposed guidelines can help organizations about to change their way of working to Agile. They can also assist organizations in switching from “doing Agile” to “being Agile”, thus becoming more successful. Originality/value The new perspective that this study contributes is the fact that our discovered categories show that several inherent processes are ongoing at the same time in order to balance the need to have both stability and change.
Conference Paper
Full-text available
A retrospective is a standard agile meeting practice designed for agile software teams to reflect and tune their process. Despite its integral importance, we know little about what aspects are focused upon during retrospectives and how reflection occurs in this practice. We conducted Case Study research involving data collected from interviews of sixteen software practitioners from four agile teams and observations of their retrospective meetings. We found that the important aspects focused on during the retrospective meeting include identifying and discussing obstacles, discussing feelings, analyzing previous action points, identifying background reasons, identifying future action points and generating a plan. Reflection occurs when the agile teams embody these aspects within three levels of reflection: reporting and responding, relating and reasoning, and reconstructing. Critically, we show that agile teams may not achieve all levels of reflection simply by performing retrospective meetings. One of the key contributions of our work is to present a reflection framework for agile retrospective meetings that explains and embeds three levels of reflection within the five steps of a standard agile retrospective. Agile teams can use this framework to achieve better focus and higher levels of reflection in their retrospective meetings.
Conference Paper
Full-text available
Agile Global Software Development is gaining relevance and importance. While communication is key for exchanging information between team members, multi-site software development introduces additional obstacles and delays. This paper reports an exploratory study on the impact of infrastructure on communication. Although this topic has been a subject of interest many issues remain unaddressed. In this paper we address both team member communication and the combination of project and product development. One of the main conclusions is that communication can be improved if tool infrastructure combine different levels of information (i.e. team members, project status and product status). The use of simple tools, such as Vsee in SmartBoards is useful for reducing distance between sites. Dependency on bandwidth is not a new issue but is still relevant.
Conference Paper
Full-text available
The majority of software developers work in teams and are thus influenced by team norms. Norms are shared expectations of how to behave and regulate the interaction between team members. Our aim of this study is to gain more knowledge about team norms in software teams and to increase the understanding of how norms influence teamwork in agile software development projects. We conducted a study of norms in four agile teams located in Norway and Malaysia. The analysis of 22 interviews revealed that we could extract a varied set of both injunctive and descriptive norms. Our results suggest that team norms have an important role in enabling team performance.
Article
Full-text available
The agile approach to projects focuses more on close-knit teams than traditional waterfall projects, which means that aspects of group maturity become even more important. This psychological aspect is not much researched in connection to the building of an "agile team." The purpose of this study is to investigate how building agile teams is connected to a group development model taken from social psychology. We conducted ten semi-structured interviews with coaches, Scrum Masters, and managers responsible for the agile process from seven different companies, and collected survey data from 66 group-members from four companies (a total of eight different companies). The survey included an agile measurement tool and the one part of the Group Development Questionnaire. The results show that the practitioners define group developmental aspects as key factors to a successful agile transition. Also, the quantitative measurement of agility was significantly correlated to the group maturity measurement. We conclude that adding these psychological aspects to the description of the " agile team " could increase the understanding of agility and partly help define an "agile team." We propose that future work should develop specific guidelines for how software development teams at different maturity levels might adopt agile principles and practices differently.
Conference Paper
Full-text available
The project manager has been a ubiquitous feature of traditional software development projects. However, agile software development (ASD) methods which emphasize self-organizing teams and rapid response to change have done away with the project manager’s title. New job titles such as the scrum master and product owner have been introduced instead. It is unclear as to what extent the “project manager” is still encountered in the agile software industry. An online survey was posted out to agile special interest groups on popular social media platforms to discover the frequency of the job title “project manager” in agile projects. Analysis of the 97 responses from 31 countries around the world revealed that: a) the title of project manager is still widely used (67%); b) there is a correlation between the team size and presence of project manager such that there is a higher probability the project manager will be present in teams of 5-10 members and those over 25 members; and c) there is an inverse correlation between the co-location of a team and presence of project manager. Further research is needed to better understand why the project manager continues to be present on ASD projects and how their role may have changed.
Article
Full-text available
The objective of this report is to propose comprehensive guidelines for systematic literature reviews appropriate for software engineering researchers, including PhD students. A systematic literature review is a means of evaluating and interpreting all available research relevant to a particular research question, topic area, or phenomenon of interest. Systematic reviews aim to present a fair evaluation of a research topic by using a trustworthy, rigorous, and auditable methodology. The guidelines presented in this report were derived from three existing guidelines used by medical researchers, two books produced by researchers with social science backgrounds and discussions with researchers from other disciplines who are involved in evidence-based practice. The guidelines have been adapted to reflect the specific problems of software engineering research. The guidelines cover three phases of a systematic literature review: planning the review, conducting the review and reporting the review. They provide a relatively high level description. They do not consider the impact of the research questions on the review procedures, nor do they specify in detail the mechanisms needed to perform meta-analysis.
Article
The Agile manifesto focuses on the delivery of valuable software. In Lean, the principles emphasise value, where every activity that does not add value is seen as waste. Despite the strong focus on value, and that the primary critical success factor for software intensive product development lies in the value domain, no empirical study has investigated specifically what value is. This paper presents an empirical study that investigates how value is interpreted and prioritised, and how value is assured and measured. Data was collected through semi-structured interviews with 23 participants from 14 agile software development organisations. The contribution of this study is fourfold. First, it examines how value is perceived amongst agile software development organisations. Second, it compares the perceptions and priorities of the perceived values by domains and roles. Third, it includes an examination of what practices are used to achieve value in industry, and what hinders the achievement of value. Fourth, it characterises what measurements are used to assure, and evaluate value-creation activities.
Conference Paper
Context: Previous research investigated how to approach architecting in agile projects (e.g., in terms of processes and practices), but the role that architects play in Scrum is still not well understood. Objective: We aim at capturing scenarios of how architects (or those taking on architecture-related tasks) are involved in Scrum. Furthermore, we aim at identifying how those taking on the role of the architect interact with other roles in Scrum. Method: We conducted a multiple case study and interviews with practitioners from six Dutch software organizations. Results: We identified three generic scenarios of architects in Scrum (“internal architect”, “external architect”, “internal and external architects”). We found that how architects interact with other roles in Scrum heavily depends on the Product Owner role. Conclusions: Some of our results are not in line with recommended practices in the Scrum Guide. Our findings support those who take on architecture-related tasks in preparing for Scrum-like projects.
Conference Paper
We present a case study on scaling Scrum in a large globally distributed software development project at Nokia, a global telecommunications company. We discuss how the case project scaled Scrum while growing from two collocated Scrum teams to 20 teams located in four countries and employing a total of 170 persons. Moreover, we report scaling challenges the case project faced during this 2,5 year journey. We gathered data by 19 semi-structured interviews of project personnel from two sites, interviewees comprising different roles including managers, architects, product owners, developers and testers. The project was highly successful from the business point of view, as agile enabled fast response to customer requirements. However, the project faced significant challenges in scaling Scrum despite attempts at applying the Large-scale Scrum (LeSS) framework. The organization experimented with different ways of implementing scaling practices like implementing common sprint planning meetings, Scrum-of-Scrums meetings, common demos and common retrospectives, as well as scaling the Product Owner role. We conclude the paper by reflecting on the scaling approach used in the case organization in contrast to the LeSS framework.