Information and Software Technology 56 (2014) 1556–1577

Contents lists available at ScienceDirect

Information and Software Technology

journal homepage: www.elsevier.com/locate/infsof

Communities of practice in a large distributed agile software

development organization – Case Ericsson
Maria Paasivaara ⇑, Casper Lassenius
Aalto University, Department of Computer Science and Engineering, POB 15400, 00076 Aalto, Finland

a r t i c l e i n f o a b s t r a c t

Article history: Context: Communities of practice—groups of experts who share a common interest or topic and collec-
Received 22 April 2013 tively want to deepen their knowledge—can be an important part of a successful lean and agile adoption
Received in revised form 28 May 2014 in particular in large organizations.
Accepted 9 June 2014
Objective: In this paper, we present a study on how a large organization within Ericsson with 400 persons
Available online 26 June 2014
in 40 Scrum teams at three sites adopted the use of Communities of Practice (CoP) as part of their trans-
formation from a traditional plan-driven organization to lean and agile.
Keywords:
Methods: We collected data by 52 semi-structured interviews on two sites, and longitudinal non-partic-
Communities of practice
Large-scale agile software development
ipant observation of the transformation during over 20 site visits over a period of two years.
Scaling agile Results: The organization had over 20 CoPs, gathering weekly, bi-weekly or on a need basis. CoPs had sev-
eral purposes including knowledge sharing and learning, coordination, technical work, and organizational
development. Examples of CoPs include Feature Coordination CoPs to coordinate between teams working
on the same feature, a Coaching CoP to discuss agile implementation challenges and successes and to help
lead the organizational continuous improvement, an end-to-end CoP to remove bottlenecks from the
flow, and Developers CoPs to share good development practices. Success factors of well-functioning CoPs
include having a good topic, passionate leader, proper agenda, decision making authority, open commu-
nity, supporting tools, suitable rhythm, and cross-site participation when needed. Organizational support
include creating a supportive atmosphere and providing a suitable infrastructure for CoPs.
Conclusions: In the case organization, CoPs were initially used to support the agile transformation, and as
part of the distributed Scrum implementation. As the transformation progressed, the CoPs also took on
the role of supporting continuous organizational improvements. CoPs became a central mechanism
behind the success of the large-scale agile implementation in the case organization that helped mitigate
some of the most pressing problems of the agile transformation.
Ó 2014 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND
license (http://creativecommons.org/licenses/by-nc-nd/3.0/).

1. Introduction critical systems with highly volatile requirements in an organiza-

tion with a high degree of acceptance of uncertainty [5].
Agile methods, and in particular Scrum [1], have become main- However, agile development is increasingly adopted in large
stream in contemporary software development in both small and organizations running big software development projects employ-
large organizations [2]. Based upon iterative and incremental soft- ing multiple teams distributed to several geographical locations
ware development [3], agile methods were originally created to [2,6]. Adopting agile methods in this context introduces new chal-
support small teams of highly experienced developers working in lenges related to scaling, such as inter-team coordination, effective
a single team room [4]. Consequently, they rely heavily on face- knowledge sharing between the teams, design without a defined
to-face communication, limiting the maximum practical size of architecture or properly defined requirements, as well as all the
the development team [4]. challenges of distributed projects [7].
The ‘‘home ground’’ for agile software development practices is Despite these additional hurdles, companies report having suc-
small teams of highly experienced people building small, non cessfully applied agile practices in large projects [8,9]. While a few
case studies and experience reports on adopting agile methods in
⇑ Corresponding author. projects involving several teams and several geographical locations
E-mail addresses: maria.paasivaara@aalto.fi (M. Paasivaara), casper.lassenius@ exist, most reports are from small projects involving only a few
aalto.fi (C. Lassenius). teams, often involving altogether less than thirty developers.

http://dx.doi.org/10.1016/j.infsof.2014.06.008
0950-5849/Ó 2014 The Authors. Published by Elsevier B.V.
This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/).
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1557

While practitioner literature, mostly authored by consultants, Table 1 compares communities of practice to other types of groups
contains advice on scaling agile development to larger contexts, [13].
see, e.g. [10,7], academic studies providing evidence on scaling Communities of Practice can take on different roles in an orga-
agile is still scarce [11]. In particular, there is little evidence on nization, and the roles can evolve over time. For example, CoPs
which scaling practices actually provide value, under what circum- have been found to be useful when an organization changes from
stances, and how to successfully introduce them. a functional structure to one based on product lines or projects.
One of the practices recommended by the consultants, is intro- In such situations, CoPs can help mitigate problems, for example
ducing Communities of Practice (CoP) to help with knowledge by providing fora for functional experts who used to work together,
sharing, organizational and process development, and coordination but in the new organization are scattered around in different
[10]. While Communities of Practice have been described and used product lines, to meet and continue to deepen their functional
widely in other contexts, see e.g. [12,13], their use in the context of expertise.
professional software development, and in particular in scaling In general, communities of practice can provide a wide range of
agile development, has received little attention in the research both long-term and short term benefits to both the organization (s)
literature. in which they function, and to the members of the community
Another significant issue that large software development orga- [13,17]. Benefits to the organization include helping to drive strat-
nizations have to deal with when adopting agile methods is how to egy, starting new lines of business, providing an arena for problem
handle the organizational transformation to agile [14,15]. Large solving, transferring best practices, developing professional skills,
organizations often have institutionalized processes and organiza- and increasing the retention of talent [16]. Benefits to the members
tional structures that provide a poor fit with agile development. include help with challenges, being better able to contribute to
Thus, in addition to understanding what a good end state should one’s team, fun, enhanced professional reputation, and a strong
look like, managing the transformation from the starting state to sense of professional identity [13].
a successfully working agile implementation can provide signifi- For an organization interested in gaining benefits from Commu-
cant challenges. nities of Practice, a central question becomes how to build and sup-
In this paper we help mitigate the research gap on the usage of port them. Wenger suggests ‘‘shepherding’’ rather than creating
Communities of Practice in scaling agile development by present- them, and present seven principles for cultivating CoPs, listed
ing the motivation, development, and use of Communities of Prac- Table 2.
tice (CoPs) in a large-scale agile software development The relationship between the formal organization and the com-
organization at the telecommunications infrastructure provider munities of practice can vary. Wenger [13] lists five relationship
Ericsson. types: the community of practice can be unrecognized, bootlegged,
The paper is structured as follows: Section 2 provides an over- legitimized, supported or institutionalized. These relationship lev-
view of related work, Section 3 describes the case background, els differ in the amount of organizational involvement in, expecta-
research goals and methods, Section 4 presents our results, and tions of, and support for the communities of practice.
finally Section 5 discusses the results and concludes the paper. While communities grow, evolve and die according to their
individual needs, literature identified five stages of development
that they go through: potential, coalescing, maturing, stewardship,
2. Related work
and transformation.
In the potential stage there is not yet any community, rather a
In this section, we discuss related work on communities of prac-
set of interested people that start networking around a topic of
tice. While the importance of communities is widely acknowl-
joint interest. Key issues that the network needs to deal with at this
edged, e.g. in open-source development, in this paper we do not
stage to evolve into a real community of practice are finding
discuss communities in general, but focus on organizational com-
enough common ground between members to help them see the
munities of practice. More specifically, we are interested in the
value of connecting, sharing knowledge and solving problems
use of communities of practice in professional software develop-
together. At this stage, having an active and passionate community
ment organizations, in particular those adopting large-scale agile
coordinator is important.
development. This focus is also reflected in our review of the
When entering the coalescing stage, the community knows
literature.
what exists in the organization with respect to its domain, and
In this literature review, we first discuss the definition, cultiva-
the community is officially launched and community events are
tion and success factors for communities of practice in general.
arranged. At this stage, coordinators are still crucial to the success
Second, we discuss the role of communities of practice in software
of the CoP. The main challenge is to incubate and deliver immedi-
engineering.
ate value to the members and the organization.
At the maturing stage, the community has delivered immediate
2.1. Communities of practice value, proving its worth, and the focus shifts to clarifying the focus,
role and boundaries of the CoP.
A community of practice, is a group of people who share a con- The fourth stage, stewardship, is mainly concerned with main-
cern, a set of problems, or a passion about a topic, and who deepen taining momentum and keep the CoP going. At the final stage,
their knowledge and expertise in this area by interacting on an ongo- transformation, the community ceases to exist, either by fading
ing basis [13]. Communities of practice have been applied in a wide away, or by turning into some other structure, such as a social club;
variety of industries and contexts [12,13]. or become institutionalized, e.g. as a department.
Communities of practice have three important characteristics
that sets them apart from other communities: a domain, commu-
nity, and practice. The domain defines the area of interest in which 2.2. Communities of practice in software engineering
the members collaborate to share and create knowledge. The com-
munity aspect means that members actively engage in joint activ- In software engineering, and in particular when scaling agile
ities, form relationships with each other, and share information. software development, CoPs have been proposed as a possible
The practice aspect means that they develop a shared set of solution for functional learning, and knowledge sharing between
resources for addressing problems in their domain of interest. organizationally separate individuals with similar roles. Examples
1558 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

Table 1
Communities of practice vs. other organizational groups [16].

Purpose Who belongs? What holds it together? How long does it last?
Community of Develop member capabilities, build and Members who select Passion, commitment, identification As long as there is interest
practice exchange knowledge themselves with group expertise
Formal work To deliver a product or service Everyone who reports to the Job requirements, common goals Until the next
group group’s manager reorganization
Project team To accomplish a specific task Employees assigned by senior Project milestones and goals Until project completed
management
Informal Collect and pass on business information Friends and business Mutual needs As long as people have a
network acquaintances reason to connect

Table 2
Principles for cultivating communities of practice [13].

CoP cultivation principle Explanation

1. Design for evolution Expect the community to grow and evolve on its own
2. Open a dialog between inside and outside Help the community members understand what the community could achieve
perspectives
3. Invite different levels of participation Allow for different activity levels and motivations of participant, e.g. coordinators, core, active and peripheral
members, as well as external interest groups
4. Develop both public and private Both ‘‘formal’’ meetings, as well as one-on-one networking is needed
community spaces
5. Focus on value Encourage members to be explicit about the value of the community; let value emerge, don’t try to design it by force
6. Combine familiarity and excitement Have a ‘‘routine’’ program, but also include novel experiences, e.g. invited speakers
7. Create a rhythm for the community Find a suitable rhythm for the regular meetings

of these include a testing CoP for software testing, and a Scrum a large and complex systems product—a node that handles a spe-
master CoP [10]. cific type of traffic in telecommunications networks. The develop-
Empirical studies of CoPs in the software engineering literature ment involved three global sites: Finland, Hungary and the US, and
are scarce. One study [18] describes how a small Norwegian soft- ca 400 persons in approximately 40 Scrum teams. The product had
ware company used CoPs to facilitate learning. When adopting originally been developed in Finland, where also product manage-
agile development, Nokia reportedly used a CoP-like approach to ment and product development responsibility was located.
solve inter-team issues, and suggests that CoPs could be valuable Hungary had collaborated with Finland on the product since
to organizations when adopting agile in the large [19]. IBM Global 2006, whereas the US site was a recent addition to the program
Services report on their experiences with over 60 CoPs, and present after an acquisition of a US company in 2011.
a development model with seven stages: potential, building, The development of the product started over ten years ago, and
engaged, active and adaptive [20]. at the time of the study it was used by over 300 operators all over
Perhaps not surprisingly, software engineering researchers have the world. The product is still in active development. The organiza-
developed tools for supporting CoPs. For example, Chau and Maur- tion had used a traditional waterfall-type software process until
er [21] presents a set of tools for supporting inter-team coordina- the end of 2009, when the whole organization started what they
tion and knowledge sharing. However, they do not present any called a ‘‘Lean and Agile transformation’’, during which Lean
validation in a real organization, and wisely recognize the cultural principles [23] and Scrum [24,25] were taken into use.
change needed in a potential user organization as a major hurdle to Ericsson Finland has been involved in R&D since it was
be overcome for the tool to be successful. founded in the early 1970s. During the 80s and 90s, Ericsson
We found it interesting that despite the fact that the practi- developed a strong plan-based project culture, and became excel-
tioner literature, e.g. [10], suggests the use of CoPs, we were not lent in running waterfall-type projects. The projects delivered
able to find any in-depth study of the use of communities of prac- products close to the planned schedules, and product quality
tice in large-scale agile software engineering. In particular, the was high. However, in the late 2000s, Ericsson felt that despite
software engineering literature lacked insights into how to imple- the success of their waterfall-type development and high product
ment CoPs, how to use them, and what their practical value is. Such quality, they would need to be even better in the future to
knowledge would help both managers and practitioners in organi- compete in the modern telecom world, in which competition is
zations to better understand when and how to implement CoPs, cut-throat. Especially, shortening the lead times and being able
and avoid making the same mistakes and run into the same chal- to respond fast to the customer needs, while maintaining the high
lenges as other organizations already have done before them. quality, would be crucial.
As this kind of basic actionable knowledge is missing in the soft- According to our background interview of unit management,
ware engineering literature, we think that even a single case study the product development unit experienced four problems that
as presented in this paper can provide value both to organizations, motivated the change from a waterfall process to agile and lean
as well as to the scientific community. development. First, the plan-driven process required up-front
scoping and investment decisions for the whole product release,
3. Research design leading to large scopes and very long lead times, typically up to
two years from requirement specification to delivery. Second,
3.1. Case background change management was very bureaucratic and strict, further
exacerbating the problem of poor responsiveness to customer
This paper is based on a single descriptive longitudinal case and market needs. Third, the cost of quality was high and growing,
study [22] of a product development unit at Ericsson, developing as there was a big-bang integration followed by a long testing and
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1559

fixing period at the end of the project. Fourth, management consid- We approached this case in an exploratory manner aiming at
ered personnel motivation to be lower than desired, as people understanding the basic reasoning behind and workings of the
worked mainly in small silos with very specialized software communities of practice. We stated the following basic research
engineering and product knowledge, and very little insight into questions to guide our research:
the larger whole of the product and project.
These problems created an uneasy feeling, in particular in the  RQ1: What kinds of communities of practice were created in the
management team in Finland, and they started to search for case organization and how did they evolve over time?
solutions. There was a lot of interest in agile and lean software  RQ2: What were the characteristics of successful communities
development worldwide in the industry, motivating the manage- of practice?
ment team to study the agile practitioner literature, which seemed  RQ3: How did the role of communities of practice in the case
to provide solutions to their problems. As the main expected ben- organization evolve over time?
efits of adopting agile software development, the organization saw  RQ4: How did the case organization support the communities of
breaking down functional silos and forming cross-functional practice?
teams, having closer relationship with the customers, and focusing  RQ5: How could the different purposes of communities of prac-
on communication rather than documentation. However, given the tice be classified?
strong process and project culture in the organization, and the
large and complex product, they thought that basic agile practices 3.3. Data collection
would not be enough. Even though Agile software development, in
particular the Scrum adoption, is the most visible part of the trans- We collected the data mainly through semi-structured inter-
formation, as it provides the day-to-day practices, lean thinking views, using five rounds of interviews over a two year period, com-
and principles were taken into the transformation already in the plemented with observations of three CoP meetings. In total, we
beginning. Actually, many founding ideas of this transformation interviewed 52 persons. A timeline of the research is shown in
came from lean, such as continuous improvement, removing Fig. 1.
waste, flow optimization in the form of end-to-end development
and value stream thinking.
3.3.1. Interview approach
After careful planning, the transformation was started by form-
We used the general interview guide approach [29], meaning
ing the first pilot team at the end of 2009 and the second and the
that we had outlined a set of issues to be explored in the inter-
third team soon after that. The full-scale agile roll-out took place in
views, having the guide serve as a checklist to ensure that all rele-
2010, during which the whole R&D organization—distributed
vant topics were covered. We performed the interviews in a highly
between Finland and Hungary—was transformed to cross-func-
conversational manner [29], to give space for deeper discussions,
tional Scrum teams of 7–8 persons. The Finnish teams were relo-
and to allow the interviewers to ask follow-up questions to gather
cated to newly renovated team spaces in an old factory hall,
more details on interesting topics that arose during interviews.
while the Hungarian teams had team rooms. The first steps of this
In particular during the two first interview rounds we concen-
Lean and Agile transformation are described in more detail in [26],
trated on topics from the guide according to each interviewee’s
the new workspace solution in [27], and the continuous release
core knowledge, e.g., with the managers we had deeper discussions
planning process in [28].
on the topics such as the lean and agile adoption and its reasons,
whereas with the team members we could have deeper discussions
3.2. Research goals and questions on how they apply Scrum at the team level. Thus, the idea was not
to discuss all the topics in the guide in detail level with all the
The main research goal of the study presented in this paper interviewees, but to use the limited interview time so that we
was to investigate how a large globally distributed software would get the best knowledge from each interviewee. We aimed
development organization adopted the use of Communities of for data saturation [30], i.e., when it seemed that an interviewee
Practice as part of their transformation from a traditional would not give additional information on a topic, we did not
plan-driven organization to Lean and Agile. We purposefully emphasize that topic in the interview. We did some minor modifi-
selected this information-rich case [29], as the case organization cations to the interview guides after the first few interviews, such
was a participant in a joint research program ensuring access. A as adding the Proxy Product Owner to the role list, when we dis-
longitudinal study was chosen to be able to understand how covered the organization had such a role. The interview guides
the transformation proceeded over time, and thus also study most relevant for this paper—the one used during the first and sec-
how the Communities of Practice developed and changed over ond interview rounds, as well as the guide developed for the fifth
time. As we were interested in studying a phenomenon in its interview round—are in Appendix A.
in vivo context, without control over events or decisions, a case In most of the interviews, two researchers were present, one
study approach is appropriate [22]. being the main interviewer and the other one taking detailed notes

Interview Interview Interview Obser- Interview Interview

round 1 round 2 round 3 vations round 4 round 5

J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J
2011 2012 2013

Feedback Result
session validation

Fig. 1. Timeline of the research.

1560 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

and asking additional questions. All interviews were recorded and CoP meetings, and provided a possibility for methodological
transcribed. triangulation.
During the fifth interview round, we asked the interviewees
about their past and current experiences in building and
3.3.2. Interview rounds
participating in CoPs. Two of the interviews were individual
We performed five interview rounds, the details of which are
interviews of managers, one leading the lean and agile transformation
shown in Table 3. When we started to study the organization,
and the other working as a head coach. With the manager leading
our main purpose was to study the Lean and Agile transformation.
the agile and lean transformation, we discussed CoPs in general
During the two first interview rounds our goal was to gather
and all types of CoPs. With the head coach, we focussed on the
understanding of this whole large-scale transformation, e.g., why
End-to-End CoP, but also talked about other types of CoPs. The rest
and how it is done, what the main challenges and successes were,
of the interviews were pair interviews that focused on three types
and what challenges and lessons learned the organization had
of Communities of Practice that we deemed interesting based on
encountered for scaling agile development to a large distributed
our earlier interviews and after discussions with the manager
organization.
leading the agile and lean transformation: the Coaching CoP,
We selected the interviewees jointly with management, aiming
Developers’ CoP and Feature CoPs.
for people with different lengths of experience and working in dif-
The Coaching CoP was chosen as it was one of the oldest CoPs
ferent roles. The first interview round of seven managers and a
and had largely evolved during its’ existence. The Developers’
coach provided us with an overview of the organization’s history,
CoP was deemed interesting, as it had already once died and then
motivation for the transformation and the main transformation
started again. The Feature CoPs were interesting, as they had
steps. To get a broader view of the transformation in the whole
turned out to be key elements of the large-scale agile implementa-
organization and to enable triangulation, during the second inter-
tion as they took care of a large part of the coordination and com-
view round we interviewed 31 persons—20 from Finland and 11
munication between cross-functional teams. The End-to-end CoP
from Hungary—from different roles and teams, and with differing
was interesting because it had an organizational wide focus, and
amount of experience in the organization.
management considered it important for optimizing the overall
The third and fourth interview rounds were follow-up
product development flow.
interviews to study how the transformation was progressing.
From the Coaching CoP, we interviewed two Coaches, and from
During the third round we discussed topics that we found
the Developers’ CoP, two developers, one of which also had the role
interesting based upon the two first interview rounds, such as
of team coach. From the Feature CoPs, we interviewed representa-
how the Product Owner structure and Scrum-of-Scrums practices
tives of two different CoPs; a Product Owner and a developer who
were evolving. During the fourth round we focused on the
doubled as a team coach. We discussed the End-to-End CoP in par-
integration of the US site in the transformation, as that was a
ticular with the head coach, who led it. In all the interviews, we
recent development.
discussed the specific CoP or CoP type that the interviewees had
Based upon the two first interview rounds, the use of Commu-
most experience of, but briefly talked about other CoPs that the
nities of Practice arose as one of the most interesting topics for fur-
interviewees had participated in, as well as about general charac-
ther study. The organization viewed CoPs as one of the main
teristics of successful and non-successful CoPs.
practices used to support scaling agile development. During the
The interviewees for the pair interviews were chosen by the
third and fourth interview rounds, we could see that the CoPs
company representative, our main contact person. The intervie-
had evolved and had a high importance placed on them. Thus, it
wees represented experienced participants of the selected CoPs,
became evident to us that CoPs played an important dual role:
and had experience of several different CoPs. In one of the pair
interviews, a Hungarian interviewee participated through video-
1. CoPs were one of the key elements supporting the on-going
conference from Hungary, while all other interviewees were from
transformation from waterfall to agile development, or ‘‘the
Finland, where the interviews were physically conducted. In the
journey’’ as the organization called it, and
manager interviews, we discussed the development of the
2. CoPs were a key practice to support the large-scale agile
organizational support for CoPs, or the ‘‘CoP culture’’ at a general
implementation.
level, as well as a few individual CoPs.
For these reasons, we asked for a possibility to perform an inter-
view round focusing only on CoPs. Fortunately, the organization 3.4. Data analysis
agreed and we were able to do a fifth interview round. Moreover,
we got an opportunity to observe three CoP meetings, of the All interviews were transcribed by a professional transcription
Coaching CoP, Feature Coordination CoP and Feature Design CoP. company. The main data analysis method used was qualitative
This helped give us an understanding of what really happened in coding of transcribed interviews [29,30]. While waiting for the

Table 3
Interviews.

Interview Focus Interviewees Roles

round
1. 3/2011 Transformation overview Finland: 8 Managers: 7, agile coach: 1
2. 6/2011a Deeper study of the transformation Finland: 20, Scrum masters: 6, team members: 13, line managers: 3, product owners: 7, technical
Hungary: 11 management/architecture: 5
3. 6/2012 Transformation follow-up: PO role, Finland: 3 Product owners: 2, team member: 1
Scrum-of-Scrums
4. 12/2012 Transformation follow-up: US site Finland: 2 Managers: 2
integration
5. 1–3/2013 Communities of practice Finland: 7, Managers: 2, coaches: 2, team members: 3, product owner: 1
Hungary: 1
a
The sum exceeds the total number of interviews, as some line managers had double roles, e.g. also worked as Scrum masters.
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1561

transcriptions, based on the interview notes we created prelimin- this session all interviewed persons were invited and around half
ary categories for coding, a start list of codes [30]. This list included of them joined the session. Both sites, Finland and Hungary, were
categories such as ‘‘Scrum’’, ‘‘CoP’’, and ‘‘Transformation’’. We represented. During the session, a lot of questions were asked
coded the transcribed interviews in Atlas.ti, a qualitative data anal- and the audience was eager to discuss our findings and progress
ysis software, using the preliminary categories, open coding, as they had made after the interviews. The company found the feed-
well as axial coding [31]. This resulted in codes below the main back valuable, and while, e.g., management challenged some of our
categories, such as ‘‘Scrum: Daily’’, ‘‘Scrum: SoS’’ (Scrum-of- less flattering findings, personnel in other roles confirmed them,
Scrums) etc. and no corrections or additions to our findings came out of the
We coded the two first interview rounds after the second inter- session.
view round. Both authors of this paper did this coding together, Moreover, we presented and discussed our findings from the
dividing the interviews between each other, and using the same third and fourth interview rounds in research meetings with sev-
hermeneutic unit.1 When coding the first few interviews, we eral case company representatives. After the fifth interview round
cross-checked each other’s coding to ensure agreement, as well as the results, in the form of the first draft of this paper, were sent for
discussed the codes together agreeing on changes to the preliminary commenting to all persons interviewed during that interview
codes. round, as well as to one other representative of the case organiza-
After the initial coding, we extracted specific codes from tion, who was not interviewed, but was very experienced in CoPs
Atlas.ti, and did in-depth coding, both open and axial. Based upon due to having participated in and led several CoPs.
this, we prepared a presentation for the case organization, describ- We received detailed comments from this last mentioned expe-
ing our findings: successes, challenges and improvement needs rienced person, as well as from one interviewed manager. The
seen by the interviewees. comments confirmed our findings, and the detailed comments
The third and fourth interview rounds were coded in a similar included only minor clarifications to the text.
manner, after each interview round, but instead of a feedback ses-
sion the findings were briefly discussed with company representa-
tives during research visits. Before the fifth interview round we 4. Results
extracted the passages coded by Communities or Practice and
Scrum-of-Scrum meetings from the previous data. These were As described in the background section, the case organization
carefully analyzed before creating a semi-structured interview had started the lean and agile transformation in 2009 and the
guide for the fifth interview round. full-scale roll-out took place in 2010. The communities of practice
As the fifth interview round focused on CoPs, these interviews were introduced at the same time as the full-scale roll-out. The
were coded from that view point. A start list of codes was created main motivation for the case organization to institute the use of
based on the interview notes. The codes included a few high-level CoPs was that the CoPs were a proposed solution both by the con-
codes such as the names of all CoPs, as well as codes describing sultants that the case company employed, as well as in the litera-
positive or negative opinions: ‘‘challenge/problem’’ and ‘‘success/ ture on scaling agile development [7,10].
positive’’. The start list of codes was improved by adding codes that In this section, we first give concrete examples on how and why
arose from the data while coding the first few interviews. Exam- the case organization built CoPs, and how they evolved over time.
ples of these include ‘‘CoP leader’’, ‘‘decision making’’, ‘‘rhythm’’, Second, we describe the characteristics of successful CoPs. Third,
‘‘agenda’’, ‘‘CoP invitation’’, ‘‘mindset’’ and ‘‘community’’. we discuss how the case organization supported the CoPs. Fourth,
The final results, presented in this paper, were based on the we describe the different phases the organization went through
analysis and comparison of both the CoP and SoS codes extracted while building and using CoPs. We end the results section by pre-
from the first four interview rounds, as well as all the codes from senting a typology of CoPs used in the organization.
the fifth interview round.
4.1. CoPs in the case organization
3.5. Validation
In this section, we discuss our results related to RQ1: What
To ensure the validity of our findings we took several actions
kinds of communities of practice emerged or were created in the
both when planning the research and during the data collection
case organization? We present four examples of successful CoPs
and analysis. First, we used three types of triangulation in data col-
in the case organization: the Coaching CoPs, the Feature CoPs,
lection: data, investigator and methodological triangulation
the Developers’ CoP, and the End-to-End CoP.
[29,32]. We interviewed a large number of persons from different
roles and organizational levels to get as realistic picture as possible
(data triangulation), in most of the interviews two researchers were 4.1.1. Existing communities of practice
present (investigator triangulation), and besides the interviews we During the fifth interview round, we asked our interviewees
observed three CoP meetings (methodological triangulation). how many CoPs the organization currently had, but could not get
Second, the data was analyzed carefully together by both a definitive answer. Some respondents reported around 20, and
researchers, who communicated actively both during the coding some that the number is somewhere between 20 and 50. Looking
process and analysis phase, which ensured that both researchers at the organization wiki page where you could find links to all
agreed on all the codes, analysis and the findings. Third, the cor- CoPs, our interviewee noted that the list does not seem to be up-
rectness of our findings were validated in several ways by the case to-date. Some CoPs that he knew exist were not there, some that
company representatives: conducting a company feedback session, were there, had according to him already ceased to exist. However,
discussions with the company representatives, and having com- when we asked our interviewees what are the most successful
pany representatives read and comment on this paper. CoPs, the same CoP names started to come up: Feature CoPs,
The results based on the first and second interview rounds were Coaching CoP, Developers’ CoP, End-to-End CoP, Functional Verifi-
presented to company representatives in a feedback session. To cation CoPs, and a few other testing related CoPs. Next, we will
have a look into these four first mentioned successful CoPs: what
they are and how they have evolved. Table 4 summarizes the key
1
The analysis ‘‘container’’ in Atlas.ti. findings on these CoPs.
1562 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

Table 4
Examples of CoPs in the case organization.

Coaching CoP Feature CoP Developer CoP End-to-end CoP

Predecessor Scrum master CoP SoS and system CoPs Previous developers’ CoP Program weekly
Predecessor’s role Sharing experiences in SoS: inter-team coordination, Design rules etc. High-level R&D progress monitoring and way
applying Scrum practices Syst.CoP: feature design of working
Participants Scrum masters/coaches Representatives of cross- Developers Persons wanting to make a difference:
functional teams managers, product owners, coaches, team
members
Current role Improving the whole Supporting coordination and Software craftsmanship, Improve the way of working and optimize the
organization and its design between teams unifying tools and end-to-end flow
competences developing a common feature technologies over product
areas
Location and Cross-site (Finland/Hungary), According to the distribution Finland, Hungary Finland, Hungary, US
distribution and site-specific CoPs of the product areas, mostly
cross-site
Rhythm Weekly Feature coordination CoPs Bi-weekly Weekly
weekly, Feature design CoPs
on a need basis
Challenges faced Lack of common activities Organization-wide SoS did not The first trial ceased to exist Involving the US site due to the time-zone
and goals after day-to-day work: several trials to find a due to lack of a CoP culture difference
problems were solved solution to inter-team issues
Successes Promising new start with After many trials a functioning Promising start-up after the Broad representation of organizational levels
goal to improve the whole solution for inter-team death, with a passionate and sites facilitates decision making and
organization and its coordination and design leader, interesting topics and moving things forward
competences goals

4.1.2. Coaching CoP Coach 2: ‘‘We have failed miserably.’’

The Coaching Community of Practice (Coaching CoP) was one of Coach 1: ‘‘I don’t know. We haven’t had a continuos backlog at any
the first CoPs that started. In the beginning, it was called the Scrum time. We have had trials of a Coach backlog and Impediment
Master’s CoP as at that time the case organization had mainly backlog during this two and half years. . . . But they have always
Scrum Masters. Later on, as the number of coaches started to grow, died for some time, then somebody wakes them up again.’’
as many of the teams changed from Scrum towards Kanban or – Coaches, Finland 2013
Scrumban [33], the name was changed to Coaching CoP.
The Scrum master/coach community has never had a real leader
4.1.2.1. Early stages. Our interviewees reported that in the begin- or even a facilitator. The meetings were organized around a loose
ning the Scrum Master CoP was working quite well, as people agenda with discussion items collected by the participants to wiki
wanted to learn more, improve their teams and search solutions pages. A brief memo was written during the meeting for those not
for their problems. present to be able to find out what was discussed.

And then we have the Scrum Master CoP, where we discuss these We have rotated the responsibility for facilitation amongst the par-
things that have been challenging in the teams and try together ticipants. Usually, it is the one who is there first and connects his
to find solutions to those. laptop to a projector. Those meetings have been quite self-organiz-
– Scrum Master, Finland 2011 ing, not much facilitation, we have had the agenda ready, so we
have just discussed those topics one after another. (. . .) The number
Then there [in the Scrum Master CoP] was a lot more discussion on
of participants has been quite low recently, I guess people have so
the basic routines, how we organize retros, what this agile thing is,
much other things going on. (. . .) But we also write the wiki memo
and how we should behave and what is our role. . . And then it was
so it is possible to follow what has happened.
really active, I have to praise that community, because that helped
– Scrum Master, Finland 2011
me to come into this role. I participated in an Agile course and
Scrum Master training, but I had not come into this lean and agile
thinking in the same way as I did when I saw the mentality here [in 4.1.2.2. Crisis and maturation. However, after this first phase of the
the Scrum Master CoP]. It helped me to come in. agile transformation was over, the Scrum master/coaching CoP was
– Coach, Finland 2013 in trouble. The participants did not form a tight community with
common goals or even a common backlog for work tasks. People
At that time the Scrum Masters tried to ‘‘practice as they
started to vote with their feet: some participated only occasionally,
preach’’. Thus, the Scrum Master community had several common
when they had the time, and some totally stopped showing up for
events during each week. They held a daily scrum meeting ‘‘the
the meetings, as they found that the meetings dealt with irrelevant
Daily’’ for Scrum Masters, and had a CoP ‘‘backlog’’, and held ‘‘Back-
topics, did not provide sufficient follow-up on issues, and partici-
log Grooming’’ and ‘‘Impediment Handling’’ sessions. They also had
pants had difficulties agreeing.
weekly ‘‘Training’’ sessions, to which they either invited internal or
external people to present on interesting topics, like conflict han- But to be honest, I was fed up with that [Scrum Master] CoP last
dling or they just watched a video together and discussed it. How- year. (. . .) We discussed irrelevant issues there. That is my view.
ever, the CoP experienced several problems, including attracting (. . .) For me it wasn’t an issue to discuss who should take the laptop
participants to the meetings, and getting the idea of a coaching to a demo session, the Scrum Master or the team, so come on, that
backlog to really work, as illustrated by the following quotes: is not relevant at all. (. . .) And I started to be bored there. And I
decided not to take part of that. (. . .) I thought at that time that
Coach 1: ‘‘We have had several things that, e.g., every morning
was not important for me, because I didn’t gain anything.
Daily and there comes those who come. We have tried to work
– Developer, Hungary, 2011
the way we want the teams to work.’’
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1563

We don’t practice what we preach. The way of working in this commu- have all coaching tasks that required support from the community
nity is not what we are trying to coach for others, we don’t have a on the wall.
backlog, we don’t follow-up in the sense that we would visualize what
The idea of this (the Cool Wall and Coaching Backlog) is that it is
we are doing. We don’t catch things up. We don’t agree on things
not only the coaches building this, but the whole organization
together—that is missing from this community. It is probably one of
(. . .) Meaning management, Product Owners, team members, coa-
the reasons why this CoP doesn’t work and people get frustrated.
ches. (. . .) And then the coaches decide what they do to these things
– Manager, Finland 2013
and then we have a Kanban Board where we have a backlog.
However, the CoP did not totally die, even though the number – A Coach, Finland 2013
of participants in the meetings was low—around three to ten—for
some time. Instead, the community started to search for better When interviewing a technical team coach, we noticed that the
forms and goals. ideas of the organizational coaches were noticed in teams, as the
During the fifth interview round, most of the teams used a com- team coach mentioned that he aimed to prioritize the development
bination of Scrum and Kanban, ‘‘Scrumban’’ [33] and had a team team’s work according to the priorities at the ‘‘Cool Wall’’ and
coach, instead of a Scrum Master. Most of the team coaches were ‘‘Coaching Backlog’’:
dedicated to one team, but some were shared between two teams. . . .I think it [the Cool Wall] is a good thing and I have taken some-
Some of the coaches were more ‘‘technical’’, i.e., they concentrated thing from there also to our own team. If we need to choose
mainly on technical tasks in the teams and took care of the coach between two tasks and one helps more than another to move
role in addition to their developer role. A few of the team coaches things on the cool wall forward, then we will do more those tasks
were also line managers. Moreover, the organization had a few and support that work.
full-time organizational coaches, including the head coach, who – Team Coach, Finland 2013
concentrated on the development of the whole organization. Thus,
the participants of the coaching community were at that time quite In the fifth interview round, we discovered that another activ-
diverse, both regarding their roles and the length of their experi- ity, started already in the beginning, was still active, namely a
ence in the coach role. weekly meeting to learn and discuss new lean and agile topics
At the time of our fifth interview round, the Coaching CoPs had together. That ‘‘learning community’’ meeting was called the
been further developed. As the Finnish site had a few teams work- Coaching Guild and had recently concentrated on watching and dis-
ing for a different product, and the Hungarian site had other prod- cussing video clips on agile development.
ucts all the time, there was a need for site-specific Coaching CoP One of the recent challenges of the Coaching CoP has been that
meetings, in addition to the product-specific Coaching CoP. Thus, the Coaching Community now had persons at different levels in
the first 30 min of the weekly Coaching CoP meeting was site-spe- their coaching career, there were experts, the experienced organi-
cific—in Finland only— followed by the cross-site product specific zational coaches, as well as new team coaches who have team
CoP for the next hour as a videoconference. Thus, the participants coaching as a side job, in addition to being a developer. As these
could choose, whether they wanted to participate in one or both persons have a totally different level of knowledge on agile meth-
parts of the session. Hungary also had site-specific Coaching CoPs, ods, as well as different problems in their daily work, it did not
but at a separate time. seem to be easy to find discussion topics that would be interesting
The organization wide Coaching CoP, that we studied, had also and important to all.
broadened its goal and responsibilities. The participants were no Even though this Coaching CoP and the coaching community
longer concentrating on solving and discussing day-to-day prob- was active during the whole organizational transformation, and
lems of the Scrum Masters and Coaches. Instead, their goal was thus probably the most successful example of a learning and
to improve the whole organization and its competences. knowledge sharing community in this organization, it has also
had serious challenges. The community clearly suffered from a lack
. . .[currently] we are planning a Coach day. We tackle problems
of common activities and goals. Only learning together and sharing
and discuss how we could improve this organization, and our com-
knowledge was not enough to keep the community alive. The com-
petences. Meaning the competences of the whole organization.
munity did not have any leader, even though the organization had
– A Coach, Finland 2013 a head coach during our fifth interview round. The recent activities
To support the organizational development and to align the of the organizational coaches in building the ‘‘Cool Wall’’ and
work, the active coaching CoP members had built a ‘‘Cool Wall’’ Coaching backlog for advancing the organization wide issues seem
and a ‘‘Coaching backlog’’ that were placed in the common area as a successful start to involve and align the whole organization.
for the whole development organization in the Finnish office. This seems to be a good beginning to create a common goal and
On the ‘‘Cool Wall’’ they listed the main topics that the organi- common activities for the coaching community and even for the
zation needed to develop further and divided them into sub-areas whole organization.
under columns ‘‘seriously uncool’’, ‘‘uncool’’, ‘‘cool’’ and ‘‘sub zero’’.
Under the column ‘‘Seriously uncool’’ were topics that needed a lot 4.1.3. Feature CoPs
of work, and the ‘‘sub zero’’ column contained items that were The Feature CoPs evolved out of Scrum-of-Scrum meetings. In
‘‘pretty cool’’. the beginning of the agile and lean journey, the case organization
The coaching backlog, on the other hand, was a backlog of con- had around 25 cross-functional teams, all using Scrum. According
crete actions, divided into tasks, and placed into Kanban board to Scrum, the main coordination mechanism between the teams
with the columns, ‘‘not started’’, ‘‘In progress’’ and ‘‘Done’’. This are Scrum-of-Scrums (SoS) meetings [25]. That is, after each team
backlog was recently created, and during our fifth interview round has had its’ own Daily Scrum meeting, in which each team member
we could see how the backlog was already in active use with a lot answers the three Scrum questions,2 the team sends a representa-
of tasks. For example, ‘‘Software Craftmanship Day’’ and ‘‘Coach tive to a Scrum-of-Scrums meeting, where each team representative
Day’’ were under preparation, as well as more technical items, such answers similar questions on behalf of his or her own team and that
as test automation improvements had started in the form of coding
camps and courses. At this time there were a few full-time organi- 2
1. What have you accomplished since the previous meeting? 2. What are you
zational coaches driving this improvement step. The idea was to planning to do before the next meeting? 3. What obstacles are in your way? [24].
1564 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

way shares information between the teams. In the case organization model, done by specific designers. When creating the new cross-
these organization-wide Scrum-of-Scrum meetings were not functional teams, the idea was that the teams would take care of
organized daily. Initially, they were held three times a week, later the systemization, as well. However, in the beginning most of the
once a week, and finally they ceased altogether. teams did not have enough knowledge to do systemization, thus
At that time, the development was distributed to two sites, in instituting systemization CoPs that had participants from teams
Finland and Hungary. Thus, the SoS meetings were organized using developing that feature helped:
videoconferencing. As the number of teams was large, and the
It is a community formed of ad-hoc of persons, who want to or are
teams were working on separate modules of the product using dif-
interested in making decisions. (. . .) Let’s say that in the next sprint
ferent technologies, they did not have much in common, and
we are going to have a user story with some complex task. If we
sometimes did not even understand what the others were doing.
have identified that, we aim to arrange some system planning
Thus, the SoS participants were not very interested in what others
beforehand, to draw a sequence diagram. To do a proposal. The Sys-
were reporting nor did they know what they could report that
tem CoP invitation is send to all teams [working on that topic], that
would be interesting or useful for the other teams. This led to a sit-
every team should send at least one representative. And then we
uation in which most of the teams reported ‘‘Nothing to report’’
make a decision; these technical decisions that are very difficult
since there was so little common ground. Obviously, this was a sign
to make in the beginning. (. . .) I think this works fine and we have
of a dysfunctional coordination mechanism. The organization tried
managed to make that kind of decisions that people don’t complain
different ways to improve the SoS meetings by facilitating and edu-
about afterwards. And everybody has a possibility to affect this
cating the teams on what to report and discuss there, as there still
decision making. And when the decision is made, it holds.
was a clear need for coordination between the teams. Many of our
interviewees noticed problems due to this dysfunctional coordina- – Developer, Finland 2011
tion and communication mechanism.
4.1.6. Feature coordination CoPs
4.1.4. Feature SoS meetings
At the time of our fifth interview round the product had been
As a solution to the problems of organization-wide Scrum-of-
divided into four product areas, two of them divided between
Scrum meetings, the organization additionally started arranging
the teams in Finland and Hungary, one between the teams in Fin-
weekly Scrum-of-Scrum meetings inside specific features, so called
land and the US, and one had just local teams in Finland. Each of
Feature SoS meetings. At that time, the features were very large,
these areas arranged Feature CoP meetings between the teams
with 3–8 teams working on a feature for several months or even
working in this area. All the areas arranged weekly SoS style CoP
in some cases, years. The feature SoS meetings turned out to work
meetings, where the team representatives reported what their
well, as there was much more common ground than in the organi-
team had been doing, what they were planning to do, and if they
zation-wide SoS meetings.
had some obstacles. Often there was some discussion in the end.
The Feature SoS meetings covered topics that were important
In most cases, each team sends a representative chosen as
and interesting to discuss together frequently. The participants of
round-robin style to these meetings. From some teams a few team
the Feature SoS meetings were one or more team members from
members joined, and sometimes even the whole team participated.
each team working for a specific feature, and in most features also
Some of our interviewees still called these weekly coordination
the Product Owner or Product Owners participated, as well. In
meetings Feature SoS, some called them Feature CoPs, and
some cases, a whole team participated. As the implementation of
when asked, they said that they did not think that the name mat-
most of the features were divided between the two sites, the Fea-
ters. For clarity, we refer to all of these as Feature Coordination CoPs.
ture SoS meetings were organized using videoconferencing. As the
Besides the Feature Coordination CoP meetings, the product
following quotes indicate, the Feature SoS meetings started to
areas arranged Feature CoP meetings on technical topics, e.g., for
work pretty well, and participants found them useful:
systemization, architecture planning and making decisions related
Feature SoS meetings are pretty good, because people participating to technical issues. From now on we call these Feature Design CoPs.
in them work on the same things, talk ‘‘the same language’’ and Feature Design CoPs were normally invited on a need basis and
have a common goal. there the team representatives were often different persons than
– Product Owner, Hungary 2011 in the Feature Coordination CoP meetings, as different things inter-
est different persons.
This [Feature SoS] is a good meeting, since this is the only place
where we are all together at the same time (. . .) Here we can dis- In practice we have noticed that it is better to have this [Feature
cuss everything. We have tried to keep it this way, that we don’t Coordination CoP] as a general meeting and then have separate
have agenda, but discuss what is done at different teams, if there meetings for technical things, as those meetings have slightly differ-
are any problems or other common topics. ent participants, those who are interested in that, so it has been
– Product Owner, Finland 2011 easiest to have separate meetings.
– Product Owner, Finland 2013

4.1.5. Feature CoPs Our interviewees emphasized that most often, the Feature CoP
For some time, the organization had the organization-wide SoS participants join the meetings on voluntary basis—those who are
meetings once a week and Feature SoS meetings for each of the fea- interested or need to be there attend. Each team just makes sure
tures once a week, as well. However, soon the organization-wide that they have at least one representative when needed. To some
SoS meetings died. As the word ‘‘SoS’’ had bad connotations after of the Feature Design CoP meetings, persons from other closely
the not so successful organization-wide SoS meetings, and as the related areas might be invited, if they have technical connections
CoP culture developed in the organization, some started to call that need to be discussed together, or to learn from another area
the Feature SoS meetings ‘‘Feature CoPs’’ instead. that has dealt with similar issues earlier.
Moreover, other Feature related CoP meetings were started In the fifth interview round, we interviewed persons from two
between the team members working for a specific feature, e.g., Sys- product areas. The first area had five teams: three in Finland, and
tem CoP, for systemization, i.e., high-level collaborative system two in Hungary. Consequently all Feature CoP meetings were orga-
design. The systemization work was previously, in the waterfall nized using videoconferencing. In this product area, the weekly
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1565

Feature Coordination CoP meetings had a time slot of one hour. body. I think it is very important, because if there will be cliques,
Normally, the first half an hour was used for a SoS style bad things will happen.
coordination discussion, and the rest was used for discussing – Developer, Finland 2013
the general ‘‘way of working’’ issues, e.g., testing, continuous
The regular Feature Coordination CoP meetings had found their
integration and other improvements.
place and were working well, when the area had several teams dis-
Previously, they had more technical discussions in the meeting,
tributed at different sites. When only a few teams were working
but noticed that it is better to have technical Feature Design CoPs
locally, the need for regular meetings was less important. One of
separately, as the participants might be different. The Feature
our interviewees even commented that he was happy that in their
Coordination CoP meetings always had a facilitator, who typically
product area they had accepted that regular Feature Coordination
was one of the team coaches. The facilitator, who had taken the
CoP meetings are not needed, so they do not waste their time on
role of a ‘‘community coach’’, also saw to that communication
organizing meetings just because it is a routine, but have meetings
between the teams was working on a daily basis. In addition, the
only when they really are needed.
product area had a wiki page, where anybody could add topics
on the agenda, even though in practice it was often the team coa-
ches and the Product Owners who added most of the topics. 4.1.7. Developers’ CoP
Besides the Feature Coordination CoPs, this product area had 4.1.7.1. First trial. The Developers’ CoP was one of the first CoPs that
started to arrange regular Feature Design CoP meetings once or started during the early phases of the transformation. However, it
twice a month. did not find its’ place back then, and ceased to exist. One of the rea-
The second product area had only three teams, all located in the sons for its’ early death, according to our interviewees, might be that
same large open office in Finland. Their daily communication was back then, this CoP concentrated too much on design rules. More-
easy, and thus their weekly Feature Coordination CoP meetings over, at that time, the CoP culture and mindset was not yet fully
were arranged only when a particular need arose. Instead, they developed. In particular for developers, it might have been difficult
arranged Feature Design CoP meetings on specific topics, whenever to see the benefit from participating in that kind of CoPs. Third, this
someone felt that there was a need. For example, when making big was a site-specific CoP, only involving Finland, even though collab-
architectural changes, refactoring, they arranged Feature Design oration between the sites would certainly have been beneficial.
CoP meetings to which they even invited people outside their I think the problem was that when this Developers’ CoP in the old
product area to receive broader input. These were considered suc- days was started it was here only and not really (. . .) Hungary
cessful events. wasn’t really part of that one. (. . .) And it stayed on for roughly a
This year we haven’t felt SoS to be important, as we have only three year, but then it died because nobody participated.
teams sitting side by side. The teams or individuals from the teams – Developer, Finland 2013
discuss daily. We have had a few SoS meetings when somebody had
done some bigger changes and wanted to explain that, and then 4.1.7.2. Restart. In the beginning of 2013, the Developers’ CoP was
informed beforehand that ‘‘In the SoS I will explain this to every- restarted. This time around, it concentrated on a popular topic in
body, come to listen if you want’’. And those have been useful. the organization, namely software craftmanship.
The SoS is a natural meeting to share that kind of information.
– Developer, Finland 2013 It was off more than a year. But then, as things came up in the
chats, that people are really struggling with these day-to-day
However, previously, one year ago, this product area had been development issues, then we talked on a coffee break that now I
distributed: in addition to the three Finnish teams, there were think we need to do something about this, and restart the Develop-
three subcontractor teams, all working at different locations. Then, ers’ CoP and then it was agreed. Now we start it again. A whole lot
the weekly half-hour Feature Coordination CoP meetings had been of stuff then came up and I think it was a good decision to restart it.
very important, as the subcontractor teams could ask questions in – A Developer, Finland2013
the meetings and somebody would take responsibility for helping
them. The Developers’ CoP is now organized as a videoconference
between Finland and Hungary. However, it was decided that the
It was working well at that time, we had many teams and we had new site, the US, will not be included due to the eight-hour time
useful things to discuss there. It was not only that ‘‘we are doing difference.
this and that’’ and nobody really is interested, but then it was use-
ful, people asked for help, received help and told what they had It’s really like one or a maximum of two hours’ time slot where
done. (. . .) Then there was also a teaching aspect for those subcon- everybody would be present. (. . .) So that is why we decided that
tractor teams, when others told what we had done and why. the Developer CoP doesn’t include [the US site]. It’s sad. I think
– Developer, Finland 2013 we should really talk with them as well, But due to the time differ-
ence, it’s really hard.
It became clear that in the both product areas, the culture for – Developer, Finland 2013
inviting Feature Design CoP meetings was very open and well-
functioning. Whenever there was a need for a meeting, somebody At the time of our fifth interview round, the Developers’ CoP
invited it, people with an interest in the topics participated, and had a very good restart and a passionate leader who had plans
decisions were made. and goals for the CoP:

These meetings (Feature Design CoPs) are invited by individuals, it I think the main thing I want to build with the Developers’ CoP is
is not Product Owner driven. When somebody feels that we need to kind of . . . really a community around it. So that people that cur-
do something, he takes the responsibility and invites a meeting. rently are not participating, would come there. To discuss their
And luckily, there has been interest, and the people that have been problems. What I would like that to be, some kind of forum where
needed have participated, and also those that have been interested we could share the good practices and try to avoid the bad prac-
to learn more have participated. Thus, it is not only the best gurus tices. That’s the direction I want that CoP to go. (. . .) We could actu-
that discuss together. Instead, it is an open meeting that everybody ally drive things forward with this CoP.
who wants may participate in. And the invitation is send to every- – Developer, Finland 2013
1566 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

The Developers’ CoP had already established a mailing list for During our later interviews it became clear that people had
active members. The idea was to have a forum for asking and asked for these CoP meetings, thus they were organized again.
answering questions. In addition, the CoP had a ‘‘software According to all the interviewees who mentioned the End-to-
craftmanship’’ chat forum, which was one of the most active chat End CoP, this CoP was seen as one of the successful ones: it was
forums in the organization. The CoP wiki page, contained both well-organized with a clear leader, a good agenda and interesting
meeting agendas and minutes from previous meetings, as well as and important topics with the potential to advance the organiza-
useful material, such as coding style guidelines, instructions for tion and affect the daily lives of the participants. In addition, the
how to set up environments, etc. broad scale of representatives from different organizational roles,
As the product was divided into four product areas, the Devel- from team members to managers ensured that different points of
opers’ CoP aimed to break down the walls between the different view from the whole organization were represented. Having peo-
product areas. The product areas had used different technologies ple from all organizational levels made it easier to make big deci-
and tools, but now they were increasingly unifying these, adding sions and move things forward. The fact that all sites, Finland,
to the amount of joint topics to discuss and share. Thus, the Devel- Hungary and sometimes also the US were represented was seen
opers’ CoP might have an important role in sharing knowledge as beneficial. However, having the US site as a participant clearly
between developers, and thus better possibilities to succeed than caused challenges, as it would mean that the meeting should be
it had during the first attempt. arranged in the evening time at the other sites, and early in the
morning in the US. For a large meeting like this, that might mean
I have high expectation with this Dev. CoP. At least that through
a reduction in the number of participants.
that different areas would talk more with each other.
Even though the topic of this CoP was very broad and it could be
– Developer, Finland 2013
difficult to attract attention from a large group of people from dif-
ferent parts of the organization, the feedback so far had been very
4.1.8. End-to-end CoP positive according to all interviewees mentioning this CoP. Having
The idea of the End-to-End Flow Optimization CoP, or simply a good and interesting agenda, and a leader that keeps the discus-
the End-to-End CoP, as most of our interviewees called it, is to sion active seemed to be the key success factors of this particular
improve the product development flow through the whole organi- CoP.
zation and to remove bottlenecks that inhibit that flow.
This end-to-end flow optimization CoP . . . it requires a pre-pre-
pared agenda and topics beforehand, that people can see ‘‘whether
4.1.8.1. Predecessor. The End-to-End CoP was born out of a meeting
it touches me or not’’. If that would be missing, I believe that par-
called the ‘‘Program Weekly’’ led by the Program Manager. The
ticipation could be low. . .
Program Weekly was a high-level monitoring meeting, monitoring
– Manager, Finland 2013
product development progress at a high abstraction level, but
participants also discussed the way of working and improvement I like that CoP [End-to-End CoP] and I like the problemsldots or I
ideas. This meeting slowly died, and after half a year the idea to don’t like the problems that we are talking about there, but I like
start a CoP around the same topic came up. At the time of the that we are talking about the problems and, we are trying solve
interviews, the End-to-End Cop had been active for a bit over a them.
year. – Developer, Hungary 2013

4.1.8.2. Current stage. The end-to-end CoP was arranged once a

4.2. Characteristics of successful CoPs
week as a videoconference. However, if the agenda did not look
good, the meeting was canceled. The CoP had 20–40 participants,
In this section we discuss our results related to RQ2: What were
both from Finland and Hungary, and sometimes even a few partic-
the characteristics of successful communities of practice? We used a
ipants from the US site, if the meeting was scheduled so that they
subjective definition of success, i.e. we considered a CoP successful
could participate. A few local meetings had been organized as well.
if the interviewees reported it to be so. Furthermore, we explicitly
Participants came from all over the organization: team members,
asked our respondents to list characteristics of successful CoPs.
managers, coaches, and Product Owners. According to our intervie-
Based upon our data, we were able to identify eight characteristics
wees, the participants were active persons who wanted to make a
of successful CoPs in the case organization. These are summarized
difference in the organization and improve things. The meeting
in Fig. 2, and discussed in more detail below.
was facilitated by the Head Agile Coach.
There, we concentrate on what are the challenges, what we should 4.2.1. Interesting topic and concrete benefits
do to be more efficient as an organization. If we don’t have enough The main characteristic of the successful CoPs seemed to be that
test environments, or certain knowledge, or the way-of-working is the participants felt that they really gained something from every
bad, or collaboration is not working. From a very broad scale you single CoP meeting. The benefit should preferably be something
can bring in topics and there is the head coach and often other concrete with an impact on their daily work.
managers, people who can easily take things forward.
In the end it really depends on people. . . . And that people feel like
– Product Owner, Finland 2013
that they receive something. They have a benefit from participat-
At the time of the first interviews of the fifth interview round, ing. . . . So every meeting should provide something. Something tan-
the leader of the End-to-End CoP wanted to test whether this gible that you can take with you.
meeting really is needed: – Developer, Finland 2013

I have a test going on now (. . .) I haven’t booked the meetings yet. If I participate in the Developers’ CoP just because it is an interesting
there will be more than five questions on when it will continue, it topic, and there we discuss topics that interest me. Topics that
will continue. (. . .) Because in general, when you have a meeting, interest me are the reasons why I participate in those CoPs that I
people will come just because it exists, but if there is a need for participate. Nobody has told me that ‘‘why don’t you participate
it, then people will ask for it. this, or that you should go there’’.
– Manager, Finland 2013 – A developer, Finland 2013
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1567

Thus, the CoP topic should be important and interesting for the the agenda was good. If there was no proper agenda, some of our
participants. The CoPs that were build around something very interviewees felt that it might be better to cancel the meeting.
concrete, that was closely related to the daily work of the
I really like if there is a proper agenda, for a meeting. . . Otherwise,
participants, seemed to work well, e.g., testing related CoPs. CoPs
if there is no such kind or leader or driver, CoPs can end up without
dealing with topics that are more general and outside the ‘‘Daily
no agenda. People will start to feel that it’s just wasting time
Flow’’ of activities are more difficult to keep active and useful.
because you are just talking about basically nothing.
The more it (the CoP topic) has direct links to daily work of the per- – Developer, Hungary 2013
sons, the easier it is to create this link, that ‘‘if I participate in that
Besides having an agenda, it seemed to be important that the
CoP, then it gives to my daily work this and this’’. The larger the dis-
CoP leader or facilitator lead and even time-boxed the discussions
tance from the daily work the more work you need to do to create
to keep discussions going nowhere from taking up valuable time.
that CoP, motivate people and keep the CoP active.
Moreover, our interviewees emphasized that decisions or actions
– Manager, Finland 2013
taken in a CoP meeting should be followed up in the next meetings,
As people have limited time, they participate only in the CoPs and thus added into the agenda of the following meetings, as well,
they feel that will benefit them the most. as follow-up items.

4.2.2. Passionate leader

The second factor we identified was to have an engaged, pas-
sionate leader or facilitator: 4.2.4. Decision making authority
Many of our interviewees mentioned that decisions are and
I guess they [the successful CoPs] have a driver who is passionate should be made in the CoPs. They felt that it was part of the orga-
about it. . . . I guess that’s one of the most important stuff. . . I’m nizational culture that the CoPs had an authority to make deci-
not saying that you have to have only one leader or driver, but sions. They pointed out that this decision making culture existed
at least one. already during the plan-driven era, but the lean and agile transfor-
– Developer, Hungary 2013 mation had emphasized it even more.
Our interviewees emphasized that the CoP leader should prefer- Currently I guess it’s [Dev. CoP] more of a this kind of discussion
ably be an expert who people appreciate, within the area of the CoP. forum, but I think we have authority. . . yes, I know, we have the
When people know that this expert is participating or even leading authority to decide even.
a new CoP, they can trust that important issues are discussed and – Developer, Finland 2013
decided there. Thus, it came clear that if a person who is ‘‘nobody’’
in that community decides to invite a CoP, even though the topic The different sites have had slightly different cultures regarding
might be important, that CoP will most probably not succeed. decision making. At the Finnish site, people have been more active
decision makers, whereas at the Hungarian site, people have been
The better known and appreciated person he (the person setting up encouraged to be more active in decision making. This difference is
a CoP) is in that context, where he is building the CoP, the bigger most probably due to the different national cultures, as well as, to
chances he has to succeed. the fact that previously the Hungarian site was in the position of
– Manager, Finland 2013 subcontractor.
Quite often a typical CoP leader in this organization was a Our interviewees felt that it is important to let the participants
coach, e.g., a team coach, who is interested in driving things for- know already in the CoP invitation whether decisions will be made
ward in a wider organizational perspective. For example, the in that meeting and on which topic. Then, people who want to par-
Developers’ CoP was lead by a team coach, the End-to-End CoP ticipate in making that decision know to participate.
by the Chief Agile Coach, and the Feature Coordination CoPs were This kind of CoPs or meetings where we want to decide something.
facilitated by one of the team coaches in that area. Usually the invitation will clearly state that ‘‘we would like to have
a decision about this, so if you are passionate about this . . . make
4.2.3. Proper agenda your voice heard’’.
Having a proper agenda for every CoP meeting was highly – Developer 1, Hungary 2013
appreciated. Most often the agenda was sent in the CoP invitation,
which was a calendar invitation send to everybody in the organiza- True. And that’s really the main thing that the invitation directly
tion, and could also be found from the CoP’s wiki page. says that ‘‘we now decide, choose to come or not to come.’’ If you
The agenda sent in the invitation was an important source of choose not to come, then that’s your opinion then. That you relay
information for participants for deciding whether to participate on the others to decide for you.
in that specific CoP meeting at that time or not. If the agenda - Developer 2, Finland 2013
was good, i.e., included interesting and important discussion topics The interviewees did not feel that it was important that all per-
or decisions to be done, it was more probable that an individual sons affected by the decisions participated in making them. As
decided to participate in it. In Feature Coordination CoPs, the everybody is informed about the meeting and the agenda, those
agenda was basically always the same, but also those meetings who are interested and want to participate attend. For example,
informed participants if there was something special on the a Developers’ CoP meeting had around ten participants from four
agenda, e.g., discussion on some special topic or decision making. development teams, when the whole product had almost 40 teams,
The agenda of the most CoPs could be found on the CoP’s wiki our interviewees felt that this CoP meeting was fully eligible to
page, and anybody could add a topic to the agenda in wiki. make decisions:
A good agenda was felt to ensure that something really happens
in the CoP and the participants feel that they gain something from . . .if we can decide with those ten people that this is the direction we
participating in that CoP meeting. Even though everybody could want to go. We can actually be quite sure that the rest will agree, as
add their items on the agenda, it was clear that, in many of the well. But if we can’t agree with ten people that we want to do this,
CoPs, it was the responsibility of the CoP leader to ensure that then we need some more discussion. . . . They [the participants] were
1568 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

passionate. And that’s good for me at least. If you show your interest, wiki page was seen important to CoP success. It was seen as the
then you have the authority decide. If you don’t care. . . well, that’s, most important informing channel that contributes to the
you can choose to do so. . . . It’s really up to. . . yourself to do what transparency.
you want.
There in the Wiki all can access that information, so even though
– Developer, Finland 2013
you might not be able to participate in some CoP during some
However, not all felt that the CoPs had totally solved the deci- week, you can see from the Wiki what decisions were made, how
sion making challenges, instead this could be one area for further things agreed in the previous meeting have progressed. I think it
development in the organization’s CoP culture. has succeeded well, that the information is very transparent, what
happens in the CoPs, that they are not closed Communities cliques.
. . .we still have had problems in decision making. People feel that
Even though I woudn’t visit the Developers CoP at all, so if I follow
the same things are talked over a week after a week. . . . If you have
the wiki page I’m pretty much on the map on what they have
only a democratic approach, it doesn’t work, it is inefficient. You
talked about and decided there.
start to have challenges as people feel that it is not my problem.
It’s the CoP’s problem. But the CoP is only a tool for decision mak- – Developer, Finland 2013
ing, and decision making is often the biggest challenge there.
Besides the wiki, some of the active CoPs had also a mailing list
– Manager, Finland 2013
and a chat channel to discuss topics between the meetings. For
4.2.5. Open community example, the Developers’ CoP had both an active chat forum on
Building a successful CoP requires that a community around the ‘‘Software Craftmanship’’, where developers could discuss their
topic already exists, or can be created. When we asked what people daily issues, as well as a mailing list to discuss broader topics. Hav-
had learned on building CoPs, one of the interviewees replied: ing these active supporting forums were seen as signs of a func-
tioning community.
Maybe the biggest learning has been that just sending invitations
and creating a Wiki page or somethingldots that is not yet a CoP. There in the Wiki all can access that information, so even though
It requires something else to fly. And that else requires preparation, you might not be able to participate in some CoP during some
and some clear, tightly defined topic that enough persons can iden- week, you can see from the Wiki what decisions were made, how
tify themselves. Then it works. But you need to create the things agreed in the previous meeting have progressed. I think it
communityldots has succeeded well, that the information is very transparent, what
happens in the CoPs, that they are not closed communities, cliques.
– Manager, Finland 2013
Even though I wouldn’t visit the Developers CoP at all, so if I follow
First, there needs to be enough people interested in that topic. the wiki page I’m pretty much on the map on what they have
Building a community requires talking to a large number a people talked about and decided there.
and identifying topics and problems that are common to them, and – Developer, Finland 2013
something that they feel they would benefit from discussing and
solving together.
The company culture regarding the CoPs and the attitude on 4.2.7. Suitable rhythm
how much, e.g., individual developers care about the bigger picture Finding a suitable rhythm for the CoP meetings was considered
and participating in common activities counts. important. The suitable rhythm is related to the number of topics
on the agenda. The interviewed CoP leaders saw as their responsi-
I think that everything depends on what people want by them-
bility to take care of that there are a suitable number of interesting
selves, whether they want to participate in, make a change. It
topics on the agenda for every CoP meeting. If that was not the
would be difficult to get anything forward by just booking meet-
case, they would rather cancel a meeting than frustrate the partic-
ings. When people have the power to vote with their feet: ‘‘An invi-
ipants with a poor agenda. They also found it important to adjust
tation came. I couldn’t care less. I’m working now’’.
the meeting rhythm accordingly.
– A developer, Finland 2013
For example, the Developers’ CoP was organized bi-weekly.
As an important part of the company culture our interviewees The leader of this CoP explained that his idea was that this
mentioned the openness of the CoPs. They considered it very CoP should not meet too often, as there are many CoPs and
important that the CoPs do not form into cliques, e.g., groups of other activities that take time from the participants. He even
experts that meet and decide something behind closed doors. commented that if the current bi-weekly rhythm turns out to
Instead, they emphasized that successful CoP culture is open, the be too fast, he is ready to adjust the rhythm to every three
invitation is send to everybody, the agenda and decisions can be weeks or even to every four weeks, or cancel some meetings if
found in the Wiki and persons not in expert positions regarding there is no proper agenda. He felt that it is important to have
the CoP topic are welcomed to join in CoPs to participate or just a good agenda and a proper number of interested people, instead
to listen and learn. of organizing meetings where people could get bored. Therefore
he also emphasized that even though anybody can suggest an
. . .they all have the same principle that all are invited, the whole
item to the agenda, it is important to time-box the items, to pre-
organization, and then anybody can participate. They try to be as
vent discussions to continue for too long.
open as possible so that there wouldn’t form any cliques, because
Most of the CoPs in this organization were organized either bi-
it would mean hidden information.
weekly or weekly. Only a few of the CoPs took place on a need
– Developer, Finland 2013
basis.

4.2.6. Supporting tools to create transparency 4.2.8. Cross-site participation when needed
Most of the CoPs we studied had wiki pages. The CoPs were Some of the CoPs were organized between the sites and some
listed in the organization’s internal wiki, with links to each individ- only inside a single site. The Functional Verification CoPs and the
ual CoP’s pages. On the CoP’s wiki page you could find at least the Coaching CoPs had both site-specific and cross-site instances.
meeting agendas and minutes from the previous meetings, Based on the interviews, it seemed that both cross-site and site-
sometimes also other information. Up-to-date information on the specific CoPs were needed, even though most of the interviewees
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1569

2. Passionate
leader
1. Interesting topic
with concrete
3. Proper agenda
participants

8. Cross-site
4. Decision making
participation when Successful CoP
authority
needed

7. Suitable rhythm 5. Open community

6. Supporting tools
to create
transparency

Fig. 2. Characteristics of successful CoPs.

supported the idea of having mainly cross-site CoPs, if possible. 4.3. The evolution of the role of CoPs
Furthermore, they would have liked to have the other sites more
involved in the CoPs than currently. The reason for this was that In this section, we discuss our findings related to RQ3: How did
the product was common and the issues discussed in CoPs around the role of communities of practice in the case organization evolve
that same product should be effectively shared between the sites. over time? We describe how the role of communities of practice
The cross-site CoP meetings were supported by good quality video- evolved by first growing into a support mechanism for the agile
conferencing spaces. transformation, then supporting scaling, and finally establishing
The biggest challenge the organization had for organizing its place as the main forum for continuos improvement. Our find-
cross-site CoP meetings was the eight hour time-difference ings on the role of CoPs in different transformation phases are
between the newly joined US site and the two other sites. This summarized in Table 5.
made involving that site difficult, as it would require adjustment
to the schedules of participants at all sites, which was not seen 4.3.1. Transformation support
as a possible solution in the long run. Thus, the US site was CoPs were initiated in the case organization as part of the full-
involved in only a few CoPs. scale agile roll-out during 2010, when the whole development
The second reason for not organizing only cross-site CoPs were organization at both sites was restructured into cross-functional
site-specific issues. In particular, all sites had other products in teams. As CoPs were suggested both by the employed consultants
addition to the common one. Thus, some of the interviewees felt and the literature on scaling agile [7,10], building them was seen as
that sharing information between the products inside one site a natural part of the transformation.
and discussing site-specific issues might be beneficial, as well. However, the first steps of this effort were not easy. The organi-
For example the Coaching CoP had started to organize site-specific zation tried to institute CoPs by managerial decision, an approach
meetings at both in Finland and in Hungary, in addition to the that did not turn out particularly well, as illustrated in the follow-
cross-site meetings. A few organizational coaches were shared ing quote:
between the products in Finland, and saw it as an opportunity to
We tried to establish the CoPs by coaches and managers, and we
share knowledge between different products.
thought that this CoP is needed and then we tried to get people
The participation in the CoP meetings both from the Finnish
to join in. But it is a voluntary meeting. People need consider the
and the Hungarian sites were considered similar, i.e., the number
discussions to be interesting or important—then they would show
of participants from each site to the cross-site CoP meetings was
up. We found this empty spot for a few months, before we under-
relative to the number of teams in both countries. A few inter-
stood that CoPs emerge when they are needed. And I think we are
viewees saw a slight difference in the eagerness to participate
still experimenting with that.
in the discussions, as most Hungarians had less experience with
– Manager, Finland 2013
the product and software development in general than the Finns.
Moreover, some interviewees felt that the Hungarian national In the beginning, finding people to build or even participate in
culture might somewhat limit the discussion, e.g., on the prob- the CoPs was difficult, as the understanding of what the CoPs really
lems if managers were present in a CoP meeting, like in the are, and the CoP culture were not yet established in the
End-to-end CoP. organization.
I have a feeling that they (Hunagarians) are not active as they do . . .it was the mindset, the thinking that ‘‘I’’ could participate in any
not have a lot to give. They have only a few years of experience community and contribute. That was not familiar, it was not seen
whereas here people are much more experienced in general. But as an opportunity. It was not seen what ‘‘I’’ could do there. It
they are listening, so that way they will certainly learn. was not concrete enough.
– Product Owner, Finland 2013 – Manager, Finland 2013
1570 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

Table 5
Role of CoPs in different transformation phases.

Phase Transformation Scaling Continuous improvement

Goal of the phase Implementing basic Scrum, broadening the Getting scaling, especially inter-team Applying lean thinking: optimizing the
knowledge in the cross-functional teams coordination, to work whole, end-to-end flow, continuous
improvement
Why CoPs? Literature suggests CoPs CoPs gradually replaced the not so successful Lean suggests continuos improvements
Scrum-of-Scrums as an inter-team coordination and CoPs seem natural fora
mechanism
Level of CoP Learning and practicing what CoPs are and how Experimenting to use CoPs for new purposes CoPs established their place as a central
knowledge do they work fora for a wide range of purposes
What kind of CoPs? Role-based CoPs and CoPs to replace functions CoPs to support coordination and design CoPs aiming to improve the way of
that did not exist anymore in the new between teams developing a common feature working and optimize the end-to-end
organization structure flow
Who were the Managers and coaches Product owners, Scrum masters, coaches Coaches at different levels
drivers setting
up the CoPs?
Examples of CoPs Scrum master CoP, framework CoP, functional Feature design CoPs, feature coordination CoPs End-to-end CoP, coaching CoP,
verification CoP developer’s CoP

As instructed by the consultant literature that the case organi- despite the fact that many teams did not have the required knowl-
zation was using [10,7], the first CoPs were build around specific edge, as there were not enough system designers to assign to all
roles distributed in the cross-functional teams, such as Scrum Mas- teams. The System CoPs were instituted to mitigate these prob-
ters, testers and developers. The cross-functional Scrum teams of lems, and became forums where the few experts and the team
initially 7–8 persons were formed with the idea that all teams members who wanted and needed to learn more could do design
would have ‘‘all needed knowledge’’ to build end-to-end user sto- work together, make design decisions and learn from each other.
ries that would provide value to end customers.
System knowledge is hard to find, . . . so there was a community of
However, in practice this was not possible. The ten-year old
practice established for this system work and now we are trying to
product was so large, complex and built using a large number of
empower people in that group so there are representatives from
components employing different technologies that having single
each team. . .
teams being able to develop any feature would be practically
– Developer, Hungary 2011
impossible. Moreover, having experts on all the components or
even all the previous phases of the development (e.g. system . . .I found it a good idea to have separate . . . to group those people
design and different levels of testing) in every team was not possi- who are interested in the same topic. Because we have cross-func-
ble to accomplish in practice, as some areas had only a couple of tional team . . . It’s really good to have these CoPs, because those
experts. guys who, for example, who are good at systemizing, they can have
During our first two interview rounds it became clear that one discussion together.
of the biggest challenges was that the new cross-functional teams – Manager, Hungary 2011
needed to broaden their knowledge to be fully functional, while at
Third, during the transformation it was noticed that some func-
the same time keep up with the new development. The communi-
tion or organization that had taken care of specific responsibilities
ties of practice provided some solutions to these problems the
in the old organization did not exist anymore. Thus, some of the
organization experienced during the transformation.
CoPs were instituted to handle the work of old functional teams
First, the communities of practice offered a forum, where people
in the old plan-driven world. One example was the Framework
could discuss how to apply agile development in practice and
CoP, which was started in the beginning to take care of the work
together solve challenges related to the way of working. The Scrum
of the old ‘‘Process, Methods and Tools’’ functional organization.
Master CoP was a good example of this kind of community, dis-
The participants of this CoP were the people who had been respon-
cussing and solving day-to-day challenges on applying agile, e.g.
sible for process development in the plan-driven world. However,
sharing good practices on how to arrange retrospective meetings
as the participants were felt to be too disconnected from the actual
in teams.
work, team members did not join the CoP. Instead, it became a
Second, communities of practice were forums in which
meeting for the old process developers only, and did not gain the
cross-functional team members could share and broaden their
momentum needed to survive.
knowledge on specific areas together, and solve problems and
make decisions related to that area. Most of the experts were Some of the CoPs were born as we have previously had some func-
now divided into different cross-functional teams, thus the com- tion or organization that has taken care of some things. When that
munities of practices were natural forums for them to continue didn’t exist anymore, so we created a CoP that takes care of those
working together and make decisions. For example, the Functional things. . . . The Framework CoP is a good example of that kind of
Verification CoP was this kind of forum. CoP. However, it turned out that when it is not clearly part of the
flow of doing things, so . . . it is difficult to accomplish real results.
The functional testers, when they were split into teams, they were
. . . It dried up, it didn’t fly. And it was a good experience to see that
left with this CoP, and it in a way works very naturally, because
too. That this doesn’t work.
before they belonged to the same group and worked together, so
now it is very natural and well-functioning. They share testing – Manager, Finland 2013
issues and make decisions related to testing. The first CoPs that were created during the transformation were
– Scrum Master, Finland, 2011 role-based, like Scrum Master CoP, Functional Verification CoP,
Developers’ CoP and System CoPs. The main purpose of these first
Moreover, as all the teams could not have all kinds of experts, CoPs was learning and knowledge sharing, both regarding the agile
teams were lacking knowledge. For example, the cross-functional practices and broadening the knowledge of the cross-functional
teams were supposed to do system-level design by themselves, teams. This kind of learning and knowledge sharing CoPs are
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1571

exactly what the agile literature suggests. At this phase, it was changing their goals towards organizational development, looking
mainly the managers and later on the coaches that were the main at the organization as a whole.
drivers for setting up the CoPs. As a summary we can see that these The End-to-end CoP was the most self-evident example as it
first CoPs initiated during the early phases of transformation were concentrated on removing the bottlenecks from the flow. Another
important support mechanisms for the transformation. clear example was the Coaching CoP that had moved from sharing
knowledge of the implementation of Scrum practices in teams to
4.3.2. Scaling support advancing organization wide issues and trying to involve the
After the first CoPs supported the transformation by concentrat- whole organization into this development by creating the ‘‘Cool
ing on making the new cross-functional teams fully functional, the Wall’’ and the coaching backlog. Also other role-based CoPs like
next challenge was to get the scaling of agile, especially the inter- the Developer’s CoP aimed at organization-wide improvements.
team coordination to work. These improvement initiatives were more or less led by the coa-
As discussed previously, the main inter-team coordination ches at different level: the head coach was leading the End-to-
mechanism offered by Scrum, the Scrum-of-Scrum meetings, were end CoP, the organization level coaches were driving the Coaching
tried, but the organization wide Scrum-of-Scrum meetings never CoP activities, and a team coach had initiated the reborn Develop-
delivered the expected value, and thus slowly died. This organiza- ers’ CoP.
tion of over 25 teams was just too large for teams to have enough At this phase of the transformation journey the CoPs had clearly
common ground for one common coordination meeting to be established their place as a central fora, that could be used for a
useful. wide range of purposes: for learning and knowledge sharing, coor-
The next attempt, Feature Scrum-of-Scrum meetings, weekly dination and design activities, as well as organizational
coordination meetings between the teams contributing to a com- improvement.
mon feature, were more successful. The scope of these meetings
was limited and the issues discussed were interesting and impor- 4.4. Organizational support for communities of practice
tant to all participants. As the term ‘‘SoS’’ had bad connotations
after the failure of the organization-wide SoS, the Feature SoS In this section, we discuss our findings related to RQ4: How did
meetings were renamed to Feature CoPs. And that is what they the case organization support communities of practice? We present
were: communities of practice concentrating on coordination the two crucial elements of organizational support that we think
between the teams working for a common feature, thus we also enabled the success of the CoPs at Ericsson: a supportive atmo-
refer to them as Feature Coordination CoPs. sphere for CoPs, and infrastructure support.
Feature Design CoPs were partially born out of the early System
CoPs that aimed to make design decisions together, and partly out 4.4.1. Supportive atmosphere for CoPs
of Feature CoP meetings where participants talked also design and Based on our results the main success factor for the CoPs has
architectural issues as part of the inter-team coordination. How- been the supportive atmosphere for building, using and participat-
ever, as it was noticed that persons interested in design and archi- ing in the CoPs. Next, we will describe the three elements
tectural issues were at least partially different than those contributing towards building supportive atmosphere for CoPs:
participating in Feature Coordination CoP meetings it was natural openness of participation, participation valued, and support from
to separate these meetings. In most areas Feature Coordination managers and coaches for building CoPs.
CoP meetings took place weekly, while Feature Design CoPs were
arranged on a need basis. 4.4.1.1. Openness of participation. As a general rule, the CoPs are
In this organization, the main challenge of scaling agile from open to anyone who wants to participate in them. This mindset
one team to several teams, the inter-team coordination, was allevi- can be seen in, e.g., that CoP calendar invitations are send to every-
ated by using CoPs. The Feature Coordination and Feature Design body. Of course, anyone can decline an invitation and not receive
CoPs took successfully care of most of the inter-team coordination invitations to that same CoP anymore. Our interviewees empha-
tasks. This, finally well-functioning support structure, was not sug- sized this openness of the participation in the CoPs. They said that
gested by the literature or consultants, but was gradually born out it is important that CoPs do not become meetings for only a select
of the need to solve a problem. As could be seen, it took several group of experts, or ‘‘gurus’’, because then cliques might start to
attempts and trials before the organization ended up to the current form. Instead, the current CoP culture emphasizes that anybody
structure. Thus, the drivers setting up these CoPs were no-longer can participate in any CoP, and that people can join in CoP meet-
managers, but those who saw the need: Product Owners, Scrum ings just to learn and to know what is going on, i.e., you do not
Masters, Coaches and team members. have to be an expert on the topic to join in. It is also acceptable
At this stage of the transformation, the idea of CoPs was not to participate in CoP meetings irregularly, e.g., when the agenda
new to the organization, but a well-functioning mechanism, thus contains a topic you are interested in, or you just happen to have
it was a natural to try it for new purposes. time. Several interviewees mentioned that they participate irregu-
larly in some CoPs, depending on the topic and their other work
4.3.3. Continuous improvement support engagements.
When the main challenges of the transformation and scaling
agile were solved, the organization continued their lean and agile 4.4.1.2. Participation valued. It is fully acceptable for a person to
journey by focusing on the lean side of the transformation. They spend as much time in CoPs and participate in as many CoPs he
started to look at the end-to-end flow, from requirements until or she deems necessary. Instead of being viewed by fellow team
they were implemented as part of the product, with the goal of members as waste, CoP participation is valued by the colleagues.
optimizing the whole. Nobody forces or asks anybody to participate in any CoPs either,
Lean thinking emphasizes continuos improvements, and CoPs the participation is on voluntary bases. The Feature CoP meetings
seemed to be natural fora for that. Most CoPs had actually already are the only ones to which each team working on that feature
from the beginning contributed to continuous improvements sends their representative or representatives. Each team chooses
to the way-of-working. However, we noticed a clear change: their representative to these meetings and our interviewees
when the most burning transformation related problems that mentioned that it is not a problem to find a volunteer or volunteers
affected the day-to-day activities were solved, many CoPs started for that either.
1572 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

The idea there is that they (CoPs) are on voluntary bases, that people 4.5. CoP purpose classification
who have passion to influence on things, to discuss with each other,
and to make decisions they go to the communities of practice. In this section we answer the RQ5: How could the different pur-
– Coach, Finland 2013 poses of communities of practice be classified?
Based on CoP purpose we did a preliminary classification of
In principle, we have so many CoPs that you can just spend your
CoPs in the case organization. The purpose of this classification is
time only in the CoPs, so everybody participates in what he feels
to clarify the understanding on the purposes of CoPs in lean and
as the most interesting and important for himself.
agile software development.
– Developer, Finland 2013
We found the following four different purposes for CoPs: (1)
When we asked our spring 2013 interviewees how many CoPs knowledge sharing and learning, (2) coordination, (3) technical
they normally participated in, most reported that they participated work, and (4) organizational development, as summarized in
in 2–3 CoPs per week. However, as our interviewees were active Table 6. Next, we will briefly explain each of these purposes and
members of the community and even the developers we inter- give examples from the case organization. Even though these four
viewed were part-time coaches, they most probably participated purposes are clearly different, we can see that many of the CoPs
in more CoPs than regular team members. One of our interviewees had characteristics of a few of them.
mentioned that approximately one third of the people in the orga-
nization are active in that sense, and want to make difference, 4.5.1. Knowledge sharing and learning
change things, and thus participate actively in CoPs as well. For many of the CoPs, our interviewees state that knowledge
sharing and learning was the basic purpose. This is also the most
I would say that it is around 30 percent of the whole organization
typical rationale for creating CoPs according to the literature [13].
who thinks this (the lean and agile transformation) is ‘‘the’’ impor-
In our case organization the best example of this type of a CoP
tant thing for them. And they participate in this kind of meetings
was the Coaching CoP, as the main purpose of it was especially in
(CoPs) a lot.
the early phases of the transformation exactly that: to share expe-
– Manager, Finland 2013
riences on how to implement agile from different teams and try to
find solutions to problems together. The coaching community even
4.4.1.3. Support from managers and coaches for building CoPs. Even arranged regularly another meeting called ‘‘Coaching Guild’’ to
though we could see from the initial steps that managers should study new material together.
not force CoPs to be build, but CoPs should just emerge when there Other examples of knowledge sharing and learning are the
is a need, our interviewees emphasized that especially in the begin- other role-based CoPs that were build as forums for specific roles
ning a lot of support and encouragement is needed. When people do in different cross-functional teams to share knowledge, e.g., Devel-
not clearly understand what a CoP is and what is it for, the CoPs do opers’ CoP and Functional Verification CoP.
not just emerge. During our interviews we could hear that building Actually, we could say that all the CoPs have at least to some
and leading a new CoP was clearly highly valued, those individuals degree knowledge sharing and learning as one of their purposes.
who took responsibility of building a new CoP were appreciated
both by the managers and peers. Moreover, we noticed that many 4.5.2. Coordination
of the CoPs were led and supported by coaches, e.g. by a team coach, Our respondents deemed inter-team coordination to be the
head coach, or community coach. Thus, the coaching community main purpose of certain CoPs, called Feature Coordination CoPs.
had clearly taken CoPs as part of their responsibility. In the Feature Coordination CoPs several cross-functional teams
working inside one product area, or a feature meet and coordinate
4.4.2. Infrastructure support their work. The Feature Coordination CoPs were formed when the
The organization provided several types of infrastructural sup- inter-team coordination mechanism offered by the Scrum method,
port for both collocated and distributed CoPs, for example: video- the organization-wide Scrum-of-Scrum meetings, were tried, but
conference, wiki, and chat. As many CoPs were distributed did not bring the expected benefits.
between sites, our interviewees saw the well-functioning video- The first step was to start Feature specific Scrum-of-Scrum
conference system as the most important infrastructure need for meetings where each team developing that feature was
the CoPs. This need had been well taken care of in the case organi- represented, and this representative answered the three Scrum
zation. The organization had a large number of meeting rooms at questions regarding their team. The Feature Coordination CoPs
all sites that had been equipped with high quality videoconferenc- were based on the same idea, but over the time, the format offered
ing equipment. These rooms had microphones hanging from the by Scrum, started to change from a reporting meeting towards a
roof, making it irrelevant where in the room the speaker sits, as discussion meeting, where coordination issues were discussed,
the audio quality is excellent regardless of physical location in not only raised.
the room. The videoconferencing rooms have enabled effective dis-
tributed CoP meetings, and are in very frequent use. 4.5.3. Technical work
These videoconferences are the best thing ever! . . . Earlier we had Another important purpose of CoPs according to our respon-
normal phone conferences with poor quality cracking voice. . . . dents is to work, design and make demanding design decisions
Now when we have this surround environment and sharp voices, together. The earliest CoPs of this type in our case organization
and you actually see the voices and can even follow the movements were the System CoPs that aimed to gathering together a group
of the mouth that what a person is saying on the other end. This has
been a really big improvement, this videoconference. Table 6
– Developer, site a 2013 CoP purposes in the case organization.

Besides videoconferencing, the CoPs actively use the organiza- Purpose Example
tion-wide wiki. Most of the CoPs have their own wiki pages with Knowledge sharing and learning Role-based CoPs
meeting agendas and minutes, as well as other information. Some Coordination Feature coordination CoP
of the CoPs even have their own chat forums and mailing lists that Technical work System CoPs
Organizational development End-to-end CoP
anybody could join.
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1573

of individuals who could do the system design together, as all The Developer CoP was an organization-wide role-based CoP
teams did not have enough system knowledge. Later on, the Fea- that initially run into problems due to the lack of a CoP culture.
ture Design CoPs had the same idea, but their main aim was to When later restarted, it had a passionate leader, focussed on soft-
make high level design and architectural decisions together with ware craftmanship and tools and was considered successful.
all the teams involved in that specific product area. Sometimes The End-to-End CoP gathered together people from a wide vari-
even experts from a related area were invited. ety of roles to work on improving the overall product development
flow across team and product area boundaries. The main purpose
of this CoP was thus organizational development. The fact that
4.5.4. Organizational development
the CoP had participation from both managers and practitioners
Organizational development, i.e., developing the way of work-
and had decision making authority facilitated fast decision making
ing in the organization is another purpose of CoPs.
and problem solving.
The End-to-End CoP was a perfect example of this kind of a CoP
in our case organization. It aimed at look at the product develop-
ment flow through the whole organization, and to optimize the 5.1.2. RQ2: What were the characteristics of successful communities of
flow by together removing the bottlenecks. For this kind of a CoP practice?
it was important that all organizational levels and parts were rep- We identified eight characteristics of successful CoPs. First, a
resented in the CoP, so that sub-optimizations could be avoided CoP needs an interesting topic, which is important to a group
and that the CoP could make or at least take care of that all the of people big enough, and the participants of the CoP need to
needed decisions are made. get some concrete benefits for their daily work from every single
Organization development was one of the main purposes of also CoP meeting. Second, every CoP needs a passionate leader or
the Coaching CoP and the Developers’ CoP. Developers’ CoP aimed facilitator that takes care that CoP meetings have a proper
to improve the level of Software Craftmanship and make the agenda and contents and that the discussions are not endless.
needed decisions to align ways of working at the software develop- Third, a good agenda that is distributed before the meeting
ment level. and that everybody may contribute to is an important factor
for people in deciding whether to participate or not. Fourth, a
CoP need to have decision making authority on the matters it
5. Discussion handles. Fifth, each CoP needs a community around it, which
is open and transparent. Sixth, CoPs need some tools to build
5.1. Summary of the findings organizational memory and transparency, e.g. wiki. Seventh,
CoPs should have suitable meeting rhythm. It might be better
In the case organization, CoPs evolved into a valuable mecha- to cancel a meeting rather than hold one without proper discus-
nisms for knowledge sharing, inter-team coordination and com- sion topics. Eighth, a distributed organization should enable
munication, technical work and organizational development. The cross-site participation to CoPs to share learning and align the
various CoPs became a central mechanism behind the success of whole organization. For site specific topics, local CoPs might be
the large-scale agile implementation in the case organization and considered.
helped to mitigate some of the most pressing problems of the agile These success criteria match well with the literature (cf. [13]),
transformation. Next, we summarize and discuss our findings with the exception of decision making authority, which the litera-
related to the research questions. ture did not mention. Decision making authority and the sense that
the people participating in the CoPs were trusted to make binding
decisions was considered very important for the success of the
5.1.1. RQ1: What kinds of communities of practice were created in the
CoPs. Comparing the success factors to Table 2, Ericsson seemed
case organization and how did they evolve over time?
to follow all of Wegner’s principles for cultivating communities
The case organization had tens of different CoPs, and had cre-
of practice.
ated a culture in which CoPs were formed as needed, and ceased
to work when they either were dysfunctional, or had fulfilled their
purpose. We chose four CoPs for deeper study, based upon the fact 5.1.3. RQ3: How did the role of communities of practice in the case
that the authors and interviewees jointly deemed them both inter- organization evolve over time?
esting and successful: Coaching CoP, Feature CoPs, Developers’ CoP, The needs with respect to CoPs might change over time. In the
and End-to-End CoP. We described how each of these CoPs were beginning of the agile transformation, CoPs had an important role
created and evolved over time. in supporting the transformation, especially by broadening the
These CoPs, their evolution and purposes differ. In particular not knowledge in the cross-functional teams and sharing tips on how
all CoPs were only about learning and knowledge sharing. CoPs had to implement Scrum.
three main roles: to support the agile transformation, to be part of After basic Scrum was working in the cross-functional teams,
the large-scale Scrum implementation, and to support continuous the next challenge was to support scaling, especially inter-team
improvement. coordination. During this phase, the CoPs gradually replaced the
The Coaching CoP was an example of a role-based CoP, the ori- not so successful Scrum-of-Scrums as an inter-team coordination
ginal main purpose of which was knowledge sharing and learning. mechanism.
This represents the perhaps most typical uses of CoPs. However, Next, the organization concentrated on continuos improve-
during the timespan of the study, we could see a slight change of ment, i.e., developing and fine-tuning the way of working. The
the purpose of this CoP–at the time of our last interviews it CoP turned out to be excellent forums for initiating and agreeing
was taking clear steps towards contributing to organizational on improvements as persons eager ‘‘to make a difference’’ from
development. different parts of the organization participated these CoPs.
The Feature CoPs were created to provide a solution to the prob- While the literature on CoPs (e.g. [13]), acknowledges that both
lem of dysfunctional organization-wide Scrum-of-Scrums. The CoPs and their role evolve over time, we think that this particular
main purpose of the Feature Coordination CoPs was coordination instance is interesting in how it illustrates the roles of CoPs in
between the teams working in the same product area, whereas large-scale agile transformation: from dealing with basic opera-
the Feature Design CoPs focussed on technical product design. tional level issues to organizational development.
1574 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

5.1.4. RQ4: How did the case organization support the communities of 1. CoPs can support a Lean and Agile transformation. This case study
practice? shows that CoPs can be used effectively as a support mecha-
According to our results the main success factor for the CoPs nism during a large-scale Lean and Agile transformation, as they
was the supportive atmosphere for building, using and participat- provide a forum to discuss the transformation, plan continuous
ing in the CoPs. We identified three elements contributing towards improvements to the way-of-working, and share knowledge
building supportive atmosphere for CoPs: openness of participa- and tips regarding working practices between the roles and
tion, participation valued by the organization, and managers and teams. Our study suggests that organizations wanting to do
coaches support in building. In addition, infrastructure support, an organizational transformation can use CoPs as an effective
including e.g., wikis and videoconference facilities for distributed mechanism to support the change.
CoPs, is needed. 2. CoPs can support scaling agile to a large and distributed organiza-
Developing an atmosphere that provides a fertile ground for tion. Basic Scrum [24] does not offer support for large-scal
CoPs does, however, require strong management support, as well cross-team coordination. This case showed that CoPs can help
as both time and patience. Initially, people in the organization provide what is missing from Scrum, i.e., efficient coordination
did not understand why they should partake in the CoP meetings, and knowledge sharing mechanisms between the teams, as well
and what the meetings were supposed to accomplish. The first as between the experts in the teams. Furthermore, our study
CoPs were formed by management and the coaches, but slowly shows that large and complex product might be supported by
the organization as a whole started to understand the idea behind product area or feature based CoPs rather than basic Scrum-
CoPs, and how to create and utilize them in the best way. Manage- of-Scrums.
ment learned that CoPs should not be created by management 3. Building a CoP-friendly corporate culture is important. In order for
decision, but by creating a supportive atmosphere, as well as sup- CoPs to work in an organization, suitable organizational support
porting infrastructure. The organization created a culture in which is required. To support the creation and evolution of CoPs as
CoPs and participation in them was appreciated, by having open part of the way of working, you should build a supportive atmo-
CoPs with invites sent to all, and by creating transparency into sphere for CoPs, give them the necessary empowerment, as well
the CoPs. as offer infrastructure support. Without this, CoPs might not
The organization learned that CoPs cannot be kept alive artifi- emerge and grow well.
cially. To successfully form a CoP, a community needs to be
built—just communicating to the whole organization that there is For practitioners working in the organization, we derive at least
a new CoP does not work. On the other hand, the term CoP was also the following practical implications:
used for single or a series of ad-hoc meetings that required a group
of people to come together to solve a common problem. After the 1. Participate in CoPs and create a new one when needed. If your
problem was solved, the ad-hoc CoP was dissolved. organization supports CoPs and you see a problem or opportu-
Our findings here match well with Wenger’s [13] observations, nity that needs to be addressed outside of your own team con-
as he emphasizes shepherding rather than creating CoPs. text, consider taking it up in an existing CoP or form a new one
to deal with the issue, as well as similar ones.
2. Use CoPs to learn and further your career. Utilize CoPs to keep up-
5.1.5. RQ5: How could the different purposes of communities of
to-date about what happens in the organization at large, and to
practice be classified?
deepen and broaden your own product, technical and process
We presented a classification of CoPs based on their purpose. In
knowledge.
our case organization, we found four main purposes for CoPs: (1)
3. Influence the organization via CoPs. CoPs are empowered to make
knowledge sharing and learning, (2) coordination, (3) technical
decisions in their area of concern. By actively participating you
work, and (4) organizational development. Even though these four
can improve and influence even organization-wide issues.
purposes are clearly different, we can see that many of the CoPs
had characteristics of a few of them.
Knowledge Sharing and Learning, the basic idea behind CoPs,
5.3. Generalizability and threats to validity
was a goal, at least implicitly, in all CoPs we studied. Several CoPs
were involved in organizational development, as well. The techni-
This paper presented a single case study on how a large, glob-
cal work, on the other hand, was a very specific purpose: designing
ally distributed software development organization built commu-
together and making demanding product design decisions together
nities of practice as part of their lean and agile transformation.
across team borders. The coordinating work between the teams
The generalizability of the results to other contexts is likely
was also a quite a specific purpose, that some CoPs had as their
limited.
main purpose, e.g. Feature Coordination CoP, but others as one of
We rely on the definitions of validity and reliability proposed by
their minor purposes, e.g. Developer’s CoP.
Yin [22]. Internal validity is not relevant, as this research is a
We think that this classification can help us understand the
exploratory case study [22].
roles CoPs can have in large-scale agile software development, in
The main threat to the construct validity of this research was
various stages of the transformation. While Wenger [13] recog-
the accuracy of the descriptions of the studied phenomena. During
nizes that CoPs can have a wide range of roles, the breadth of roles
the spring 2013 interviews we concentrated on CoP, however,
CoPs had at Ericsson – from coordination to creative technical work
then the number of people interviewed was only eight. These
– was quite interesting.
interviews were extremely fruitful, but having a larger number of
interviews, and having interviewees from a bigger number of CoPs
5.2. Practical implications could have given us a broader view, as the organization had over
twenty CoPs. There is a possibility of positive selection bias with
In this section we briefly describe the main practical implica- respect to the CoPs that might skew the results, since the CoPs to
tions of our research, divided into two categories: organizational study was selected jointly with management at the case organiza-
and management implications, and implications for practitioners. tion. Moreover, most of the spring 2013 interviews were conducted
At the organizational and management level, we have three in Finland, only one in Hungary, and we did not have access to the
main implications: US site. Having a better representation of these two sites would
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1575

have given a better understanding of the current situation regard-  What kind of training have you had on Lean and Agile
ing CoPs in the organization. software development? Would you have needed more
To increase the construct validity we took several actions: First, training?
we used multiple sources of evidence: we interviewed multiple 2. Agile and lean transformation
persons from different roles, as well as observed actual CoP meet-  Why was the transformation started?
ings. Second, the interviews were analyzed together by both  Explain the timeline of the transformation.
authors. Third, all the informants of the two first interview rounds  Why did you choose Scrum? Why Lean?
were invited to a feedback session, where the results were pre-  What comes from Scrum in your way-of-working? What
sented, and the first draft of this paper was reviewed by the key comes from Lean in your way-of-working?
informants.  What is still left from the waterfall model?
The external validity of a case study concerns the domain to  What kind of training have you arranged? By whom? To
which the results can be generalized [22]. Based on our study, we whom?
can hypothesize about the significant characteristics of the domain.  What are you still planning to change/improve?
First, the system under development was large, multifaceted and  What is your general feeling of the transformation?
technically demanding. Second, the case organization was trans- Good/bad/challenges? How have you solved the
forming from a waterfall type process to agile development. Third, challenges?
the number of development teams was relatively large. Fourth, the  What would you have done differently? How?
development was distributed to three geographical sites. The  Has Lean and Agile solved the challenges you wanted to
results are likely generalizable to single site development, but it solve by this change?
is difficult to hypothesize how generalizable the results are when  How have you measured the change? What have you
the development is distributed to a larger number of sites. exactly measured? How does this change look according
The main threat to the reliability of this research is the variabil- to your measurements?
ity in the data collection. The data collection was conducted using 3. Organization structure
the general interview guide approach [29], which introduced vari-  How does your organization look like? (draw a picture!)
ability to the topics discussed in the interviews. However, the large  How has the agile transformation affected the roles and
number of interviewees and multiple interviewers allowed data responsibilities?
source and investigator triangulation [29] which increased the reli-  What roles do you currently have in your organization?
ability of the results. Are the following roles and their responsibilities clear:
Project Manager vs. Scrum Master vs. Product Owner
5.4. Future research vs. Proxy Product Owner vs. Program Manager? Are the
roles clear in your organization? Are there challenges/
In this case study, we got a preliminary understanding both of improvement needs regarding these roles or their
the role CoPs can play in agile adoption and implementation in a application?
large organization, as well as related challenges and success fac-  Comment on the organization structure: Good?/improve-
tors. However, additional data is needed both to confirm these ment needs? Do you still plan to change something
results, as well as to better understand the contextual factors, such regarding the organization structure?
as role of the existing organizational culture and structure, the role  How many persons do you have at the moment at each
of national culture, products, etc. site? How many teams at each site? What are the team
In the immediate future we will continue to longitudinally sizes at the different sites?
study the CoPs at Ericsson, both related to this particular product,  How are responsibilities divided between the different
as well as in other products. In addition, we plan to study another sites? Do you have different kind of tasks/roles at differ-
large organization in the same industry sector, using interviews ent sites? When did Hungary join in? Why?
and observations as our main method. In order to get a better  How do you take care of the collaboration, communica-
understanding of the contextual factors affecting the use and value tion and division of tasks between the sites? How does
of CoPs in large-scale agile development, organizations in other it work? Good?/improvement needs?
sectors and countries should also be studied, using e.g. survey  Do different teams have different roles?
instruments or case studies by other researchers.  Feature teams: What kind of knowledge/‘‘roles’’ do you
have in each team? Good?/challenges? What have you
Acknowledgements done to solve the challenges?
4. Coaching
We would like to thank Oy LM Ericsson Ab for making this  External coaching: What kind of coaching/consulting
study possible and all the anonymous interviewees and persons have you had to support the transformation?
who gave us feedback for providing valuable contributions to this  What kind of training have you arranged?
research. This work was supported by Tekes as part of the Cloud  Have you had internal coaches? If yes, tell more about
Software Finland program of DIGILE (Finnish Strategic Centre for their role and tasks.
Science, Technology and Innovation in the field of ICT and digital 5. Team-level Scrum practices
business).  Your own team: team size, what does your team do, con-
nections to other teams?
 Scrum practices of your team (explain all Scrum practices
Appendix A. Interview questions your team uses)
 What is the length of your iterations? What is your opin-
A.1. Transformation questions ion on the iteration length? Explain.
 Cross-functional teams: How has the idea of the cross-
1. Background functional teams worked out? Why?/why not?
 What is your role, background and experience at  Tell about the communication inside your team. Good/
Ericsson? bad/improvement needs?
1576 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577

 How and when do you communicate with other teams?  Feature SOS – Have you participated? If yes, to which feature
 Do you know enough on what is happening in the other SoS? How did to work? Good/challenges?
teams/elsewhere in the project? Is there something that  Do you still have SoS? If, yes, what kind?
you would need to know more? What? Why? 3. (Only to managers) CoP culture
 How does the global distribution affect your daily work?  How did you start building CoPs?
 What is working well in you team/regarding your team  How have you supported building CoP?
practices? What are the biggest problems? What should  How have you built ‘‘the CoP culture’’?
be improved? How?  What has been challenging in building CoPs/CoP culture?
6. Improvement suggestions  What are the most successful CoPs? Why?
 Is there something that should be improved in this 4. CoPs:
project?  Which CoPs do you currently have? Which CoPs have you
 How? had previously? Which CoPs have disappeared? Why?
7. Tools:  When did you start building CoPs? Why did you start build-
 What are the most important tools that you use? ing CoPs?
 Tell a bit about each tool (for what is it used, who are  What is the difference between SoS and CoPs?
using it, etc.) Good?/Bad?  How is a CoP born? How does a CoP die/is terminated?
8. Scaling agile/cross-team coordination practices  What kind of a CoP is successful? Why? What makes a CoP
 What are your current scaling/cross-team coordination well-functioning?
practices?  What kind of CoPs have not been not successful/well-func-
 Scrum-of-Scrums? CoPs? Feature Owners? Tell about tioning? Why?
each practice. 5. Your own CoP participation
 How have you taken into account the global distribution  Which CoPs do you participate in? Or have participated?
in cross-team coordination? How do you handle commu-  Tell about each CoP you have participated in: the purpose of
nication? Tools used to support the communication and that CoP, what happens in that CoP, who are the participants,
coordination? What kind of challenges have you what is your general feeling of this CoP, positive/negative
experienced? experiences
9. Measuring  How does the global distribution affect on the CoPs? Experi-
 What do you measure? ences with Hungary/Finland/US? Your general feelings on
 How do you measure quality? Productivity? How has this the distributed CoPs? Success/challenges? How well differ-
changed compared to the way of working before the ent sites participate in distributed CoPs (Hungary/Finland/
transformation? US)? Arranging CoPs over videoconference, how does that
 What should be measured? Why? work?
10. Product management  Wiki: How is wiki used in the CoPs you have participated in?
 How is product management taken care of? What kind of information can be found from the CoP wiki
 Where do you receive the requirements? Describe the pages?
whole flow from the customer request to the require-  CoP invitations?
ment being part of the product.  How would you improve the CoPs you participate in? How
 How is customer communication taken care of? would you improve the CoP culture/support for building
 What does the product owner do? What does the proxy CoPs?
product owner do?
 Communication between the product owners/proxy References
product owners? Communication with the teams?
 How is work divided between teams? Who does that? [1] K. Schwaber, M. Beedle, Agile Software Development with Scrum, Prentice-
 What are the current challenges of product Hall, Upper Saddle River, NJ, 2002.
[2] VersionOne, Inc., 6th Annual State of Agile Development Survey, 2011. <http://
management? versionone.com/state_of_agile_development_survey/11/>.
11. Opinions [3] C. Larman, V.R. Basili, Iterative and incremental development: a brief history,
 How do you think that the Lean and Agile transformation Computer (2003) 2–11.
[4] A. Cockburn, Agile Software Development, Addison-Wesley, Boston, MA, 2002.
has succeeded? [5] B.W. Boehm, R. Turner, Balancing Agility and Discipline: A Guide for the
 How do you think that Lean and Agile software develop- Perplexed, Addison-Wesley Professional, 2004.
ment fits in your organization? What are the benefits is [6] M. Lindvall, D. Muthig, A. Dagnino, C. Wallin, M. Stupperich, D. Kiefer, J. May, T.
Kahkonen, Agile software development in large organizations, Computer 37
brings? What are the challenges? Has your opinion (12) (2004) 26–34.
towards the Lean and Agile changed somehow during [7] D. Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises,
the transformation? Addison-Wesley Professional, 2007.
[8] E.C. Lee, Forming to performing: transitioning large-scale project into agile, in:
 What advice would you give others considering the
Proceedings of the Agile 2008, AGILE ’08, IEEE Computer Society, Washington,
application of Lean and Agile to a similar situation? DC, USA, 2008, pp. 106–111.
 What are your expectations towards our research? [9] M. Paasivaara, S. Durasiewicz, C. Lassenius, Using scrum in distributed agile
development: a multiple case study, in: Proceedings – 2009 4th IEEE
International Conference on Global Software Engineering, ICGSE 2009, 2009,
A.2. Communities of practice questions pp. 195–204.
[10] C. Larman, B. Vodde, Practices for Scaling Lean & Agile Development: Large,
1. Background Multisite, and Offshore Product Development with Large-Scale Scrum,
Addison-Wesley Professional, Boston, MA, USA, 2010.
 What is your role, background and experience at Ericsson? [11] E. Hossain, M.A. Babar, H.-y. Paik, Using scrum in global software
 Of which CoPs do you have experience? development: a systematic literature review, in: Proceedings of the 2009
2. Scrum-of-Scrums Fourth IEEE International Conference on Global Software Engineering, ICGSE
’09, IEEE Computer Society, Washington, DC, USA, 2009, pp. 175–184.
 Project wide SOS – Have you participated? How did it work? [12] E. Wenger, Communities of Practice: Learning, Meaning, and Identity,
Good/challenges? Cambridge University Press, 1998.
 M. Paasivaara, C. Lassenius / Information and Software Technology 56 (2014) 1556–1577 1577

[13] E. Wenger, R. McDermott, W.M. Snyder, Cultivating Communities of Practice, [24] K. Schwaber, Agile Project Management with Scrum, Microsoft Press,
Harvard Business Review Press, Cambridge, MA, 2002. Redmond, Washington, USA, 2004.
[14] C. Fry, S. Greene, Large scale agile transformation in an on-demand world, in: [25] K. Schwaber, The Enterprise and Scrum, Microsoft Press, Redmond,
Agile Conference (AGILE), 2007, pp. 136–142. http://dx.doi.org/10.1109/ Washington, USA, 2007.
AGILE.2007.38. [26] M. Paasivaara, C. Lassenius, V.T. Heikkila, K. Dikert, C. Engblom, Integrating
[15] G. Benefield, Rolling out agile in a large enterprise, in: Proceedings of the 41st global sites into the lean and agile transformation at Ericsson, in: 2013 IEEE
Annual Hawaii International Conference on System Sciences, 2008, pp. 461– 8th International Conference on Global Software Engineering (ICGSE), 2013,
461. http://dx.doi.org/10.1109/HICSS.2008.382. pp. 134–143.
[16] E. Wenger, R. McDermott, W.M. Snyder, Communities of practice: the [27] M. Hallikainen, Experiences on agile seating, facilities and solutions: multisite
organizational frontier, Harvard Business Rev. (January–February) (2000) environment, in: 2011 6th IEEE International Conference on Global Software
139–145. Engineering (ICGSE), 2011, pp. 119–123. http://dx.doi.org/10.1109/
[17] E. Lesser, J. Storck, Communities of practice and organizational performance, ICGSE.2011.20.
IBM Syst. J. 40 (4) (2001) 831–841. [28] V.T. Heikkilä, M. Paasivaara, C. Lassenius, C. Engblom, Continuous release
[18] A. Mestad, R. Myrdal, T. Dingsoyr, T. Dyba, Building a learning organization: planning in a large-scale scrum development organization at Ericsson, in:
three phases of communities of practice in a software consulting company, in: Agile Processes in Software Engineering and Extreme Programming, in: H.
40th Annual Hawaii International Conference on System Sciences, 2007 (HICSS Baumeister, B. Weber (Eds.), Lecture Notes in Business Information Processing,
2007), 2007. vol. 149, Springer, Berlin Heidelberg, 2013, pp. 195–209.
[19] T. Kahkonen, Agile methods for large organizations – building communities of [29] M.Q. Patton, Qualitative Evaluation and Research Methods, second ed., Sage
practice, in: Agile Development Conference, 2004, pp. 2–10. Publications, Newbury Park, Calif., 1990.
[20] P. Gongla, C. Rizzuto, Evolving communities of practice: IBM global services [30] M. Miles, A. Huberman, Qualitative Data Analysis: An Expanded Sourcebook,
experience, IBM Syst. J. 40 (4) (2001) 842–862. second ed., Sage Publications, Thousand Oaks, CA, 1994.
[21] T. Chau, F. Maurer, Tool support for inter-team learning in agile software [31] J. Corbin, A. Strauss, Basics of Qualitative Research, third ed., SAGE
organizations, Lecture Notes Comput. Sci. 3096 (2004) 98–109. Publications, Thousand Oaks, CA, USA, 2008.
[22] R.K. Yin, Case Study Research: Design and Methods, fourth ed., SAGE [32] T. Jick, Mixing qualitative and quantitative methods: triangulation in action,
Publications, Thousand Oaks, CA, USA, 2009. Admin. Sci. Quart. 24 (4) (1979) 602–611.
[23] M. Poppendieck, M. Cusumano, Lean software development: a tutorial, IEEE [33] C. Ladas, Scrumban: Essays on Kanban Systems for Lean Software
Softw. 29 (5) (2012) 26–32. Development, Modus Cooperandi Press, Seattle, WA, USA, 2008.