Large-scale agile transformation at Ericsson: a case study

We conducted a total of 45 semi-structured interviews in three rounds: 1) 31 interviews on the transformation journey, 2) twelve interviews on value workshops (which were one of the major steps during the transformation journey described later on), and 3) two validation interviews after analyzing the data.

The goal of the transformation interviews was to study the large-scale agile adoption. During that first interview round we conducted 31 interviews of altogether 34 persons at four sites.

The roles of the interviewees included development team members (i.e., members of agile teams such as developers and testers), Product Owners, coaches and managers. We aimed to interview a broad representation of the organization, talking to informants in different roles, with various backgrounds and representing different organizational levels in order to gain as complete a view of the situation as possible. We mainly selected persons with long experience with the organization to be able to reflect the whole transformation journey, but also a few persons joining later on to give us another perspective. Many of the interviewees had a long background at Ericsson. About half had joined Ericsson over ten years ago. 2/3 of the interviewees had joined the studied case project over a year before our interviews and only 1/3 had less than a year of experience from the case project. A bit more than half of the interviewed persons had a background in agile methods before joining the project, and around half of them had transferred to the project from the first agile project at site A, reported in (Paasivaara et al. 2013). All interviewees were selected with the help of case organization representatives. The interviews typically lasted one hour, but the length ranged from half an hour to two hours. Especially for the few first interviews, we reserved more time, as we asked more background questions in order to understand the history of the organization and the starting point of the transformation. These early interviewees were managers and coaches, who had a broader overview of the organization. The subsequent interviews were focused on the transformation and were somewhat shorter. During the first interview round, two researchers participated in all interviews, one being the main interviewer (Author 1, in a few interviews Author 3) and the other one taking detailed notes, as well as asking additional questions (Author 2).

During the first interview round we learned that the organization had started to define common values, and would be working further with these values in workshops. The common values and the related value workshops were an important step during the transformation journey, which was the reason why we decided to study them further. We had a possibility to participate as observers in both workshops and, after the second workshop, interview 12 participants from three different sites. This formed the second interview round. These interviews were short, ranging from 15 to 30 minutes each. The interviewees ranged from team members to managers. These interviews were conducted by a single researcher (Author 1), who selected the interviewed persons amongst the workshop participants.

During the third interview round two interviews were done to validate our results after we had analyzed the data. The first interview took place after we had analyzed the data from the first interview round and the second one after analyzing the second round interviews. The main purpose of these interviews was to deepen our understanding about topics that emerged when analyzing the data, as well as validate that we had understood particular issues correctly, e.g, the product structure. In the first of these interviews two researchers and two interviewees were present and in the last one, one researcher and one interviewee. These interviewees were selected as they had a broad view of the whole organization and were actively involved in the transformation in the whole organization in their roles as line manager, project steering committee member and organizational coach.

The number of interviews and interviewees differ, as in two interviews we had two interviewees and in another three. The multi-person interviews during the first interview round were due to interviewee time limitations. For example, we could have interviewed only one of the three coaches (who had been doing exactly the same work) and only one of the consultants (also working tightly together), but the interviewees suggested group interviews to which we agreed, as we thought it would give us a broader picture than conducting single person interviews. In addition, in the last validation interview we had two interviewees, with whom we checked our results and asked clarifying questions.

During the two first interview rounds we used an interview guide approach with predetermined topics as suggested by Patton (1990). The main topics were the same for each interviewee but the questions were adjusted based on their position and background. Table 1 shows the roles interviewed and the interview guides can be found in Appendix A and B.

All interviews were conducted face to face in the organization’s facilities and recorded. The recordings were transcribed by a professional transcription company.

As part of this study, we visited all the European sites (A, B, C, D). Unfortunately, due to budgetary restrictions, we were not able to visit the Asian subcontracted site (E), but were able to interview one representative of that site who temporarily was located at site D. Except for that one interview, the data we have on site E are the descriptions given by people at sites A, C, and D who closely collaborated with that site. However, our results focus on the main internal sites (A, B, C and D), as this was where the large-scale agile transformation took place. Site E as an external site, was not actively included in the transformation, and the plan was to drop the site in the near future.

To support the interviews, we conducted five observation sessions of altogether 31,5 hours during seven days. The events observed were selected carefully to support our study: 1) to see in practice how the basic Scrum practices were implemented in the case organization we observed how a Scrum team performed the activities related to a sprint change: sprint review, retrospective and sprint planning. 2) To understand how the major coordination events worked in practice, we observed the weekly Product Owner meeting, as well as two common bi-weekly demos, where a team or teams who have finished something that might interest others demonstrated their work. 3) To follow major transformation events, we observed both 2-day value workshops (arranged at sites A and D) and one continuous integration (CI) roadshows (arranged at site A). As explained later on, common values and the related value workshops were one of the major transformation steps. They were organized to unite the globally distributed organization. Building the CI system and spreading the CI knowledge and CI mindset in the organization was another major transformation step. During the CI roadshow sessions the persons who had participated in building the first CI system presented the current situation of CI and the goals of CI to the other teams, as well as discussed current challenges in the area. Similar CI roadshow events were organized at three other major sites.

The first and second author conducted the observations as non-participants. During the breaks they discussed with the participants. The observers took detailed notes during the observation sessions on what happened, what was presented and discussed, who were present, and how the participants behaved. For confidentiality reasons, the observation sessions were not recorded, as during those sessions details of new product features were discussed. Such details were, naturally, highly confidential, and as a result we were not allowed to record the sessions. The information gathered during the observations was used to support and complement the interviews. Table 2 shows the details of the observations.

We received a number of documents from our interviewees, e.g., slides discussing the process, working practices, product and organization structure, as well as a fictional story called the “Showcase”, created by the agile coaches together with the management team to describe how this organization would look like in two years. These documents were used to triangulate and complement the information received in the interviews.

At the corporate level, Ericsson had identified the need to be more agile, and had made the adoption of agile methods a strategic priority. Several successful agile transformations had already taken place in various units withing the company. However, each unit inside Ericsson was given the freedom to choose whether and how to adopt and apply agile. At site A, the biggest site of our case organization, a previous, still ongoing project, had started the transformation earlier (see (Paasivaara et al. 2013)). A large group of people from that project were gradually transferred to the case organization, and to them, agile was already a natural way of working. Thus, given their exprience with agile, it became natural also for the case organization to start thinking about adopting agile.

After the product was acquired, the case organization started to implement Ericsson’s traditional, waterfall process framework, even though the first development teams did not use any well-defined development process. The early development teams were simply assigned new features with preassigned deadlines.The teams then implemented the features as they saw fit. Our interviewees reported that development was slightly chaotic at this time, but features were finished on time. The lack of a defined process was not considered a major problem, because there were only a couple of small teams working on the product, in addition to a group of external consultants.

However, as the organization started to grow in 2012, it became necessary to implement at least somewhat orderly process. The first step, in 2012, was to implement a component-team based model, which seemed natural, as the product was composed of several components, each requiring specialized technical knowledge. The component teams had members with deep expertise on their individual components. When developing features spanning several components, virtual feature teams were used. In these, specialists from different component teams collaborated on a specific feature. There were several issues with the component based structure: it was challenging to plan and coordinate work, as features depended on several components, and experts were not always available when needed; the work was not considered efficient; development lead-times were long; teams had difficulties in finishing promised features on time; and team members felt that this way of working was stressful and somewhat chaotic. The rapid organizational growth from around twenty persons to over one hundred exacerbated the situation. Thus, they felt that change was needed.

At the time of our study, the product was released every eight weeks, the same rhythm as when it was acquired by Ericsson. However, this was considered too slow, and the goal of the organization was to transition towards continuous deployment. The idea was that anew feature could be taken as part of the product instantly when ready.

My dream is that we shouldn’t have releases at all, but that afeature goes to production right away when it is ready. It means that what we do here should include coding and verification in the team, as well as continuous integration and automatic regression tests so that we can trust that when they [the team] say it’s ready, we can just push it to the system.— Manager

Thus, the hope was that going agile would enable them to implement each feature in across-functional team as efficiently as possible, from requirement until delivered as part of the product. Moreover, by using agile practices, Ericsson aimed to optimize the whole end-to-end flow:

Our goal is that we can make this whole end-to-end chain work in anew way, to remove all waste, all unnecessary handovers, and [...] to optimize the whole flow, from customer requirement until deployment.— Manager

Optimized end-to-end development would help the organization to respond quickly to changing customer requirements, as well as to provide customers constant visibility on what is coming out next.

To achieve these goals, a wide spectrum of organizational improvement actions were undertaken, as described next.

Knowledge transfer from the original development organization, including external consultants, started soon after the acquisition. The first two teams were built in fall 2011. During winter 2011-2012, these teams worked partially collocated at site Dand partially as distributed teams, as part of the team members came from sites Aand B. However, during the most intensive knowledge transfer period, most members worked collocated at site Dfor longer periods. These first teams were working without any specific process. Instead, team members collaborated informally aided by “agile seating”, i.e. they shared asingle large table:

As Isee it, we had no process in the beginning that we would have been following... So no Agile processes, nor [any] traditional waterfall model.— Team Member

When growing the organization from the initial two teams, the idea was to hire experts with knowledge of specific system components. In particular, they intended to use internal recruiting as far as possible. As aresult, the experts were located at different Ericsson sites. In addition, aconsultancy company offering experts with specific domain knowledge was hired at site E. Even though the organization had started talking about agile already in late 2011, they decided to go for acomponent-based team structure in early 2012. The main reason for this was that each component required highly specialized knowledge and it was time-consuming to learn even asingle component.

You cannot really ask people to learn more than one component in two years.

— Product Owner

Furthermore, Ericsson had a long history in using a waterfall type process. Thus, this initial organization structure was based on component teams and a sequential, waterfall type, process. Typically, a single component team comprised of 10–20 people, was distributed to multiple sites, and communicated through weekly or daily teleconferences.

Experts from these component teams were selected to virtual feature teams, as illustrated in Fig. 5, whenever the development of a new feature would start. Virtual feature teams were loosely structured—team members performed their own feature-related tasks for their component, and then passed the work further. Usually, a new virtual team was established for every feature.

This component-based organization structure had several challenges, e.g., suitable resources for anew feature were not always available, and virtual feature team members simply performed their own tasks individually, and did not actually work together as ateam.

Setting up the virtual teams was challenging because we had the feature and then we found three guys [with competence A] but we don’t have [competence B] because they’re all busy with other features. So here we have the resources [with competence A] available but then we cannot wait for three weeks, so the guys start with something else. So it’s like apuzzle all the time.— Manager

Furthermore, the team members considered it challenging to work in virtual teams. The people you were supposed to collaborate with changed constantly and it took time to make the acquaintance of new people, hindering the development of trust and slowing down team building. The interviewed team members reported that at that time they identified themselves more with the component teams, rather than with the constantly changing virtual feature teams.

As a whole, the organization structure based on component teams and virtual feature teams created on top of them was seen as too rigid and not being able to answer market requirements fast enough. It was not efficient nor predictable enough.

When the organization decided to move to Agile software development, the idea of creating cross-functional, cross-component teams was born. Here, we focus on the organization and team structure while moving to agile, as it turned out to be both important and challenging. The structure was tested and modified several times.

At the team level agile, teams were given the freedom to themselves decide the practical agile implementation, guided by the coaches. Thus, no common agile framework was prescribed or used.

The organization structure evolved into the current agile team structure through four phases:

The development organization grew quickly from 10 (spring 2013) to 15 teams (fall 2013), while introducing agile development at the team level. Even though the goal had been to form predominantly site-specific teams, due to the knowledge differences between the sites, approximately half of the teams ended up as cross-site teams. There were lots of people who had never met. In addition, people at one site did not necessarily know what was happening at the other sites regarding the development and the transformation. There were clear borders between the sites:

I see site politics as one of the problems. It’s difficult to communicate between the sites. So we build up some kind of, us vs. them feelings. That hinders our way of working. We don’t have aperfect flow in the system. Because we don’t really trust each other. And that’s aproblem.— Coach

Moreover, management noticed that the organization lacked acommon direction, regarding both the future direction of the product, as well as the way of working, and there were site-based and history-based opposing views. Thus, management and coaches decided that the next step in the transformation journey would be to define acommon direction and build a“we spirit” to help people identify themselves with the single product organization rather than with their competing sites.

Why we have started with values, [...] is that we would have acommon baseline to continue further, [...] abaseline on which we build this common understanding and common direction. That we have something common to discuss together. Ihave seen as aproblem in this whole project that different sites and different people have taken abit different direction.— Manager

The work on the common organizational values started in early 2013. The first step was the Futurospective, a workshop where the agile coaches and managers created a vision for the organization a couple of years ahead. Based on the results of the Futurospective, the coaches wrote a Showcase, a fictional story of how the organization would look like and how it would work in two years time, after tight collaboration and joint creation of a success story. The idea of the values was born during a workshop on how to make the organization “more agile”. Thus, the values were based on the one hand on the ideas and principles of agile, and on the other hand on the three core values of whole Ericsson: professionalism, respect, and perseverance. The five core values were created in collaboration between the coaches, the management team and a few developers, and are: One organization, Step-by-step, Customer collaboration, Passion to win, and Fun.

The goal of the value workshops was twofold: 1) to create a common vision for the whole organization in the form of common values, and 2) to create contacts and collaboration, as well as building a “we” spirit across the sites by having people meet face-to-face.

The value workshops were held as two 2-day workshops at the biggest development sites, A and D, with around 20 people traveling from three other European development sites. The whole management team, all coaches, as well as a few team members traveled. The only site that did not have workshop participants was site E, the consultant firm, with the exception of a few consultants who were working on the sites where the workshops were arranged. The aim was that all team members from sites A, B, C and D would participate in one of the workshops, as well as meet all managers and coaches face-to-face. The results from the first value workshop organized at site A was shared with the other sites by having a videoconference call during the result presentations between the sites A, C, and D (site B participants were at site A already).

Besides meeting face-to-face, the goal of the value workshops was to jointly discuss and elaborate the values. Purposefully, the values were not defined beforehand, but the managers and coaches presented the values in both workshops using examples. What each value really means were discussed in small groups. In Table 3, we have collected some examples of what these values could mean based on the Showcase, examples provided and the value workshop discussions.

The workshops included different kind of group activities and exercises: within the whole group, within individual cross-functional teams, as well as in highly mixed teams with people from different roles and from different sites. For example, in one exercise, the teams considered what the values would mean in practice in that specific team, and what kind of concrete behaviors they would lead to. The coaches from different sites planned and facilitated these workshops as a collective effort. For more detailed description of the activities during the value workshops see (Paasivaara et al. 2014b).

The first impression of the value workshops was highly positive. In particular, participants felt that the organization took ahuge step closer to the goal of being asingle organization building acommon product. Especially, meeting with people from other sites and talking face-to-face was abenefit that all interviewed participants mentioned.

The value this event brings, that Isee, is that we are no longer just names and faces behind the screen. You see real people and talk to real people.— Team Member

Regarding the values, most workshop participants seemed to feel that the chosen values were good:

I completely agree with these values. [...] [the values are] not so easy as before to forget, or ignore in the daily work, Ithink that’s the main benefit of the workshop.

— Team Member

Several interviewees agreed that they would personally act differently in the future and that the events had clarified the values and made them meaningful.

I will probably do alot of things differently. [...] I’m gonna try to collaborate more, between the teams. Because Ithink that’s one of the biggest flaws we have right now.

— Team Member

Some participants worried that the values would be forgotten after the events, expressing that good intentions formed during the workshops are not enough to implement the values in the normal working environment. The plan to tackle this was to have the coaches help the teams work towards the common values and exhibit the behaviors they had planned. Many of our interviewees also suggested some kind of acommon follow up for these events after half ayear or so.

I would say afollow-up in maybe six months or something like that, just to have arecap of what has changed, what has happened, what Ihave done. Just akind of retrospective, just to see what is happening and what kind of next steps we can take. [...] All sites should be involved with that follow-up, [...] because we should fight for this one [name of the product].— Team Member

Even though the values were considered good and the workshops beneficial by all of the interviewed participants, some were still hoping to have an even more concrete vision than what the values and the showcase provided. Especially, a concrete product vision or roadmap was asked for. However, that was not a goal of these workshops this time.

The lack of continuous integration (CI) and test automation were major challenges on the way towards continuous deployment, as the integration and testing phase took several weeks before each release. The goal was to get rid of the integration and testing phase, and having the teams integrate and verify the system functionality immediately.

I think [that] the goal is that we should be able to...when something is ready...it should...pass through and be deployed directly into production. If we can deploy something...maybe the first user (story), Imean not acomplete thing and deploy it and test it with akey customer.— Manager

The work towards this goal started in fall 2013 by creating three new teams concentrating on implementing CI and test automation. Most team members came from another product developed by the same organization, and in which agile methods had been in use for several years. In that product CI and test automation had been a major and extremely successful effort. Thus, the teams had ample relevant knowledge and experience.

One of the Lean principles (Poppendieck and Cusumano 2012), optimizing the whole, is behind the goal of end-to-end development. In this case, end-to-end development meant developing system functionality from a customer requirement to new functionality being part of the product and used by the customer. One way to shorten the lead time of end-to-end development is to develop each functionality in a single team. This removes extra handovers and non-value adding waiting. CI and automated testing aims to optimize the last part of the end-to-end flow before the release.

Another action the case organization took to optimize the flow was to involve the teams in the early phases, i.e., in planning and design. The idea was that the teams would themselves conduct initial studies on new features: Feature Investigations (FI) and Feature Concept Studies (FCS). The purpose of these studies was to quickly investigate whether a feature is doable, how much effort it might require and how it could be implemented. Previously, experts such as architects had conducted the studies during the planning phase of the waterfall model. However, now the aim was to perform less profound studies quickly whenever new feature requirements appeared. The expected benefits were threefold. First, as the studies are not that profound, quick feedback can be received. Second, when teams are involved they learn more about the features, thus speeding up implementation since no extra handovers or documentation are needed. Third, as the number of experts doing these studies was limited, reducing their work with FIs and FCSs would free them up to focus on more profound issues. At the time of our research, the studies were already assigned to the teams. However, in-team experts, e.g., architects or subsystem responsibles, normally took the main responsibility for conducting the studies.

At the end of our study period, the organization had six releases per year but the goal was that the teams would be able to deploy new features into production immediately when they are finalized.

The first initial attempts to start the transformation were in 2012, but they did not lead anywhere as the issue polarized the organization. Some did not want to change the way of working at all, and those willing to change had different views on how the transformation should be conducted. Initially, the leadership team was not willing to sacrifice deliveries in order to support the transition. Several leadership team members found it more important to deliver new features than to focus on amajor organizational change.

The top operative management was located in [site C], and they hadn’t adopted the Agile philosophy. There was so much resistance that it was absolutely impossible to drive the change from bottom up.— Team member

During summer and fall 2013, the leadership team was reorganized, and new members having previous experience in agile transitions and strongly supporting the transformation were added. After this change, the transformation was rolled out full-scale, with less resistance.

However, at the time of the interviews, there were still groups of people in the organization, who had not yet adopted agile thinking. For example, the product management had still aquite plan-driven mindset, as illustrated by the following quote:

In product management there’s still some belief that aplan is the truth and trying to fulfill that is agood thing.— Coach

The evidence related to change resistance was strong in both the sense that it was mentioned and discussed in depth by many respondents, as illustrated in the quotes above, as well as in the fact that it was the explicit reason for changing the membership of the leadership team.

One bottleneck that prevented the transformation was a high degree of technical debt in the system. Technical debt is a metaphor originally referring to “not quite right code which we postpone making it right” (Cunningham 1992) but that since has expanded to include a spectrum of issues from bad coding to architectural issues (Kruchten et al. 2012)

The system was originally designed for a single customer. Additionally, the development in the previous organization had occurred within strict deadlines. Together, these two factors had resulted in a situation where lots of shortcuts had been taken in development, and the system was not stable enough to be scaled up for a larger pool of users. Improvements had to be made before new features could reasonably be implemented. Moreover, in the beginning, when working in component teams, adding new features had the highest priority, while the quality of the underlying system suffered. That happened partly because the overall architecture was not well understood by the new developers. All this led to increasing technical debt.

During 2012, many system improvements took place and a few components were replaced by Ericsson’s own components.

Furthermore, when working in component teams, management used to make the feature implementation decisions according to ever changing customer requirements. Feature prioritization could change constantly, causing major challenges in design, coding and testing. However, this was improved after establishing a common backlog and assigning subsystem responsibles and architects to the development teams.

The technical debt was a pervasive issue that despite its importance was raised only by few technical experts. However, the importance of dealing with it was reflected in the urgency of getting a working CI system in place to harness the product, and the fact that it required serious architectural changes to the components.

The organization had decided not to use any common agile framework guiding the teams’ day-to-day working practices. Instead, each team could itself decide how to work. The only commonalities between the teams were the common bi-weekly demos, coaches, and the use of Jira as a backlog management tool. In the common demo, usually one team demonstrated their achievements. This demo was open for everyone in the organization and it was organized as a video/audio-conference between the sites. The teams having finished something of interest to others would give a demo. Some Scrum trainings were arranged in the beginning, but participation was voluntary, thus not all participated. Some teams and team members had already agile experience from their previous project, some not. Thus, taking agile into use at the team level was not systematically organized.

Many interviewees expressed that starting with acommon agile framework that teams could later on tailor to their needs would have been preferable, as that was how it was done for example in another still on-going agile project at site A, from where many managers, coaches, and team members had been moved to this project. Several interviewees commented that having acommon framework, like in that previous project, would have been abetter solution to this project as well.

I think it’s good to start with acommon [framework], like start with Scrum or anything. That’s where you start, and everybody has to go through that or whatever and then you can go from that. But now it’s really difficult. [...] We have to really go back to [the basics] so it’s really difficult to do coaching or advice because we are, Idon’t know where we are. Iagree it’s kind of aproblem.— Coach

Many interviewees from teams even commented that their team had some agile practices in use, but not aspecific process to follow. For example, most teams did not use sprints and many teams did not have regular retrospectives or planning meetings. At the time of our study, each team had their own ways of working, often combining Scrum and Kanban, e.g., all teams had aScrum or Kanban board to visualize their workflow.

I came from acompany where we followed Scrum exactly, but here Ifeel that we are doing things, but we have no process to follow.— Team Member

I think Scrum is avery good start, and when you know Scrum then you can shift into other stuff. My feeling here is that we are kind of trying to take ashort cut and doing other stuff immediately, so some of these ground pieces are actually missing in quite many teams.— Coach

A few interviewees suggested having acommon pulse for the organization:

I think we need apulse in [name of the project]. We should have, like, every second week we could have acommon planning, acommon retrospective, and Ireally miss that. [...] It’s actually on our [Coaches’] Kanban board to start up this pulse, this heartbeat.— Coach

Some sort of timeboxing could help to push us to work harder and to help us to prioritize our work so that it is done in the right order.— Team Member

The common demo every second week was a start for this pulse and our interviewees found it useful. However, they did not consider this sufficient.

A few interviewees explained that one reason for not starting with acommon agile framework was, surprisingly, due to that above mentioned still on-going agile project at site A. This other project had started their agile transformation afew years back with strict Scrum that they later modified towards Scrumban and gave the teams alot of freedom to choose their ways of working. As part of the personnel from that project had moved to the case project, some interviewees suspected that the managers and coaches moving from that project did not consider it necessary to go back and start with acommon Scrum framework and Scrum trainings, as they had done that and were “past that phase”. They explained that the persons probably assumed that the rest of this project would be as mature in agile as their old one, making it possible to directly apply the same kind of practices and thinking.

So they probably tried to short-cut this path through Scrum. So they kind of tried to start where the old organization was.— Coach

However, in practice this was not possible, as a large part of the personnel in this new project was new to agile or had little familiarity with agile, and thus needed basic training and a framework to start with, before they could start modifying it. Interviewed developers that had moved from that other project to the case project, found having a common agile framework with common Scrum trainings a much better way of starting the transformation than giving quite free hands to the teams.

As the new organization was composed of persons from several internal organizations and sites, none of the groups actually wanted to say that “this is the way we should work”. Instead, they tried to come to a joint understanding and a way of working. However, achieving such an understanding takes time. Actually, the managers and coaches coming from that other on-going agile project at site A explained to us that they did not want to “push” too much the ways of working in their previous project, as in the beginning they had done that, but the other sites clearly did not like it, but instead always answered in style “but this is a totally different kind of product”. Thus, instead of following the good practices from the previous project, they decided to find together a common way of working for this project.

A major step towards this goal was the creation of across-site Coaching Community of Practice (CoP). Having aCoaching CoP that meets regularly aims at helping coaches to establish acommon way of coaching and to guide the teams to work in similar ways across the sites. This would be helpful also for people changing teams, e.g., the floating resources in the competence pool.

I think that’s [Coaching CoP] really important. And it must be cross-site, so that we can coach in the same direction, at the same time and have the same view on coaching and the ways of working. So, instead of going into control mode we should coach in the same way. And say the same things about what’s good and bad.— Coach

The evidence regarding the problems related to the lack of a common agile framework came from a few respondents, who had participated in an earlier agile transformation within Ericsson. While small in the number of respondents, their insights were deep, and they discussed the issue at depth in our interviews. They very strongly recommended that a common framework should be used instead of giving teams too much autonomy too soon.

At the time of our interviews, the organization had both team and organization level coaches. Approximately athird of the teams had their own team coaches. The organizational coaches supported the rest of the teams, each having several teams to coach. However, they were also responsible for helping with agile issues at the organizational level and developing the whole organization and its way of working further. Thus, the coaches lacked time to concentrate on helping individual teams. For example, they could not always participate in their teams’ daily meetings or retrospectives. The interviewees found coaching they had received extremely useful, but thought that the number of coaches was not sufficient.

Last week the coach participated in our daily meetings only once. And during the previous week maybe twice. [The coach] wasn’t involved in other things.

— Team Member

Currently we have so many teams and there’s only afew of us, so we are not able to support teams very well.— Coach

During our study period, the organization slightly increased the number of both organizational and team coaches. As the number of teams grew at the same time, the situation improved only slightly.

The data related to the lack of coaching and coaches came from a few coaches and a few team members, and is not as strong as for the previous categories. While coaching is important, the lack of it did not seem to be one of the most important challenges in this case, as coaches were available.

The agile knowledge was not yet at a sufficient level despite the fact that the organization had experienced people with knowledge on agile methods. The level of agile knowledge varied a lot from person to person, as some had used agile in their previous organizations while some had never used agile. Even though a few agile trainings had been organized, not all employees had participated in these, as participation had been voluntary and they had prioritized other tasks. The knowledge of agile experts was not spreading as well as it could have been.

A few interviewees even mentioned that the basic terms, such as feature, story or definition of done were not known or understood similarly by all, which is abasic requirement for working together in an agile way.

Sometimes Isend out mail or call people and discuss these, what Ifeel is basics. And then, for example, Italked to somebody about definition of done. But then, yeah they kind of agreed some of them, but acouple days later you get back some questions, “What is the definition of done?”. And then you realize, okay. We have to really go back to, so it’s really difficult to do coaching or advice because Idon’t know where we are. Iagree, it’s kind of aproblem.— Coach

The organization had plans to arrange trainings on a need basis. Moreover, the collaboration of coaches across sites and unifying the coaching would in time increase the agile knowledge in the teams.

The evidence related to the lack of agile training came from a few respondents, in particular coaches. Many people in the organization had already earlier received agile training, but the coaches noted clear differences in the knowledge, e.g. across site borders. While the data supports the importance of agile training, the lack of it was not one of the main concerns in the organization.

Even though one of the principles when forming the cross-component agile teams was to build site-specific teams, ca 50% of the teams were distributed between two or three sites at the end of our study period. Many interviewees commented that this was not agood solution for high quality team work. However, due to knowledge asymmetries between the sites this structure was deemed necessary.

Q: Do you feel that you are really ateam?

A: No, Idon’t. Iam ateam player and Ilike working in teams, but Idon’t feel that we have ateam spirit. And, Iguess it’s hard, when you have multiple sites. As long as you don’t know the people, you can’t possibly care for them either.— Team member

It would be nice if we could work with local teams, if we didn’t have any dependencies, for example. [...] But we do have dependencies between each other, so in that case it’s better to have distributed teams, even though it is less efficient on the team level.— Coach

Moreover, high quality videoconference equipment was used between sites A, B, C and D for most meetings. The videoconference connection between the distributed team members at sites A and B, was mentioned to be open sometimes all day to enable ad-hoc communication. Unfortunately, site E, a consultancy company, did not have compatible videoconference equipment. Thus, personnel at that site usually participated in using only audioconferencing.

Many interviewees emphasized that the team members should travel even more, and that they should arrange exchange visits and work co-located, at least for short periods.

We don’t talk to each other that much. So you do not trust each other. If you don’t know somebody, it’s difficult to trust them. [...] My solution is to travel more. To actually see each other. The teams [should travel]. The ones who really should cooperate. [...] Once you have met each other and worked together for awhile, then it’s much easier. And that sticks for awhile.— Coach

One goal of the value workshops was to increase trust, and make people know each other to lower the threshold for contacting. However, most cross-site teams spanned sites E and C and/or D, and as team members from site E, the consultancy company, did not travel to the workshops, they did not help with building team cohesion as much as they could have.

The use of cross-site teams with members from organizations that had not been tightly integrated before arose as one of the major problems in the case project. It was mentioned by most respondents, and also was the reason for arranging the value workshops.

All cross-component teams had experts from several components. As each expert had deep knowledge on his or her component only, some of the interviewed team members felt that all teams were not yet working as “real teams”. The global distribution of many teams made this even worse.

Q: You said that you do your tasks mainly all alone so, what do you do with the other team members?

A: Idon’t do anything with them. Idon’t work...

Q: So you don’t have any collaboration?

A: Sometimes they come with questions, and Itry to answer.— Team member

Due to the deep technical knowledge required team members could not really collaborate, e.g., help other team members working with other components when done with their own tasks. Thus, at times some team members had a too high workload, while others might not have work at all. During one of the value workshops, one team member worked on a task, while the rest of the team participated in the workshop. The team members explained that this individual was doing a critical task that no-one else from the team had knowledge of and thus could not help with. They explained that otherwise the whole team would be solving the problem together instead of participating in the workshop.

One of the goals the organization had was to broaden team member’s knowledge on other components, e.g., by working as a pair with an expert of another component in the own team. The goal was to add collaboration between the teams, e.g., pairing teams, so that they could learn from each other. Moreover, an exchange program across the sites was suggested to enable team members and teams from different sites to learn from each other. Exchanges were going on at the time of our study, even though it was not systematic.

Many components were quite complex, requiring significant effort to learn. This learning was not structured or organized, leaving it mainly to individuals to organize their familiarization.

Teams distributed between sites C, D and E had a couple of very experienced members, e.g., subsystem responsibles, sub-system architects or technical coaches from sites C and D, while the rest of the team was located at site E. As site E was located in Asia, and sites C and D in Europe, there were significant cultural differences between the sites. At the time of this study the technical coaches had taken the role of team leaders and the rest of the team performed individual tasks. These teams seemed to have a long way to go before turning into real agile teams.

The problem related to part of the teams not being “real” teams was mentioned in particular by coaches and line managers, working with teams with members on site E. This can be explained by the fact that we did not interview team members at site E (the consultancy company). The significance of the problem was evidenced by the fact that the organization actively planned for how to make the project succeed without site E.

The initial goal was to have fully cross-functional and cross-component teams that could implement any feature from the top of the backlog. However, the organization realized that this might never work in practice, as the different components required very specialized knowledge that would take long time to learn.

For at least half ayear ago they said that one team should be able to do any feature, end-to-end. That’s impossible. [...] Idon’t think we will ever get one team who can do end-to-end of all features.— Coach

It’s proved that it’s almost impossible to have across-functional team that could do any features. We don’t have asituation where developers would have competences of many components, and that’s why it’s easier for teams to focus on aspecific area.

— Product Owner

We work alot with third-party products. And Icannot possibly help someone else working on another platform. And the other way around. They can’t help me, so there’s not really any point in having cross-functional teams in that sense.

— Team member

Thus, the initial idea of fully cross-component and cross-functional teams was discarded, as it was not seen reasonable that any single team could be able to implement just any feature from the backlog, not even after some time of working and broadening the knowledge. At the end of our study period teams started to focus on specific business flows, which would not require knowledge on all the components of the product, but only from a few. Within these business flows, teams would still be cross-functional and able to develop end-to-end features.

The fact that the agile ideal of any team being able to implement any feature was impossible to meet in this project turned out to be one of the main problems, which explains many of the organizational changes done. The evidence for this is strong both as it came up in many interviews, and in the visible actions taken trying to deal with it. Indeed, it can be considered one of the main findings of our study that there can be cases in which trying to meet this agile ideal might not be feasible.

At the time of our first interviews, most of the testing was still manual, as appropriate CI and test automation systems had not been implemented. Therefore, the development teams had only three to four weeks for implementing new features until the code freeze, when the integration and verification team would start testing it. The testing phase took three to four weeks, after which it took approximately three weeks until the system could be released.

One thing that is in heat, that is due to that we don’t have this CI and the setup. We’re living in this waterfall mechanism so four weeks before we go into deployment, then we’re more or less locking the code, the mainstream.— Manager

As the organization was building CI and test automation, this challenge would be mitigated. However, the initial effort to build the systems had required a huge effort: three teams focusing on it for several months. The next major effort, Continuous Integration Road Shows for the whole organization took place at the end of our study period. The aim of this effort was to train the personnel in CI practices, as well as build a CI mindset in the whole development organization.

The lack of continuous integration and test automation was mentioned in particular by managers and coaches, as well as the active team members. The organization viewed the existence of a strong CI pipeline as a major facilitator of agile, and its importance can also be seen in the resources dedicated to building it, as well as in the actions taken to spread the understanding.

A few interviewees commented that the most of the organization was still in awaterfall mode—only the development teams were agile: product management, release management and integration and release testing were seen as working in awaterfall mode.

We have teams that try to work in agile, but the rest of the organization is not that agile. We have this, release management, Idon’t see this as an agile setup actually.

— Manager

We still have too much waste. We’re still doing waterfall. We have different phases, we have to have PowerPoint slides, we have different checkpoints and meetings, before we can move on.— Team Member

Product line management is still quite strongly in the waterfall world, that everything should be planned beforehand, and they expect that the feature they ordered will come out as such.— Manager

This was quite true, as the organization had only recently started to involve teams in the early planning activities and the integration and release verification activities took a long time at the end of each release cycle. The organization had recognized this challenge, and actions to remove the rest of the waterfall had already been taken, e.g., building the CI and automated testing systems, and involving teams in the early planning activities: feature investigation and feature concept studies.

The challenges related to product management not being agile, and the need to have teams involved more in the upfront activities were mentioned mainly by managers and a few enlightened team members. Actions to solve these problems were in the early phases, and this did not strike us as one of the main problems in the project. On the other hand, people strongly commented on the need to reduce the release verification time, and as far as possible integrate that activity in the development cycle.

Defining the Product Owner (PO) role has not been straightforward. During our first interviews POs were not responsible of the backlog, nor did they participate in backlog prioritization. Instead, the product line organization took care of that.

We have aseparate prioritization meeting where it (backlog) is prioritized. [...] And I’m not sure who are participating in that, but [the] POs aren’t there.

— Product Owner

Moreover, afew interviewees complained that the POs did not know enough about the new features to be able to answer the team member’s questions. Instead, they were more like messengers.

It is pretty hard to explain [the role of aPO], but we have had aportfolio manager on one site, who has been sitting on the backlog and is responsible of it. But on the other hand, we have this kind of PO function. And these POs have been more like technical coordinators and messengers of the product management, so they have not been able to do independent prioritization decisions.— Developer

In addition to the PO role, there were many other roles, partly overlapping with the PO role, such as sub-system responsibles and sub-system architects. To our interviewees it was not clear what the responsibilities of these different roles were. Even persons holding these roles complained that the roles and responsibilities were not clear.

We have way too many overlapping roles, we have architects, POs, portfolio management and others. [...] There’s too much discussion that’s preventing us to get forward.

— Developer

Even though Scrum does not recognize an architect role, the rapidly growing organization with a complicated product considered it important to have persons responsible for the sub-systems and their architecture. At the time of our interviews, these persons were located in the teams, and some sub-system responsibles and sub-system architects took care of the team coach role, as well. At the end of our study period, there was on-going discussion, on how to clarify the PO and architecture roles, as well as the responsibilities of these roles in the new team structure based on business flows.

The evidence related to the Product Owner role problems came in particular from the Product Owners, sub-system architects and the sub-system responsibles, i.e., the people who felt that their roles and responsibilities were unclear. The issue was addressed during the study, indicating the importance of having well-defined and understood roles.

The organization was still learning how to break down the requirements small enough to implement within one release by one or acouple of teams. At the time of our interviews, most features still took over one release to implement. Starting abig feature, that would require over one release cycle to implement was challenging according to our interviewees, as that team or teams would no contribute to the next release.

We have been struggling when we have something that is very big and we can see that this is not fitting into our next release. Then it’s too big to start and then it’s difficult to start.— Manager

The organization had started a discussion on minimum marketable features, but this idea had not yet been implemented in practice.

At the team level the interviewees found it challenging to split the features into user stories small enough to be implemented in atwo week sprint.

The ability to chew it [feature] into smaller subareas, so that we could do something visible in two weeks is still quite bad.— Manager

Now they [user stories] are huge to implement. Iwish they could be smaller, so that they could be implemented during one sprint, preferably even afew stories [per sprint].— Team Member

Moreover, as different team members still had quite specialized knowledge, the teams often had to start several stories at the same time so that each team member would have work that would fit his or her competences. This indicates that teams worked hard on optimizing resource usage, i.e. minimizing developer downtime rather than optimizing the flow.

While maybe conceptually a serious problem, the fact that the organization was unable to create user stories small enough to be finished in a single sprint did not seem to cause many problems. Interestingly, it seemed rather to be a minor nuisance that would be nice to solve than a major issue. Except for thinking about the concept of a minimum viable product (MVP), no clear actions were taken related to this issue.

A common backlog was considered as one of the most important improvement targets. Thus, it was one of the first improvement actions taken. It was expected to support the new agile way of working, to help streamline the end-to-end flow, to improve visibility and to help to define the lead time of new requirements.

Earlier, several different backlogs had been in use: an electronic backlog management tool was used for issue tracking, and different stakeholders had their own spreadsheets for managing requirements, features and improvements. This led to poor transparency, and made it impossible to define the cycle time of a single requirement and to see the whole end-to-end flow.

Building a common backlog started in early 2013 and was finished in summer 2013. At the time of the interviews, every new feature and improvement was to be added to this single backlog. The common backlog was for high-level features and improvements. Each team had their own backlog where chosen features and improvements were split into user stories.

Our interviewees expressed favorable opinions about the common backlog:

The good thing is that we have acommon backlog.— Manager

However, some challenges were seen, as well. The common backlog was big, i.e., it had alot of items. In addition, the original idea that any team could pick the next item from the top of the backlog was not seen feasible.

I don’t like this common backlog because it’s just abin of ahuge amount of features and improvements. [...] Ithink they have cut it down to 200 (features) now. So they have to wait afew years to get it out.— Manager

We actually had problems as someone says that we have acommon backlog, but when ateam starts going through the first items of it, they couldn’t understand anything. They simply don’t have the right competences. An item they were able to do was about the twentieth on the list and they were told that they aren’t allowed to do that yet.

— Product Owner

As mentioned, the reason for this difficulty was the lack of often very specialized knowledge needed to implement a specific backlog item. To help solve this, teams were starting to specialize in specific business flows, and the idea was to have business flow based backlogs, and each business flow having a few teams.

The journey towards agile had been challenging and stressful for everyone as avast number of changes had been implemented, while working under high pressure from the customers who continuously expected and demanded new features. The product structure, team structures and the process had been changed in parallel with the rapid organizational growth. Moreover, the development organization was globally distributed to five sites.

From my point of view, we’re currently shooting at amoving target, constantly ... It means that, we try to, or someone changes the organization, in order for it to work better, in alean and agile way. And after acouple of months, they realized that it didn’t really work. So they make another change, and so on.— Team member

Moreover, activities not directly contributing to feature development, like the development of the CI and test automation systems, had tied up several teams, leaving fewer resources to work on new features. As the organization aims to constantly improve its way of working, the constant change might never be over, even thought the biggest changes towards agile adoption seemed to be almost done.

The fact that change was constant came up in most interviews, and was thus strongly supported. However, most respondents did not consider it a big issue, and preferred to focus on the fact that the constant change mostly brought improvements to their work.

The case organization espoused an “agile mindset” in their experimental transformation approach. The reason for this was that it was difficult to determine up front how to perform the transformation, despite the fact that part of the organization had previous experiences in transforming a large product development program from waterfall to agile.

In this case, the situation was different from the previous experience: The R&D product development program was not developing a traditional telecom product for operators, but a XaaS platform and services that the customers would not buy, but use as a service. The system consisted of several components, and the organization developing it was new, rapidly growing and highly distributed. In comparison, one previous transformation in the same case company (Paasivaara et al. 2013; Hallikainen 2011) was for a traditional, over ten years old telecom product developed at two sites with a stable organization size. Thus, the set up was quite different. For this reason, the organization felt they could not follow the steps of any previous transformation.

In practice, the experimental approach meant that the organization open-mindedly tried solutions to see if they would work in their setting. If something did not work, it was quickly changed. For example, the organization tried different team set-ups and made changes quickly when problems occurred.

The organization had a mindset that it is good to try and ok to fail, since that is the only way to learn. This mindset was pervasive and what we consider an agile way of implementing agile. We believe that this is an important aspect of succeeding in large-scale transformation that is widely transferrable to different contexts. The literature review supported this approach (Dikert et al. 2016) as several companies reported that customization of the agile approach is an evolutionary process, see e.g. (Rodríguez et al. 2013; Ryan and Scudiere 2008).

While the literature contains little empirically based guidelines for large-scale agile transformations, the literature on lean and lean software development contain some prescriptive guidelines, e.g. in (Poppendieck 2007; Hibbs et al. 2009; Womack and Jones 2010). Looking at Ericsson’s approach, it seems to embody several of the principles suggested by this literature. In particular, the focus on mindset and experimentation is well in line with the suggestions of the proponents of lean.

Mirroring the discussion about this, while this lesson here was learned in the context of large-scale adoption, as evidenced e.g., by the discussion above about the lean principles, it is likely to be valid also in other, i.e., small organization contexts.

As a large-scale lean and agile adoption is a big undertaking, our case organization performed it step by step. Instead of trying to change everything at once, they focused on one change at a time. First, they focused on teams: they experimented to find out a working team set-up and get all agile teams to work well. Second, they aimed to unify the highly distributed organization and to find a common direction by creating and working with common values. Third, they invested in building CI and test automation systems, as well as training the whole organization to be able to contribute to this new way of working.

A big bang transformation approach would probably not have worked well in this case, as the organization had to continue delivering releases to the customers at the same pace as previously during the transformation. Thus, the gradual adoption of practices and structures was considered as a necessity. In this case the step-by-step approach was clearly a successful choice, as it facilitated adoption as everything could not be planned beforehand. The stepwise approach is closely related to the experimental approach, as when starting the transformation they did not have a plan of the future steps. Instead, they reacted and experimented when changes were needed.

The literature contains reports of both big bang and step-by-step transformation approaches, with step-wise being more commonly used. Often, step-by-step transformations started by piloting, which was reported as one of the success factors (Dikert et al. 2016). Piloting was the first concrete action in our case project, even though it was used for a shorter duration than expected, due to the problems experienced in the rest of the organization, as the component teams lost too many central persons to the pilot team. Still, it was seen as a necessary step in the transformation.

We observed clear high-level transformation steps in our case organization. However, in the literature review, besides piloting, we did not identify clear steps that would be common to all transformations. Thus, this could be an interesting topic for future research.

It could reasonably be argued that stepwise organizational transformation is a widely useful strategy for all kinds of transformations and process improvements initiatives, and indeed, even the venerable CMM(I) takes such an approach. Thus, it is likely that this idea of stepwise improvement is widely applicable, and this case clearly seems to validate such a statement through the success seen here.

In the beginning of the transformation the case organization had a goal that any agile, cross-functional and cross-component team would be able to implement any feature from the top of the common backlog. However, they soon noticed that this was infeasible, due to the product complexity and the asymmetry of competences. The product was composed of several components, each requiring deep technical knowledge. Component specialists were not distributed evenly to different sites. Moreover, each feature would not touch all the components, but only a limited set. Of course, agile teams and individuals can and should broaden their knowledge, but there are limits to what is reasonable and doable.

We believe that also other large organizations implementing agile might find it useful to take into account that the goal of “any agile team being able to implement any feature on top of the backlog” might not be fully feasible.

The solution our case organization identified was to have teams specializing in use-cases spanning several components, or business flows as they called them, with a few teams working in each business flow. Within the business flows, each team could implement end-to-end functionality, from requirement to deployment. This was seen as very important for achieving a fast product development flow, and the end-to-end flow was not compromised. The teams would not need to have deep knowledge on all the components, as the features in a business flow did not touch all components. This solution seemed to work well. Unfortunately, the change took place close to the end of our study period, thus we could not observe whether any further improvements to the setup were needed.

Practitioners have suggested the division of large products into product areas, in which teams can specialize (Larman and Vodde 2010). Our previous research has confirmed this (Paasivaara et al. 2013). In this case, however, the difference is that the components in a way formed logical product areas, whereas the use-cases could better be specified into business flows, crossing several product areas. One can think of this as a matrix structure, as illustrated in Fig. 2.

The organization gave the teams a lot of leeway in how they implemented agile—perhaps too much. The organization started by opting for Scrum, and arranged trainings that, however, everybody did not participate in. The agile background of the project members varied both between and inside distributed sites, as some had participated in trainings and agile projects before, while others had not.

Despite the fact that Scrum was chosen as the basic framework for all teams, only a few actually implemented the majority of the Scrum practices. For example, most teams were not using Sprints, but many did have daily Scrums. As there was a lack of coaches, nobody “forced” the teams to think about the best way for them to work in an agile way. This led to a situation in which some teams, having strong “agilists”, conformed quite well to Scrum, but others with less agile experience did not, focusing more on implementation tasks and more or less ignoring the process. Moreover, as people from different sites had not worked together before, and came from different cultures, they did not feel comfortable suggesting: “let’s work our way”.

Part of the interviewees had experience from another, still ongoing, project at one of the sites (reported in (Paasivaara et al. 2013)). There, the agile transformation had started a few years earlier with heavy support from an external consulting company with common trainings for all, as this was the first agile project at that site. A common Scrum framework was used by all in the beginning, and later on modified towards Scrumban. After the common start the teams got more freedom and took responsibility also in customizing their own way of working. Thus, persons coming from this background to our case project, like many of the coaches and managers, knew that pure Scrum needs to be customized. Moreover, as part of the team members had some agile knowledge already, the teams were given quite free hands to customize, which however did not lead to perfect results.

Close to the end of our study period the coaches were planning to implement similar ways of coaching between the teams and sites, as that would, e.g., make collaboration and changing team members between the teams easier. Thus, they aimed to encourage creating similarities of ways of working in different teams.

Literature emphasizes team autonomy in the way team implements agile practices. Allowing teams to self-organize was one of the success factors of large-scale agile transformations (Dikert et al. 2016). On the other hand, Conforming to a single approach was mentioned as a success factor as well (Dikert et al. 2016). Finally, common trainings and open events were suggested for delivering the same message to everybody to ensure that agile understanding across the organization was consistent (Dikert et al. 2016).

When comparing the literature findings to our case, we may hypothesize that the lack of common trainings across the sites, the lack of sufficient and unified coaching and the lack of a clear common approach led to a lack of unified agile mindset and understanding. Thus, giving teams autonomy without enough coaching led to a suboptimal agile implementation in the teams. Interviewees with background from the other transformation within Ericsson, asked for a common framework, as they thought that model had worked well in the previous transformation. Such a framework with common and similar trainings across the sites could have supported the organization in finding a common direction in agile, and thus providing a common ground for teams to customize the practices later on.

In retrospect, starting with a common agile framework and common trainings seems rather self-evident, and indeed that seems to be the presumption behind any agile implementation, for both large and small organizations. However, the fact that our case organization did not do this, and subsequently run into problems seems to validate this idea, which is increasingly important as the organization grows, as inter-team coordination otherwise becomes very difficult or impossible.