FOCUS: DevOps: LESSONS LEARNED

Innovative I find myself more and more ex-

asperated with the great inflexible
sets of rules that many companies

Practices for pour into concrete and sanctify

as methods. … Use the prevailing
method only as a starting point

Knowledge
for tailoring.

—Tom DeMarco (1982)

Sharing in Large- AGILE METHODS EMERGED from

the inability of conventional (for
example, waterfall) methods to de-

Scale DevOps liver software to meet the needs of

a rapidly changing environment.
Initially, agile methods were consid-
ered to have a “home ground” where
Aymeric Hemon, ESSCA School of Management and University of Nantes they were best suited; namely, small
projects with colocated developers
Brian Fitzgerald, Lero and University of Limerick in noncritical domains. The home
Barbara Lyonnet, University of Nantes ground theory has been challenged
considerably during the past 15 years
Frantz Rowe, University of Nantes and SKEMA Business School
as researchers and practitioners tai-
lored the application of agile meth-
// Agile development methods and DevOps ods through new roles, ceremonies,
require adaptation during implementation to meet and artifacts to meet the needs of the
development context; for example,
the needs of a constantly changing software- in critical and regulated domains.
development environment. The emergence of In addition, a bottleneck emerged
due to a lack of alignment between the
knowledge-sharing practices for large-scale operations function, which coordinates
DevOps has not been the subject of much the software release, and development
function. Consequently, releases to cus-
research. Our in-depth case study, consisting
tomers took more time. To solve the
of 106 interviews at a multinational company problem, Debois1 advocated for more
operating in a DevOps-at-scale environment, collaboration between the develop-
ment and operations functions through
identified a number of innovative practices. // tighter integration, a rapprochement
called DevOps. The term comes from
the fusion of two words related to spe-
cific component activities: development
and operations.
While agile methods can achieve a
more frequent cadence of software de-
velopment and better alignment with
customer expectations, DevOps strives
for a continuous delivery of value
Digital Object Identifier 10.1109/MS.2019.2958900
through constant integration, delivery,
Date of current version: 16 April 2020 and deployment. DevOps is, hence, an

30 I E E E S O F T WA R E | PUBLISHED BY THE IEEE COMPUTER SO CIE T Y 0 74 0 -74 5 9 / 2 0 © 2 0 2 0 I E E E

Authorized licensed use limited to: UNIVERSIDAD VERACRUZANA. Downloaded on February 19,2023 at 01:07:05 UTC from IEEE Xplore. Restrictions apply.
 extension of agile2 to the entire soft-
ware-delivery pipeline, aiming to opti-
mize the lead time between code writing
and its use by end users in a real produc-
tion environment.
We consider large-scale DevOps as
we focus on the four DevOps pillars
(culture, automation, measurement,
and sharing) that involve a large
number of actors, systems, and inter-
dependencies, with more than two
teams working on the same project3
and applying continuous integration,
delivery, and deployment. Roles and
responsibilities do still matter in the
agile world, particularly when using
prescriptive methods, such as Scrum.
DevOps breaks silos and, therefore,
possibly blurs the lines (such as orga-
nizational and hierarchical) between
jobs, roles, collaborations, responsi-
bilities, skills, and practices. DevOps
potentially amplifies the ­b oundary
distortion when applied at a large
scale. In this article, we focus on inno-
vative practices for knowledge sharing
(KS), which is one of the four pillars,
and argue that these approaches are
more likely to emerge in large-scale
DevOps. A KS practice occurs when
an individual transfers what he or she
knows to another person.
When moving to large-scale agile,
the KS challenges and related suc-
cess criteria have been identified,4,5
which raises the issue of ensuring
and improving learning and KS prac-
tices. Ghobadi et al. identified barri-
ers6 and risks to effective KS in agile
teams. Risk perception is even higher
in DevOps than in agile.7 Conse-
quently, KS challenges are larger and
more complex since more points of
view come into consideration when
using large-scale DevOps. Managing
knowledge dependencies becomes
critical in a large-scale DevOps con-
text.8 Indeed, some individuals could
form a bottleneck to the knowledge
Authorized licensed use limited to: UNIVERSIDAD VERACRUZANA. Downloaded on February 19,2023 at 01:07:05 UTC from IEEE Xplore. Restrictions apply.
transfer when moving to large-scale
DevOps. Despite the need for inno-
vation and tailoring, as expressed by
DeMarco in the opening quote, new
KS practices for large-scale DevOps
have not been extensively studied. In
that respect, Nielsen et al. proposed
a DevOps KS framework9 and used
the combination, externalization,
socialization, and internalization di-
mensions to increase awareness of KS
modes within the organization. They
concluded that the size of the team
and company influences the move
toward continuous delivery and
DevOps. They showed that larger
companies need a more structured
plan when moving to DevOps to en-
sure K S a m o n g t h e i r I T t e a m s ,
while smaller organizations do not
need a similar strategy. Consequently,
moving to large-scale DevOps might
impact KS practices.
In sum, the following KS chal-
lenges in DevOps have been identi-
fied in the literature:
1. more intense cross-functional
collaboration between Dev
and Ops10,11
2. multiple environment incompat-
ibilities leading to specialized
teams12,13
3. the ability to self-organize14
4. a loss of global vision of a proj-
ect and application knowledge
due to automation7
5. the confinement of KS to hierar-
chical organizational structure
and red tape7
6. limited sharing when parts of
the development and operations
are outsourced.15
Moving from DevOps to large-
scale DevOps amplifies challenges
including coordination and collabora-
tion improvement, dependency man-
agement, knowledge development,
M AY/J U N E 2 0 2 0
and sharing. Three of the six KS chal-
lenges are particularly salient. First,
the ability to self-organize could be
affected by scaling up DevOps due
to a larger number of team members
covering a wider organizational pe-
rimeter. Second, notwithstanding a
higher level of automation at scale,
more frequent commits (releases) re-
quire manual coding adjustment,16
which needs a common coordination
mechanism and, hence, more intense
cross-functional collaboration. Third,
scaling DevOps could impact the KS
due to more friction with the organi-
zational structure and red tape.
Context
Our study was conducted in a mul-
tinational company (with more than
100,000 employees) that has been
practicing DevOps for eight years,
being one of the very early adopt-
ers of the approach. We followed
the case-study method of combining
interviews, observations, and docu-
mentation. To identify the KS prac-
tices implemented by project teams,
we made direct observations during
field visits, attended 20 meetings plus
an eight-hour DevOps coaching day,
and conducted semi-structured in-
terviews with 106 employees. The
teams included multiple functions as-
sociated with software development,
such as developers, project managers,
release engineers, user-experience
designers, the product owner (PO),
and architects.
For each project, three of the four
authors worked on a deep analysis.
First, we collected information re-
garding the agile methods and actual
practices supporting the KS inside
and outside of the teams and related
to the use of space (that is, a com-
mon work area), agile methodologies
(for instance, Scrum-of-Scrum meet-
ings and the daily stand-up), and
| I E E E S O F T WA R E 31
 FOCUS: DevOps: LESSONS LEARNED
collaborative tools enabling the KS
(such as Slack and Atlassian JIRA).
Second, we compared our findings
with a baseline reference (the 12th
“State of Agile Report”) to identify
potential innovative practices. We
studied specific adaptations of agile
practices and the development of KS
procedures that had emerged to suit
the contingencies of the development
environment. Third, we investigated
the literature, where we found prac-
tices that the company used and that
were not present in the baseline ref-
erence report.
Identifying innovative KS prac-
tices thus meant identifying those
that were the most advanced within
the 18 projects we investigated. They
were likely to be new to the firm, but
we do not claim that they are new
to the world. However, they help
address challenges when moving
toward large-scale DevOps. Six of
the projects practiced DevOps, and
innovative KS methods were found
in only two of the projects that
used large-scale DevOps. Project X
started eight years ago, operating in
DevOps mode from the beginning,
and Project Y matured to operate in
DevOps mode in 2016. Both were
advanced in DevOps and practiced
continuous delivery and deployment.
Project X involved 85 people or-
ganized in seven teams that were
colo c ate d exc ept for a n op era-
tions group a few miles away. The
teams were not necessarily the same
size and did not have to be com-
posed the same way. Project mem-
bers worked in DevOps and mainly
used a hybrid agile method derived
from Scrum, Kanban, and XP. They
scaled up their agile method, first
with large-scale Scrum (LeSS). One
year later, they moved to the scaled
agile framework (SAFe). Project Y
involved 65 people divided into five
32 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E
Authorized licensed use limited to: UNIVERSIDAD VERACRUZANA. Downloaded on February 19,2023 at 01:07:05 UTC from IEEE Xplore. Restrictions apply.
teams distributed across four geo-
graphical sites and two remote coun-
tries, which were distant at many
levels, according to Ghemawat’s cul-
tural, administrative, geographic,
and economic model.17 Development
activities were essentially based in
the same country, while the opera-
tions were mostly in another. Proj-
ect members chiefly used Scrum and
Scrumban and scaled up with LeSS-
adopting practices such as Scrum
of Scrum. They implemented an in-
ternational, cross-functional daily
DevOps meeting.
Innovative Practices
for KS
We propose t h re e levels of K S
practices based on three orders of
DevOps maturity (agile, continuous
integration, and continuous deliv-
ery) during the transition from agile
to large-scale DevOps (see Table 1).
At the first DevOps maturity level,
agile teams do not cross between
functional silos, and DevOps is non-
existent. At the second level, teams
practice continuous integration;
hence, across silos. At the third level,
teams practice continuous delivery
and/or deployment. We identify four
practices that emerged through tai-
loring the method and address the
needs of DevOps in a large-scale de-
velopment context: cross-functional
dynamic role rotation (DRR), tech-
nical Thursdays (T Ts), heads-up
grooming and planning (H UGP),
a nd t he ci rcle. We d is c uss each
in turn.
Cross-Functional DRR
A significant involvement of certain
functions (project Manager, PO,
and Scrum master) was highlighted
during daily stand-up meetings. In
some projects, this involvement was
even more pronounced as several
| @ I E E E S O F T WA R E
of the functions were performed by
the same individuals. To overcome
this difficulty, one of the large proj-
ect teams at an advanced level of
DevOps maturity proposed a new
practice that involved a cross-func-
tional DRR and, therefore, associ-
ated responsibilities. Job rotation in
the software-development context
was identified in a previous study18
as a means of addressing organiza-
tional concerns and stimulating in-
novation. The instantiation of the
role rotation in the cross-functional
DRR practice in our case enabled
large-scale learning and KS since
all team members were able to per-
form several roles and become more
knowledgeable.
DRR is usually limited to a spe-
cific area, such as the development
or operations team. A developer can
become a Scrum master for a week
or sprint, then go back to his or her
position. In our case, the DRR was
cross functional, and, for instance,
production engineers (operations)
performed code reviews. All mem-
bers from both sides, development
and operations, were able to meet
and work together alternatively.
Cross-functional DRR ensured that
the “heavy lifting” workload did not
repeatedly fall on the same individu-
als. It also fulfilled the succession-
planning role: Team compositions
became more flexible since individu-
als could be swapped out without
causing perturbation to the extent
that the groups could not function.
TTs
Another practice that emerged in the
context of technical KS was the TTs.
Those “tech-talk” events took place
for half a day every two weeks. The
goal was to disseminate technical
knowledge, particularly in relation
to technologies, tools, skills, and
 Table 1. Knowledge-sharing practices during the transition to large-scale DevOps
(after Hemon et al.15).
Maturity level Characteristic of KS practice Path to large-scale DevOps

Level 1: Agile There is a more frequent KS due to the iterative process and Large-scale agile methods are used (for example, SAFe and
more frequent releases. LeSS).
There is better communication and sharing between the DevOps is not achieved because silos still exist.
customer and developers.
The KS is limited to specific silos (mostly development and, to
There is limited sharing among the team and little common a lower level, business).
culture with the PO.

Level 2: Continuous Through the performance of various tests (unit and Some large-scale frameworks are used and meet their first
integration nonregression), the KS is synchronized with the code limits (such as the rigidity of SAFe) along the entire pipeline
development.
The alignment of the operations function with the
Task automation is achieved as far as possible, with development function is achieved.
knowledge transfer.
Some DevOps pillars, such as sharing, are partially reached.
There is partial KS. Developers need quick feedback.
The KS is applied across silos between development and
A partial common vocabulary and culture boosts the KS. operations.
There are some common tools fostering the KS.
There are different metrics and measurement systems
limiting the KS.

Level 3: Continuous Integration tests with other components, end-to-end Large-scale frameworks are particularly challenged on the KS
delivery tests, performance tests, and user-acceptance tests are along the entire pipeline.
codesigned, performed, and, preferably, automated by
There is a higher degree of alignment, sharing, and
operations in conjunction with the development function.
automation.
There is learning and extensive KS.
There are full DevOps practices based on the four pillars, with
There is a shared backlog. a high level of KS across teams and beyond.
There is a shared work system.
There are shared metrics and measurement tools.
Innovative KS practices appear.

other topics that would typically be
championed and led by an individual
team member. The TTs could take
the form of workshops on new top-
ics (for example, containerization,
automated configuration manage-
ment, and infrastructure as code),
related tooling (Puppet and Docker),
fresh initiatives (A/B experimenta-
tion), challenges (hackathons), and
games (Code Wars). A playful spirit
and gamification were often strong
components, which had the extra
benefit of boosting morale and the
team spirit.
The difficulty with the tech talks
concerns the fact that the KS could
be limited to a group, person, or
community of practice (CoP). There-
fore, inter-team KS at a large scale
could be an issue for agile software-
development organizations.19 The
originality of the TT events is that
they go beyond CoPs and the risk
of developing knowledge on a tribal
basis. The TTs are fully cross func-
tional both vertically and horizon-
tally across silos. One could have
supposed that the Code War game
was only intended for developers.
However, POs, architects, designers,
developers, testers, and operations
engineers were invited. Participants
played for teams other than their
usual one. Teams had to be mixed
and represent as many trades as pos-
sible at the organization level. While
the hackathons were frequented
mostly by developers, the game fos-
tered large-scale KS across the de-
velopment and operations areas and
significantly helped the realization of
projects; for instance, the implemen-
tation of Docker containers for a de-
ployment system that was proposed

M AY/J U N E 2 0 2 0 | I E E E S O F T WA R E 33
Authorized licensed use limited to: UNIVERSIDAD VERACRUZANA. Downloaded on February 19,2023 at 01:07:05 UTC from IEEE Xplore. Restrictions apply.
 FOCUS: DevOps: LESSONS LEARNED
by operations and accepted by devel-
opment outside of the project teams.
HUGP
Backlog grooming, or backlog refine-
ment, can be understood in differ-
ent ways. In the projects we studied,
backlog grooming consisted of short-
term user-story costing. However, in
a large project where the team used
DevOps, one PO initiated a prac-
tice to support backlog grooming
and sprint planning, which is labeled
HUGP. This practice is similar to
rolling look-ahead planning (RLP) in
the sense that there is a high-level re-
lease plan, and sprints are gradually
refined as they start. In the HUGP
ceremony, the PO no longer performs
any immediate user-story estima-
tion with the team. Instead, the PO
provides the team with broad infor-
mation on the subject. The idea is to
give the team a visualization of the
work to come. The meeting is short,
somewhere between 10 and 30 min.
Subsequently, the sprint-planning
meeting takes place and lasts two
hours during which user stories are
presented, estimated, and broken
down into tasks. However, the effect
of the previously held HUGP practice
is very noticeable. The PO describes
it well: “The team is more confident
and self-assured when it comes to
story-point estimation. There is less
error or difference. The team mem-
bers have had time to go through the
code and figure out if they had any
doubts. They discuss it among them-
selves, around a foosball game.”
We consider HUGP as an ex-
ten sion of R L P. B ot h adopt a
just-in-time approach to up-front
planning; both foster discussion
within teams for the identification
and estimation of product backlog
components. However, we suggest
that HUGP differs because it is more
34 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E
Authorized licensed use limited to: UNIVERSIDAD VERACRUZANA. Downloaded on February 19,2023 at 01:07:05 UTC from IEEE Xplore. Restrictions apply.
than a discussion about user-story
estimation. H UGP strongly pro-
motes KS, pushing team members
to delve into the code, learn, test
something new, enrich each other,
and even consult operations engi-
neers on specific topics (such as the
production environment and deploy-
ment package). Before the discus-
sion, there is a transfer of knowledge
between members that helps them
to surface their arguments for bet-
ter estimates. The benefits of such
KS practices are multiple at the
DevOps-team level, then across the
project: time-saving when estimating
user stories, clearer and more accu-
rate estimations, and engendering a
greater sense of development-team
empowerment.
The Circle
One issue with sprint retrospectives is
that, if they are done at all, they are
often combined with the sprint-review
ceremony. Also, they are confined to a
single team, thereby limiting the KS19
and minimizing its opportunity to play
a role in achieving continuous improve-
ment. Consequently, agile and DevOps
are not fostered at a large-scale.
The team met difficulties with
retrospectives, primarily because the
forums were quite complex to orga-
nize with 85 people. The members
decided to set up joint-reflection cer-
emonies, which were known as the
circle. The practice was based on a
discussion among a group of people
that represented all of the jobs and
roles across multiple project teams,
including managers, POs, architects,
developers, testers, and operations
engineers. Participation was volun-
tary. The circle was a forum for the
real exchange of knowledge across
team functions. It was composed of
approximately 20 people who met
twice a month. The circle practice
| @ I E E E S O F T WA R E
fulfilled the role of the sprint retro-
spective at a large scale by stimulat-
ing and animating reflection on the
daily functioning of the teams and
organization, and it had the added
advantage of consisting of multiple
groups. This reflection was particu-
larly useful for implementing the
other innovative practices mentioned
here. New practices do not always
get everybody’s support; therefore,
their implementation must be the
subject of open discussion.
When the shared knowledge ap-
peared to be valuable, such as during
Code Wars, it was adopted and dis-
seminated across teams. In that way,
team members limited the problem
of missing valuable knowledge or
not capitalizing on it. The circle en-
abled such discussion to take place
and ensured that innovative prac-
tices could evolve, much in the spirit
of the quote by DeMarco. The prac-
tice typically responded to the KS
challenge when large-scale DevOps
was applied (see Table 1) and went
beyond DevOps boundaries by also
integrating the business domain.
Resolution of Major KS Challenges
Different innovative practices have
met the KS challenges in the context
of large-scale DevOps. In Table 2, we
summarize the main difficulties and
impacts that each of them generates.
Large-Scale DevOps and
Innovative KS Practices
While the Scrum method was the
backdrop for the projects we sur-
veyed, reality is much more complex
in terms of overlapping and comple-
mentary practices.20 Thus, we were
able to identify the development of
innovative KS practices only in the
most advanced projects (see Table 1).
This raises the question of how large-
scale DevOps enables innovation.
 Table 2. The major challenges and impacts of innovative practices.
Innovative Major challenges
Impact
practice addressed

Cross- • Intense cross-functional The breaking of knowledge dependencies is enabled15 because information is not held by any
functional DRR collaborations individual. However, this obliges team members to communicate to carry out their roles effectively.
• Team self-organization When team members rotate, they can take on responsibilities, develop skills, and acquire
challenges knowledge. This fosters the team’s autonomy.

TTs • More intense cross-
functional collaboration
• Complex environments
and specialized teams
Team participants (representing almost every area, such as business, development, quality, and so
forth) can discover and learn new approaches without any consideration of belonging to a specific
functional silo or the position held. This is how operations teams bypassed the organizational
culture related to training, and operations made development teams discover Rancher, an open-
source tool to deploy and manage containers in production environments.
Teams are helped to avoid over-specializing through fostering the KS and increasing the number of
individuals who understand the multiple environmental complexities and incompatibilities.

HUGP • Confinement of the KS
due to the hierarchical and
organizational structure
and red tape.
The KS is facilitated at scale, avoiding additional red tape and reducing the burden of agile
processes and organizational rules and procedures.
By practicing HUGP, the manager gives the team members the possibility to obtain central
information that they would not have had, while respecting the processes of the agile method and
organization. Team members can, therefore, use information in advance, which enables them to
enrich and transform the information into knowledge. This new knowledge is shared, helping team
members make more realistic and accurate decisions during their mission.

The circle • Capability to self-organize
• Multiple environment
incompatibilities leading
teams’ specialization.
The circulation of knowledge is facilitated because the circle is fully cross-functional, with
representatives from all of the jobs linked to the project and, at the same time, because it consists
of only 20 individuals representing larger teams (85 people).
This fosters the KS at a large scale, decision making, and, consequently, teams’ autonomy.

Our hypothesis is that these innova-
tion practices are the result of further
continuous improvement facilitated
by stronger levels of self-organization
in DevOps teams acting on a broader
mandate. As mentioned, these KS
practices were observed in large-scale
projects that commenced eight years
ago, one of them operating in DevOps
mode from the beginning, and the
other maturing to eventually oper-
ate in DevOps mode. The other four
DevOps projects were clearly shar-
ing knowledge (for instance, com-
mon project management, processes,
and tools, such as shared continuous
integration and automated deploy-
ment tools and the co-construction
of deliverables), and they used basic
practices. However, the KS was less
developed than it was for the other
two projects. This may be because the
four projects had less time to evolve
the practice and because three of
them were smaller initiatives.
Interestingly, in this large company,
the innovative KS practices were not
shared across all projects, even at the
same software-process maturity level.
The creative KS practices addressed
specific challenges that projects faced
and helped the organization to par-
tially or fully resolve initial problems.
Large-scale DevOps may require more
KS practices since additional con-
straints have to be integrated between
the business, development, and opera-
tions functions. Such KS methods suit
projects operating at a large-scale and
in DevOps because those joint condi-
tions multiply the coordination issues
and risks related to a lack of compe-
tencies.15 Moreover, we believe that
project autonomy, or self-organization,
and continuous improvement during a
long period of time are critical influ-
encing factors. Thus, in the teams that
developed KS practices:
• Projects were more advanced in
agile and tended toward large-
scale DevOps.
• The larger the project teams were
the more they self-organized and

M AY/J U N E 2 0 2 0 | I E E E S O F T WA R E 35
Authorized licensed use limited to: UNIVERSIDAD VERACRUZANA. Downloaded on February 19,2023 at 01:07:05 UTC from IEEE Xplore. Restrictions apply.
 FOCUS: DEVOPS: LESSONS LEARNED
ABOUT THE AUTHORS
AYMERIC HEMON is an assistant profes-
sor in management information systems
(ISs) at the ESSCA School of Management,
Angers, France, and a researcher at the
Laboratoire d’Economie et de Management
de Nantes Atlantique, University of Nantes,
France. He is also a senior lecturer in
software engineering at the Mines Telecom
Institute, Paris, France. His research
focuses on IS-enabled organizational
transformation, particularly agile methods
and DevOps. Hemon received a Ph.D. in
management information systems from
the University of Nantes, France, in 2018.
Contact him at aymeric.hemon-hildgen@
essca.fr.
BRIAN FITZGERALD is the director of
Lero, a software research center at the
University of Limerick, Ireland. He also
holds an endowed professorship, the
Krehbiel Chair in Innovation in Business and
Technology, at the University of Limerick.
Fitzgerald received a Ph.D. in computer
science from the University of London in
1997. His publications include 15 books
and more than 150 peer-reviewed articles
in international journals and conferences
related to the information-systems and
software-engineering fields. Contact him
at brian.fitzgerald@ul.ie.
used their relative autonomy to
continuously improve throughout
a long period.
• Project teams were more likely
to develop innovative KS
C learly, the emergence and
implementation of these in-
novative KS practices is
an outcome of multiple idiosyn-
cratic conditions, and we would
practices among their mem- need data beyond the 18 projects
bers and across functional that we studied to reach any firm
boundaries. conclusion. However, observations
36 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E
Authorized licensed use limited to: UNIVERSIDAD VERACRUZANA. Downloaded on February 19,2023 at 01:07:05 UTC from IEEE Xplore. Restrictions apply.
BARBARA LYONNET is an associate
professor of management sciences at the
University of Nantes, France, where she
is also a researcher in the Laboratoire
d’Economie et de Management de Nantes
Atlantique. Lyonnet received a Ph.D. in
industrial engineering from the University
of Savoie Mont-Blanc, France, in 2010. She
has published in the field of information
systems and quality and supply-chain man-
agement, including several books, such as
Lean Management. Contact her at barbara.
lyonnet@univ-nantes.fr.
FRANTZ ROWE is a professor at the Uni-
versity of Nantes, France, where he is also
a researcher at the Laboratoire d’Economie
et de Management de Nantes Atlantique.
He is a professor at the SKEMA Business
School, Sophia Antipolis, France; former
chief information officer of the University
of Nantes; and professor at Telecom Paris.
Rowe received a Ph.D. in the management
of information systems from the University
of Paris X, Nanterre, France, in 1991. He
is an Association for Information Systems
fellow and editor emeritus of the European
Journal of Information Systems. He directs
the research program on DevOps at the
University of Nantes. Contact him at frantz.
rowe@univ-nantes.fr.
in our ongoing research at other
firms tend to support a large-scale
DevOps effect and continuous-
improvement result related to self-
organization in the generation of
in novative K S prac tices. Using
DevOps at a large-scale amplifies
the KS challenge as well as related
| @ I E E E S O F T WA R E
 solutions through the development
of innovative practices. Such effects
are not fixed since the implementa-
tion of these practices is not rigid,
and they are subject to continu-
ous adjustment to avoid deteriora-
tion and rigidity or, indeed, being
poured into concrete.
References
1. P. Debois, “DevOps: A software
revolution in the making,” J. Inform.
Technol. Manage., vol. 24, no. 8,
pp. 3–39, Aug. 2011.
2. M. Virmani, “Understanding
DevOps & bridging the gap from
continuous integration to continu-
ous delivery,” in Proc. 5th Int. Conf.
Innovative Computing Technology
(INTECH), 2015, pp. 78–82. doi:
10.1109/INTECH.2015.7173368.
3. T. Dingsøyr, T. E. Fægri, and J.
Itkonen, “What is large in large-
scale? A taxonomy of scale for
agile software development,” in
Proc. Int. Conf. Product-Focused
Software Process Improvement
(PROFES), 2014, pp. 273–276. doi:
10.1007/978-3-319-13835-0_20.
4. T. Dingsøyr and N. B. Moe, “Re-
search challenges in large-scale
agile software development,” ACM
SIGSOFT Softw. Eng. Notes, vol.
38, no. 5, pp. 38–39, Sept. 2013. doi:
10.1145/2507288.2507322.
5. D. Smite, N. B. Moe, G. Levinta, and
M. Floryan, “Spotify guilds: How
to succeed with knowledge sharing
in large-scale agile organizations,”
IEEE Softw., vol. 36, no. 2, pp. 51–
57, Mar.–Apr. 2019. doi: 10.1109/
MS.2018.2886178.
6. S. Ghobadi and L. Mathiassen,
“Perceived barriers to effective
knowledge sharing in agile software
teams,” Inform. Syst. J., vol. 26,
no. 2, pp. 95–125, Dec. 2014.
doi: 10.1111/isj.12053.
Authorized licensed use limited to: UNIVERSIDAD VERACRUZANA. Downloaded on February 19,2023 at 01:07:05 UTC from IEEE Xplore. Restrictions apply.
7. A. Hemon, L. Monnier-Senicourt, and
F. Rowe, “Job satisfaction factors and
risks perception: An embedded case
study of DevOps and agile teams,”
in Proc. 39th Int. Conf. Information
Systems (ICIS), San Francisco, 2018.
8. V. Stray, N. B. Moe, and A. Aasheim,
“Dependency management in large-
scale agile: A case study of DevOps
teams,” in Proc. 52nd Hawaii Int.
Conf. System Sciences (HICSS),
Grand Wailea, HA, 2019. doi:
10.24251/HICSS.2019.840.
9. P. A. Nielsen, T. J. Winkler, and J.
Nørbjerg, “Closing the IT develop-
ment-operations gap: The DevOps
knowledge sharing framework,”
in Proc. 16th Int. Conf. Perspec-
tives Business Informatics Research
(BIR), Copenhagen, Denmark, 2017,
vol. 1898, chap. 5, pp. 1–15.
10. W. Gottesheim, “Challenges, ben-
efits and best practices of per-
formance focused DevOps,” in
Proc. 4th Int. Workshop Large-
Scale Testing, 2015, pp. 3–3. doi:
10.1145/2693182.2693187.
11. A. Wiedemann, “A new form of col-
laboration in IT teams—Exploring
the DevOps phenomenon,” in Proc.
21st PACIS Asia Pacific Conference
Information Systems, 2017. pp. 1–12.
[Online]. Available: http://aisel.aisnet
.org/pacis2017/82
12. L. E. Lwakatare et al., “Towards
DevOps in the embedded systems
domain: Why is it so hard?” in Proc.
2016 49th Hawaii Int. Conf. System
Sciences (HICSS), pp. 5437–5446.
doi: 10.1109/HICSS.2016.671.
13. J. Smeds, K. Nybom, and I. Porres,
“DevOps: A definition and perceived
adoption impediments,” in Proc.
Int. Conf. Agile Software Devel-
opment, 2015, pp. 166–177. doi:
10.1007/978-3-319-18612-2_14.
14. A. Wiedemann, “IT gover-
nance mechanisms for DevOps
M AY/J U N E 2 0 2 0
teams—How incumbent companies
achieve competitive advantages,”
in Proc. 51st Hawaii Int. Conf.
System Sciences (HICSS), 2018,
pp. 4931–4940. doi: 10.24251/
HICSS.2018.617.
15. A. Hemon, B. Lyonnet, F. Rowe,
and B. Fitzgerald, “Conceptualizing
the transition from agile to DevOps:
A maturity model for a smarter IS
function,” in Proc. Int. Working
Conf. Transfer and Diffusion IT
(TDIT), 2018, pp. 209–223. doi:
10.1007/978-3-030-04315-5_15.
16. Y. Zhao, A. Serebrenik, Y. Zhou,
V. Filkov, and B. Vasilescu, “The
impact of continuous integration
on other software development
practices: A large-scale empiri-
cal study,” in Proc. 2017 32nd
IEEE/ACM Int. Conf. Auto-
mated Software Engineering
(ASE), pp. 60 –71. doi: 10.1109/
ASE.2017.8115619.
17. P. Ghemawat, “Distance still mat-
ters,” Harv. Bus. Rev., vol. 79, no. 8,
pp. 137–147, Sept. 2001.
18. T. E. Fægri, T. Dybå, and T. Ding-
søyr, “Introducing knowledge
redundancy practice in software
development: Experiences with job
rotation in support work,” Inf. Softw.
Technol., vol. 52, no. 10, pp. 1118–
1132, Oct. 2010. doi: 10.1016/j.
infsof.2010.06.002.
19. V. Santos, A. Goldman, and C.
R. De Souza, “Fostering effective
inter-team knowledge sharing in
agile software development,” Em-
pir. Softw. Eng., vol. 20, no. 4, pp.
1006–1051, Aug. 2015. doi: 10.1007/
s10664-014-9307-y.
20. B. Fitzgerald, G. Hartnett, and K.
Conboy, “Customising agile methods
to software practices at Intel Shan-
non,” Eur. J. Inf. Syst., vol. 15, no.
2, pp. 200–213, Jan. 2006. doi:
10.1057/palgrave.ejis.3000605.
| I E E E S O F T WA R E 37