identifying friction between large-scale agile …feldt/teaching/master_theses/...in the following...

Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering Göteborg, Sweden, June 2011

Identifying Friction between Large-scale Agile Software Development and Plan-based Business Processes

Master of Science Thesis in the Programme Software Engineering and Technology

TOBIAS ALTEHED ROBIN INGMARSSON

The Authors grant to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Authors warrant that they are the authors to the Work, and warrant that the Work does not contain text, pictures or other material that violates copyright law. The Authors shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Authors have signed a copyright agreement with a third party regarding the Work, the Authors warrant hereby that they have obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Identifying Friction between Large-scale Agile Software Development and Plan-based Business Processes TOBIAS ALTEHED, ROBIN INGMARSSON © TOBIAS ALTEHED, June 2011. © ROBIN INGMARSSON, June 2011. Examiner: HELENA HOLMSTRÖM OLSSON Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Göteborg, Sweden June 2011

Acknowledgements The Authors would like to extend gratitude and thanks to Ericsson AB for providing time and resources contributing to the writing of this thesis. In particular, the authors are thankful for the support and guidance given by Mats Lindén and Heike Thiede throughout the conducted study, alongside the important contribution given by interviewees at the studied Ericsson unit. Furthermore, the Authors would like to thank Associate Professor Robert Feldt, Chalmers University of Technology, for his academic supervision and support from initial thesis proposition to thesis completion.

Preface

This Master of Science Thesis is reported here in a hybrid format, i.e. the main content of the Work is reported as a scientific article conforming to the Empirical Software Engineering Journal’s template, complemented by additional appendices relevant for the examination at Chalmers University of Technology.

Table of Content Scientific Article ...............................................................................................................1

Introduction ..............................................................................................................1 Background ..............................................................................................................2 Related Work............................................................................................................3 Case Study Design ...................................................................................................5 Results ....................................................................................................................10 Discussion ..............................................................................................................16 Conclusion..............................................................................................................17

Appendix I – Interview Questions ..................................................................................19 Appendix II – Survey Questions .....................................................................................21 Appendix III – Example Material from Workshop.........................................................24

myjournal manuscript No.(will be inserted by the editor)

Identifying Friction between Large-scale Agile SoftwareDevelopment and Plan-based Business Processes

Tobias Altehed · Robin Ingmarsson

Received: date / Accepted: date

Abstract Agile software development has transitionedfrom small projects to large-scale enterprise settings,incorporating additional influences from lean manufac-turing principles such as an end-to-end perspective. Atan Ericsson AB development unit, one such processconsisting of both agility and planning is deployed ina large-scale setting, having more than 300 develop-ers within more than 30 teams continuously developingsoftware comprising several million lines of code. In thisstudy, thirteen employees of that particular unit par-ticipated in interviews, in a workshop and respondedto a questionnaire. The collected data was analyzedusing an analysis process influenced by grounded the-ory, resulting in a characterization of friction, i.e. gapsin expected behavior and actual observations betweenemployees in units of the organization working eitherplan-based or according to agile practices. The resultsshowed that such friction was present between plan-based product management and agile development, aswell as between agile development and the plan-basedrelease unit. Furthermore, it was indicated that separa-tion of agile and plan-based organizational units leadsto a lack of understanding others’ work and valuations,limiting possibilities to optimize across the whole orga-nization. In general, findings indicated a need for im-proving this end-to-end perspective and it was thereforesuggested to incorporate plan-based units into the ag-ile way of working in order to lower barriers to achievecross-organizational improvements.

Tobias AltehedTel.: +46-735-353422E-mail: [email protected]

Robin IngmarssonTel.: +46-708-651177E-mail: [email protected]

Keywords Large-scale · Agile · Plan-based · Friction ·Case study

1 Introduction

The agile development methodology for software en-gineering emerged as a response to manage frequentchanges in project scope during the project life cycle[1, 3, 8]. Through dynamic prioritization and focus onfeedback, change and teamwork, the incorporation ofagile practices has shifted project focus from followinga plan to meeting stakeholders’ needs at time of deliv-ery.

In parallel to the introduction of agile development,Lean Software Development (LSD) has emerged [22],transferring concepts from lean manufacturing [14, 28]such as an end-to-end perspective, value-stream map-ping, inventory management and pull systems to soft-ware development [19]. Even though LSD has influ-enced the business process perspective of agile organi-zations, project contracts and release plans are for in-stance still fixed at project initiation due to challengessuch as cost and time estimation [7].

While existing empirical studies suggest that an ag-ile process should be adopted by incorporating all rele-vant practices into the organization [3, 8], finding a bal-ance between agile and plan-based development couldimprove the alignment between agility in developmentand planning in business processes, similar to the in-tension of LSD [4, 5].

For instance, it has been shown that plan-drivenmanagement can be successfully combined with agiledevelopment [13] and previous research on large-scaleagile software development report that organizations

2 Tobias Altehed, Robin Ingmarsson

using balanced processes have seen improvements incommunication, speed and quality [20, 21, 27].

However, it is also reported that adaptations in bothagile and plan-based practices are required [7, 12, 13]and in order to gain more insight into large-scale agilesettings with the need for adaptation between agile andplan-based processes, additional empirical studies areneeded to fully understand how projects are affectedby agile practices [10].

This paper specifically sets out to investigate large-scale agile software development by identifying and char-acterizing friction (See Section 2.2 for definition of fric-tion) between agile and plan-based organizational unitsin order to assess the effect of friction on end-to-endspeed in a software development organization.

The distinction between agility and planning or ag-ile and plan-based is in this paper made as follows; pro-cesses containing agile practices or influences from LSDhave been grouped into agility, whereas processes basedon plans, heavy documentation or stage-gates such asthe waterfall model have been grouped into planning.Thus, the two methodologies are not seen as completeopposites and it is not excluded that agility to someextent incorporates planning or vice versa.

As basis for this paper, a case study was conductedby the two authors during January to June 2011. Withboth authors actively participating at an Ericsson de-velopment unit, initial data gathering was performedthrough document analysis and discussion with assignedmentors, followed by interviews, a workshop and a sur-vey with Ericsson employees.

With the studied unit having both a large-scale con-text and an existing balance between agility and plan-ning, this study and paper contributes to previous re-search by providing empirical data on large-scale agilesoftware development in practice. Furthermore, contri-bution is made by identifying observed friction in bal-ancing agility with planning seen from employees withinmultiple software engineering roles.

The paper is structured as follows; In Section 2,Streamline Development is introduced together withthe definition of friction, followed by a brief review of re-lated work in Section 3. The case study design is thendetailed in Section 4 and the results are presented inSection 5 together with the identified friction. Finally,the results are discussed in Section 6 and the paper isconcluded by Section 7.

2 Background

In the following subsections, the evolution and intro-duction of Streamline Development and its relation to

agile software development is introduced on a high-level, followed by the definition of friction used in thispaper and its intended utilization as an analytical frame-work.

2.1 Streamline Development at Ericsson

Streamline Development (SD) has been implementedat an Ericsson development unit through several evo-lutionary steps with a vision of delivering the latestversion of the system to any customer at any time.

The extent of agility within SD at another Ericssonunit was by Petersen and Wohlin concluded to be high,with similarities to iterative development, eXtreme pro-gramming and Scrum [21]. However, it was noted thatnot all agile practices was fulfilled, indicating that theSD process is not entirely agile.

More specifically, at the unit selected for this casestudy, product management and the organizational unitresponsible for releasing the product to customers areworking traditionally by following a plan. In contrast,the development unit has an agile way of working whichincorporates several agile principles such as frequent de-livery of working software, co-location and self-organizingteams. This plan-based and agile balance of SD is fur-ther detailed in Section 4.1.3.

The introduction of SD at the studied Ericsson unitspanned several years during a step-by-step evolution,which started during the 90’s when the developmentunit employed a waterfall approach for software devel-opment. The waterfall way of working was then ex-tended to incorporate anatomy planning, i.e. an ap-proach to avoid late system testing and re-design throughfeature breakdown, incremental development and testwith continuous integration.

The incorporation of anatomy planning eventuallyforced increased collaboration between disciplines, whichled to an introduction of cross-functional teams. Fur-thermore, the feasibility decision of development projectswas divided into several parts, creating early and latephases of the scope to be delivered, thus providing amargin for the development unit to handle small changeslate in the project.

When the organization was accommodated with ana-tomy planning and cross-functional teams, SD was in-troduced and it is currently employed in 30 teams. Sofar, three years of incorporating SD during six productreleases have resulted in shortened release cycles fromeighteen to six months, measurable quality increase to-ward customers and efficiency improvements.

However, during initial discussions with the Erics-son unit, it was made clear that previous internal stud-ies identified possible bottlenecks, misunderstandings

Identifying Friction between Large-scale Agile Software Development and Plan-based Business Processes 3

or misalignment between the agile development unitand more traditionally plan-based units of the organi-zation, retaining further improvements from an end-to-end perspective. Given this clear indication of presentfriction between agility and planning, the Ericsson unitwas selected as a case study candidate, strengthened byits large-scale context of many teams developing soft-ware comprising several million lines of code deliveredto hundreds of customers.

2.2 Definition of Friction

In this paper, the term friction is used as an analyt-ical metaphor to describe and consolidate misconcep-tions, bottlenecks and problems related to interactionsbetween individuals or roles in a large-scale softwareengineering organization. This way of using friction asa metaphor from physics to other scientific subjects isnothing new and has previously been summarized byAkerman [2].

More specifically, in the framework used for analysisin this paper, friction is seen as the gap between roles’or individuals’ expectations and actual observations ofeach others’ actions as illustrated in Figure 1.

Friction

A1

X Y

E1

A2 E2

Fig. 1 Friction is defined as the gap between roles’ or indi-viduals’ expectations and actual observations of each others’actions

For example, individual X in Figure 1 observes fric-tion in the personal or professional relationship towardindividual Y if the expectation (E1) on how individualY should act does not correlate with how X observesthat Y actually acts (A1). Simultaneously, individualY can expect (E2) and observe actual behavior (A2) ofindividual X, resulting in additional friction if a mis-match exists.

With this simple analytical framework, statementscaptured during interviews regarding the current anddesired way of working can be structured to effectivelyillustrate where in the organization misconceptions, bot-tlenecks or problems occur. The illustration can then beused to provide a concrete base for further improvementwork, as explicit statements on expectations and obser-vations can be used to facilitate constructive discussionsacross the organization.

3 Related Work

In pace with the rise of agile practices [3, 8, 11] for soft-ware development, several empirical studies have beenconducted in industry to determine the effects of in-creased agility. For instance, Dyba and Dingsøyr pro-vide a literature review of 36 high quality empiricalstudies [10], in which they identify both improvementsand limitations of agile development.

In addition to an overall agile mindset, SD has clearlytaken influences from LSD such as the end-to-end per-spective or as specified by Poppendieck and Poppendieck;optimizing the whole [22]. Mehta et al. [16] provide in-sight into how lean principles relate to a real softwaredevelopment context, but in contrast to case studiesonly covering agile practices the extent of LSD empir-ical studies is limited. Apart from Middleton who pro-vides a good coverage of LSD evolution [17] and thefirst empirical results of a LSD implementation [18].

With Ericsson being a large company where thestudied unit has rolled-out SD to 300 developers in 30teams, a large-scale perspective on agile developmentmust be taken into consideration. Therefore the nextsection will detail case studies of large-scale agile im-plementations and other studies of interest relating tothis thesis.

3.1 Large-scale Agile Case Studies

Petersen and Wohlin conducted an interview study atanother Ericsson development unit, where perceived im-provements after transitioning from a plan-based wayof working to SD were investigated [21]. It was con-cluded that the agile transition eliminated common is-sues from plan-based development and that agile prac-tices led to increased release frequency, reduced lead-time, improved quality and communication while en-abling a reduction of waste and change requests. How-ever, they state that current challenges exist, includingan increased need for test coordination and test cover-age, a need for support of team-coordination and de-cision making for concurrent projects and a need tointegrate release projects in the development process.

Furthermore, Petersen and Wohlin recognized thatthe majority of past research concerning agile softwaredevelopment focused on one specific model and smallprojects [20]. They therefore re-analyzed data from thesame interview study, focusing on identifying advan-tages and disadvantages comparing the findings to pre-vious empirical research in order to evaluate whetheror not large-scale projects receive the same advantagesand suffers from the same disadvantages as small-scaleprojects. It was concluded that most of the advantages


gained by using agile practices in small-scale projectsare directly transferable to large-scale projects. For in-stance, communication in teams reduces the need fordocumentation and early feedback is possible thanksto frequent delivery and reduced amount of rework. Incontrast, few of the identified issues with large-scaledevelopment had been found in previous research re-garding small-scale projects. For instance, large-scaleagility brought challenges regarding continuous testing,increased configuration management effort, increase inproduct-packaging and release effort and increased main-tenance effort due to the increasing number of releases.

Another study made by Tomaszewski et al. presentsan evaluation of the suitability and applicability of SDfor Ericsson [27]. The evaluation was performed by iden-tifying advantages, disadvantages and potential issuesrelated to an SD process implementation using datacollection from 27 interviews with Ericsson employees.The findings were classified into three categories; thingsthat would improve, worsen or need to be changed inan SD introduction. It was concluded that SD has greatpotential, recognizing that there were many things thatwould improve with the process, e.g. increased moti-vation of the staff, increased customer responsiveness,simplified maintenance (in contrast to the findings pre-sented by Petersen and Wohlin [20]) and improved com-munication. On the other hand, some that would worsenwere also identified, e.g. difficulty in assuring qualityand long-term architecture deterioration. However, itwas concluded that many of these could be avoided ifnecessary changes were made prior to introduction, e.g.introducing continuous requirements management, in-crease testing efficiency, improve architecture and in-crease the efficiency of the installation procedure.

In relation to partially agile and partially plan-basedprocesses such as SD, Karlstrom and Runeson investi-gate how an agile development process fit together withstage-gate management. By studying large-scale devel-opment settings at ABB, Ericsson and Vodafone whereagile development had influenced or been integratedinto plan-based management models [12, 13] they foundthat both methodologies gave tools to each other, i.e.agility improved planning by having a day-to-day focusand planning improved agility by providing means forinter-team coordination and communication. However,the authors stress that adaptation of the methodologiesto be combined is required and that a cross-organizationacceptance of the employed process is a major successfactor.

A similar conclusion is supported by Lindvall et al.who analyzed experiences from pilot projects of agileintroduction at four large organizations; ABB, Daim-lerChrysler, Motorola and Nokia [15]. They found the

greatest challenge to be integration of the agile prac-tices into the existing process, requiring tailoring to in-tegrate agile projects into the organization rather thanagile practices into a project. Concluding that clarify-ing and specifying the interface between agile and non-agile parts of the organization is required to minimizethe need for re-work and misunderstandings.

The need for adaptation of agile practices to bet-ter fit large-scale software development organizations isalso recognized by Cao et al. [6]. Through an industrialcase study they identify key differences when agile isemployed in a large setting, such as up-front creationof a stable architecture and to surrogate customer in-volvement to reduce problems with an extensive domainbeing too much for a single customer to have detailedknowledge of.

Talby et al. conducted a case study at the Israeli AirForce focusing on how to work in an agile manner withquality and testing in a large-scale software project [26].

It was emphasized that defects should be resolved assoon as they are discovered in order to enable deliveryof working and stable software to the customer at everyiteration. They concluded that this way of working withdefects has a set of advantages. First, the effort to fixa defect is significantly reduced. Second, developmentpace can be increased with a clean and stable baseline.Third, it eliminates the overhead of defect prioritizationand planning, making negotiation with the customerover which defects to fix unnecessary.

Sutherland describes his experience from workingin five different projects and organizations where ag-ile software development, and Scrum in particular, hasbeen introduced and successfully used [25]. In additionto the conclusion that Scrum works in any environmentand is scalable to large projects, it is recognized thatdevelopment speed can be significantly increased as adirect effect of communication and information shar-ing. Reflections from one project state that people wereaware of what other team members were doing andcould therefore work in a way that were beneficial forthe whole team, ultimately eliminating much work forthe team members.

On the topic of balancing agile software develop-ment with plan-based business and release, Boehm andTurner created a framework for adapted projects [5].They recognized that both agile and plan-based meth-ods have short-comings which if unaddressed can leadto project failure. The framework constitutes a five stepmodel where risk is used for structuring projects inorder to incorporate both agile and plan-based prac-tices. First, risk analysis is used to specify risk areasin relation to agile and plan-based methods, catego-rized into environmental, agile and plan-driven risks.


Second, the risks are evaluated to determine whetheror not the project should use a pure agile or pure plan-based methodology. Third, given that the project isunsuitable for a purely agile or plan-based approach,an architecture is developed that supports agile meth-ods where their strengths are exploited and weaknessesminimized. Fourth, a risk management and resolutionstrategy is developed. Finally, project attributes aremonitored in order to enable proper adjustments to-ward either agility or planning during the project lifetime.

From the related work, several findings contributeto this study. First, the studies conducted at other Er-icsson development units provide a direct comparisonbasis with details on the agility of SD, effects of thetransition and improvement recommendations. Second,studies of other large-scale or balanced software devel-opment processes contribute with additional findingssuch as alternative solutions along with their positiveand negative effects. Third, specific studies focusing ontesting, communication and risk assessment provide ad-ditional insight and contrasting material to behavioralaspects or technical details in the organization. Fur-thermore, the design of the related studies has providedinput to the design of this case study with respect to in-terviewee selection, interview questions and validationtechniques.

4 Case Study Design

In the following subsections, the context of the studiedproject, product and process at Ericsson is detailed.Furthermore, specifics regarding the study design areexplained, including research questions investigated anddata collection and analysis procedures used.

4.1 Study Context

This case study has been conducted at Ericsson AB, amultinational telecommunication and data communica-tion company developing various mobile and fixed net-work products. With a market share of 35 percent andover 90,000 employees in more than 150 countries, Er-icsson is the world’s largest mobile telecommunicationsequipment vendor and the world’s fifth largest softwaredevelopment company.

4.1.1 Project

The studied project consists of approximately 300 de-velopers distributed over 30 teams, serving hundredsof customers with a target of delivering high quality

with dependability. The teams are cross-functional andco-located to enable close communication between de-velopers and teams but also with project managementand release units.

Overall, the project organization can be divided intothree parts; Product Management (PM), Research andDevelopment (R&D) and Product Introduction, De-ployment and Support (PIDS). Within both R&D andPIDS, roles include program leader, system manager,team leader, designer and tester and the employees tak-ing these roles belong to a line organization in parallelto the project but usually devotes all their time to theproject. Simplified, R&D receives input from PM todevelop, test and integrate new features that are trans-ferred to PIDS in order to be released to customers andthereafter maintained and supported.

How information flows between the different partsof the organization and its customers is illustrated inFigure 2. The relation between PM and customers in-cludes management of requirements (1) and strategi-cal issues (2), e.g. negotiations regarding what othersuppliers and Ericsson can deliver. Usually, R&D andcustomers do not communicate directly, instead the in-formation flows either through PM or PIDS dependingon the matter; if a customer wants to know more aboutspecific features and how they work (3) or if R&D wantsmore information from a customer regarding requestedfeatures or trouble reports to be corrected (4). Addi-tionally, PIDS selects a collaboration customer (5), ex-ecutes live tests on customer site and finally puts therelease out for general availability to all customers (6).

PM R&D PIDS

Plan-‐based Plan-‐basedAgile

Customers

456

32

1

3 4

Fig. 2 An overview of the organization and its relation tocustomers

4.1.2 Product

The project develops two separate mobile network unitsconsisting of both hardware and software, acting asgateways between mobile devices and the Internet. How-ever, the two units provides functionality in differentgenerations of mobile telecommunication, complement-ing each other and are therefore usually combined intoa single entity.


The product has been in development since the mid90’s, first released commercially in 2001. The softwareis developed separately from the hardware developmentand several releases of software are made before a hard-ware upgrade of the unit occurs. The software has beenupdated continuously and is currently subject to tworeleases per year following the SD process described indetail in Section 4.1.3.

In total, the software comprises several million linesof code, divided equally between C and Erlang [9] sourcecode. Several different releases are currently maintainedand supported through a number of correction packagessent to customers containing defect corrections.

4.1.3 Process

In contrast to previous employed processes at Ericsson,SD has ensured that important decisions are no longermade early and upfront; rather they are made just intime through a conscious focus on speed to shorten leadtimes. High speed is seen as delivering small incrementsof added customer value (cf. single piece flow [28]) byintegrating working parts of a feature, i.e. anatoms, to abranch of the software compromising the latest systemversion (LSV).

...

Team

1Team

n

Team 2 to n-‐1

Continuous Analysis and Planning

Latest System Version Branch

1

2

Release Program

5

7

3

4 6

Fig. 3 Overview of the Streamline Development process

From an overall and purely theoretical perspective,the SD process (See Figure 3) includes continuous anal-ysis and planning with feature prioritization (1), sub-mission of features to cross-functional teams just-in-time (2), division of features into anatoms (3), contin-uous renewal of developers’ code-base (4) and integra-tion of each completed feature (5) and each completed

anatom to the LSV (6) while having the release pro-gram separated from development (7).

More specifically, the SD process is in theory guidedby five cornerstones;

I. The highest priority feature is assigned to ateam when available

The decision to develop a new feature is taken by acontinuous analysis and planning program as soon as adevelopment team is available. The program planningmaintains a prioritized list of features, which is analyzedand re-prioritized bi-weekly. Each feature is specified tothe extent where there is just enough information for itto be handed over to a development team.

II. A team develops the feature during anaverage of three months with full responsibilityof its implementation

The cross-functional teams, having an average of sevenemployees, incorporate roles such as system managers,designers, developers and testers. Each team is desig-nated to develop and deliver one feature at a time dur-ing roughly three month intervals, with full responsibil-ity from end-to-end of the development, i.e. from pre-study through system test and also if needed throughnetwork integration and verification.

III. The team breaks down the feature intosmaller parts, specified in an anatomy plan

Upon receiving a feature from program planning, theteam is supposed to break it down into smaller partscalled anatoms to be delivered sequentially during thethree months of development. The team can either breakthe feature down into anatoms upfront or decide tospecify only the first anatom and defer the specificationof the latter parts of the feature to be specified whenmore knowledge is acquired during the implementationof the first anatom.

IV. Each completed anatom is integrated to theLSV

Regardless of how the feature is divided into anatoms,the team is expected to deliver and integrate a workingpart, i.e. one anatom, of the feature to the LSV eachmonth. The LSV should therefore represent the lateststate of the software, making it possible for all teams touse the same code base. Eventually, with 30 teams in-tegrating small functional pieces every month, the leadtime for the release projects should be shortened whilethe software grows in small steps.

V. Release of the LSV to customers isdecoupled from the development organization


PIDS follow their own stage-gate project process delib-erately separated from the agile R&D organization dueto legacy reasons, i.e. to maintain a plan-based way ofworking toward customers while enabling R&D to tran-sition to an agile way of working in order to increasedevelopment speed.

Figure 4 illustrates the plan-based release processemployed in PIDS, starting with product packaging (PP)to set prices on features or packages of features in thenew release, securing supply of hardware supporting therelease and finding one specific customer to involve infirst office application (FOA). When a pre-release as-sessment (PRA) has been conducted to ensure that thesoftware is ready to be released, the content in the formof code, supporting models and documents at the LSVis delivered from R&D to PIDS.

Latest System Version Branch

Release Program

PP, HW Supply, FOA selection

PRA

GAFOA

Fig. 4 An overview of the plan-based release process

Following that delivery, the actual FOA work is en-gaged and planned to last for eleven weeks, including athree week clean run where the test object list is exe-cuted without customer participation, a four week ac-ceptance test with the customer and a four week pri-mary consolidation integrating the node with the newrelease in the customer’s network. After a successfulFOA, the release is set to general availability (GA) forall customers.

When GA has been set, the specific release is branchedinto a separate maintenance track handled by PIDS,where trouble reports are solved and defects are cor-rected.

4.2 Research Objective and Questions

This work strives to provide desired empirical insight onlarge-scale agile development in general and balancingagility with planning in particular.

In the following, a set of research questions (RQ)and sub-questions (SQ) to be investigated in accordanceto the objective is listed. RQ1 and its SQs are stronglyrelated to the definition of friction and its categoriza-tion while RQ2 and its SQs are more related to assessingthe effect of friction on the organizational performance.

Even though SD has resulted in improvements tothe work performed at the studied Ericsson unit, thedecision to focus on identifying friction and its effectswas made in order to provide the organization with con-crete instances of possible improvement areas.

– RQ1: What characterizes the friction between agile

development and plan-based business?

– SQ1.1: What is the current expectation on the

way of working between individuals and roles in

different units of the organization?

– SQ1.2: What is the actual or observed way of

working in different organizational units?

– RQ2: What is the effect of friction on the end-to-

end speed in the organization?

– SQ2.1: How has the friction affected the orga-

nizational units?

– SQ2.2: To what extent are the organizational

units aware of the effects?

4.3 Data Collection

The data collection followed a general case study ap-proach, i.e. an in-depth investigation of a single studyobject, chosen due to its suitability for software engi-neering research in a natural context and the incorpo-ration of multiple elements of research methods, be-ing both exploratory and qualitative as described be-low [23].

During the study, interviews were conducted withemployees, supported by observations at internal work-shops, guest lectures held by Ericsson employees andcontinuous study of archival data such as process docu-mentation. All data sources were strategically selectedin order to ensure data triangulation, i.e. making it pos-sible to cross-reference findings. In the following subsec-tions, these data sources are described in further detail.

4.3.1 First Degree Data Sources

As a first degree data source, interviews were conductedwhere interviewees were strategically selected to collec-tively provide a broad perspective covering all phasesof the project, i.e. spanning from PM through R&Dand PIDS. The selection was also made to provide cus-tomer insight from interviewees working in roles havingdirect contact with Ericsson’s customers. Furthermore,most interviewees had several years of experience fromworking at Ericsson, being able to follow the evolutionof SD, often through working in different roles histor-ically. The distribution of their roles is summarized inTable 1.


Table 1 Distribution of interviewees

Org. Role

PM Product ManagerPM Product Release ResponsibleR&D ManagerR&D System Manager and Team LeaderR&D Developer and DesignerR&D Developer and Function TesterR&D Function TesterPIDS Release Program ManagePIDS Release Execution Team ResponsiblePIDS Release ResponsiblePIDS Product Packaging and SupplyPIDS Customer Product InformationPIDS System Tester

As seen from Table 1, the distribution of intervie-wees was uneven in relation to the number of organiza-tional units. However, interviewees were deliberately se-lected to cover all roles with relevant responsibilities forthe study within each organizational unit rather thantriangulating each role. Thus, the distribution of inter-viewees is strongly related to the roles within the stud-ied project, i.e. more interviewees were selected fromPIDS than PM since there were more relevant roles tobe interviewed in that organizational unit for the pur-pose of this study.

The interviews were between 30 and 75 minuteslong, following a semi-structured interview guide as out-lined in Table 2 with the purpose of in-depth investiga-tion of friction between agility and planning. When anactual instance of friction was discussed, follow-up ques-tions were posed to the interviewee in order to reachthe causal factors in relation to possible gaps betweenexpectations and actual behavior. At the end of eachinterview, the interviewee was asked to rank the threemost problematic friction instances and provide ownimprovement suggestions.

For example, during the Q3 section of Table 2 thequestion ”Has the vision of delivering to any customer

at any time affected your own work and interaction with

other departments?” was asked, followed by ”Is it con-

sistent with your expectation on how work and interac-

tion between different parts of the organization should

be performed?” and during Q5 the question ”How do

you think that the vision of delivering to any customer

at any time involves the customer?” was followed by”What is your perception of other employees’ opinions

regarding this?”. Thus, the interviewees were first declar-ing their observed friction within each section and thenfurther asked to detail their observations in a way thatcorresponds to the definition of friction and its use asa framework for analysis.

Table 2 Structure of interview guide

Section Topic

A Information on anonymity and recordingsB Description of study purposeC Set the focus on agility and planning balanceD Explain commonly used conceptsQ1 Formal role and performed activitiesQ2 Observed friction in generalQ3 Friction in relation to the way of workingQ4 Friction in relation to organizational structureQ5 Friction in relation to external forcesQ6 Prioritizing friction and improvementsQ7 Open-ended questions

All interviews were conducted by both authors, re-corded, transcribed word by word and sent to the inter-viewee for review and validation in summarized form.In total, 13 employees were interviewed; 2 from PM, 5from R&D and 6 from PIDS, resulting in 10 hours ofrecordings and over 140 pages of transcriptions.

4.3.2 Second and Third Degree Data Sources

In addition to interviews, data was collected throughdiscussions with employees from PM, R&D and PIDS.Specifically, employees having an overview of processesand work performed within the organizational unitspresented high-level descriptions for basic understand-ing of the current way of working.

Furthermore, an internal workshop relating to bot-tlenecks in the SD end-to-end flow was attended. Here,employees who previously participated in an interviewstudy gathered to discuss bottlenecks and possible en-ablers to remove them. From this workshop, an initialunderstanding to possible friction areas was given, ul-timately forming a basis for construction of the semi-structured interview guide.

As a complement to spoken information, archivaldata was used for understanding the organization andits process. For instance, process documentations andchecklists were investigated to deepen the understand-ing of the way of working and terminology used withinthe studied unit and project.

4.4 Data Analysis

While second and third degree data sources were mostlyused to provide a general understanding of the currentstate in the organization and to indicate possible fric-tion, the interviews were thoroughly analyzed in orderto extract and compare explicit statements related tofriction and the underlying causes identified by the in-terviewees.


The process used for this analysis followed basicprinciples from grounded theory [24], modified and ex-tended with a validation workshop and survey as out-lined in Figure 5.

Extraction & Individual Coding

Joint Refinement of Coding

Grouping of Statements

Categorization into Results

Identification of Friction

Validation Workshop & Survey

Integration of Validation Results

Section 5.1

Section 5.2

Section 5.3

Fig. 5 Data analysis process and related sections

Figure 5 shows how the word-by-word transcriptswere analyzed by the interviewers, starting with threesteps. First, relevant statements from three of the tran-scribed interviews were extracted and assigned a codeby each interviewer individually [24]. Second, the in-dividual coding was refined through joint cooperationwhere deviation in coding and non-overlapping in ex-tracted statements were taken into consideration [24].Finally, the extracted statements were collected intogroups containing statements on the same subject [24].

This process was then repeated for the ten remain-ing transcribed interviews, although with an establishedbase of categories the extraction and coding of state-ments was done individually, dividing the ten interviewsequally between the interviewers.

With an established set of groups, further refine-ment into categories was performed jointly, resulting inthe set of four results presented in Section 5.1. Fromthese results, specific instances of friction between rolesor individuals were analyzed with respect to interviewfindings and related work, the results of which are pre-sented in Section 5.2.

Finally, the friction instances were discussed at avalidation workshop complemented by a validation ques-tionnaire, which were conducted together with the 13interviewees. The workshop and questionnaire focusedon validating that each friction exists, whether or notit is related to a balance of agility and planning and ifthe friction was present before SD was introduced. Theresult of the survey is presented in Section 5.3.

4.5 Validity Threats

According to grounded theory, threats are divided intofour categorizes; fit, relevance, workability and modifi-ability [24]. However, in software engineering studies,threats are conventionally divided into the four cate-gories that will be used here; construct validity, inter-nal validity, external validity and reliability [23]. First,construct validity concerns the method of collecting themost valuable and accurate data for the study to beconducted. Second, internal validity primarily concernsexplanatory and casual studies. However, this study isof exploratory and qualitative nature, thus internal va-lidity is not considered. Third, external validity con-cerns the degree to which the study findings can begeneralized outside the study context. Finally, reliabil-ity concerns whether or not the study can be repeatedor replicated producing the same result.

4.5.1 Construct Validity

The interview results are highly dependent on the se-lection of interviewees. In order to obtain the best pos-sible sample, the selection of interviewees was made inclose collaboration with experienced Ericsson employ-ees, having extensive knowledge about the organizationand the employees as well as experience from conduct-ing similar internal studies.

Since both interviewers were external researchers,there is a risk that the interviewees’ answers were influ-enced. However, with support from experienced Erics-son researchers and given that it was a continuation onprevious research, it was not perceived as a large risk.In addition, the interviews were guaranteed anonymityin order to further mitigate the risk.

The risk of the interviewees misunderstanding thequestions or the interviewers misinterpreting the an-swers has been mitigated through several actions. First,the purpose of the study and all concepts used dur-ing interviews were explained to all interviewees priorthe interviews. Second, interview questions were com-piled in close collaboration with researchers and em-ployees internally at Ericsson as well as with externalresearchers. Finally, all interviews were recorded, en-abling the interviewers to follow up interviews for clari-fication and thereby resolve possible misinterpretations.

4.5.2 External Validity

Due to the limited time span of the case study, it hasbeen conducted at a single company, posing a potentialthreat to the generalizability. In order to mitigate therisk from the study being influenced by this, general


findings from previous research within the field of soft-ware engineering was mapped to the findings from thestudied Ericsson unit, thereby enabling general conclu-sions to be drawn.

4.5.3 Reliability

In order to mitigate the risk of the interview answersbeing misinterpreted by the researchers, data has beencollected from multiple sources, i.e. triangulated to en-sure the correctness of the findings, and validated bothindividually and collectively. First, documents describ-ing the current processes were studied, summarized andvalidated in order to have a complete understandingof the theoretical process prior to the interviews. Sec-ond, all recorded interviews were transcribed, summa-rized and sent to the respective interviewee for individ-ual validation and comments on the interviewers’ inter-pretations. Third, a workshop was held together withall interviewees, discussing and validating the findings.However, due to time constraints, only four frictionswere discussed during the workshop; F2, F3, F5 andF6. To compensate for this, a survey was conductedprior to the workshop using a questionnaire in order tocover those frictions omitted from the workshop, whilealso further triangulating the frictions included in theworkshop.

5 Results

Through the data analysis process used, interview find-ings were ultimately consolidated to four major resultcategories. These findings are presented in the next sub-section, followed by the identified friction instances de-rived from the categories and their relevance for balanc-ing agility and planning. The section is then concludedwith the findings and analysis of the conducted valida-tion workshop and survey.

It should be noticed that this study is aiming atidentifying potential friction from using a balanced pro-cess of agility and planning. With this focus on fric-tion, the results tend to seem negative. However, theSD transition has generally provided substantial im-provements throughout the organization at the studiedEricsson unit. Despite that, this section only reflectsmomentary issues, it does not go into depth regard-ing general improvements or possible issues related tothe transition, it only focuses on the current balancebetween agility and planning. Furthermore, the resultspresented in the following sections are highly dependenton a small sample of interviewees in relation to the sizeof the organization and their subjective opinions on theway of working. The presented result should therefore

not be considered as fact but rather individual viewsand opinions grouped together to describe the currentsituation from multiple perspectives.

5.1 Interview Findings

Findings from the interviews have been consolidatedinto four result categories, R1-R4, as summarized inTable 3 and further detailed below.

R1. Undefined communication interfaces

Interviewees agreed that it is often unclear who to con-tact regarding a specific errand, i.e. communication in-terfaces in the organization are partly undefined. Mostly,interviewees stated that they rely on previous contactsand experiences when a need for communication arises,leading to a self-organized and informal exchange of ser-vices and favors. In general, self-organizing within agilesoftware development is desired [8], but in this specificcase unwanted effects have been noted.

For example, the relation between PM and devel-opers in R&D is occasionally informal, even though SDspecifies formal ways of communicating, i.e. cornerstone1-3. This informality has resulted in unclarity regardingon what grounds PM base promises toward customerson and what grounds developers base promises to PMon. It has also resulted in unclarity regarding responsi-bilities associated with the respective roles.

Specifically, developers tend to contact PM regard-ing development specific issues, which PM consider notto be their responsibility to answer since they do notwant to become an internal source of requirements withthe risk of loosing customer focus, leading to a devel-opment organization without any market perception.Instead, it is desired by PM that the R&D organiza-tion should be elevated to a level where they can solvetheir specific issues without PM involvement.

Another example of this informality is that resourcesperforming work in PIDS are usually taken from teamsin R&D since the PIDS organization is too small andlack sufficient competence to correct errors and fix bugs.For this purpose, a formal interface for resource alloca-tion exists but still the informal contacts are faster andtherefore more often used, resulting in uncertainty re-garding what resources are available at a specific pointin time. In the end, this affects the flow end-to-end inthe organization; PM cannot be asserted on a commit-ted scope since R&D cannot know whether developersare working on new feature development or fixing bugs,risking delayed delivery affecting PIDS’s time plan.

This unclear interface between R&D and PIDS isotherwise apparent regarding the handover at PRA.


Table 3 Summary of interview findings

ID Description

R1 Undefined communication interfaces between agile and plan-based parts of the organization have led to unclearareas of responsibility

R2 The deliberate isolation of agile organizational units limits possibilities for understanding how one’s work affectsother parts of the organization

R3 Agile and plan-based parts of the organization have different time and quality limitationsR4 The desired extent of customer involvement differs between agile and plan-based parts of the organization

Here, the expectations on the details of what to be de-livered differ between R&D and PIDS. For instance,R&D realize that PIDS have a need for documenta-tion, but it is hard for them to know in detail what todeliver. At the same time, PIDS realize that R&D needand want quick feedback, but find it hard to locate aspecific person or role to use as a feedback channel.

As a possible effect, the responsibility to updatedocuments describing the processes had been lost inthe gap between R&D and PIDS, which led to docu-ments containing erroneous data concerning agreementsof hand-over dates from the agile R&D organization tothe plan-based PIDS organization. PIDS were still re-lying on the agreements stated in the documents whileR&D in their new agile way of working had no possibil-ity to commit to these fixed hand-over dates as beforethe transition.

Furthermore, the unclear interface has led to re-sponsibilities belonging to R&D being taken care of byemployees in the PIDS organization. PIDS argue thatquality assurance work and responsibility that shouldrest on developers or teams in R&D now have been in-formally put on PIDS. However, R&D is utilizing thepossibility created by SD to incorporate features late inparallel to PIDS’s FOA work in order to achieve fasterdelivery rather than delaying the whole scope.

R2. Possibilities for understanding

PM, R&D and PIDS have deliberately been built upas separate units of the organization, most noteablythrough PIDS’s separation in accordance with SD’s fifthcornerstone. The conducted interviews show that thishas led to a separation of decision making with an un-wanted effect on understanding the importance and im-pact of work performed by others.

Apparently, existing dependencies between the unitshave become hard to see from the employee perspectivein all different parts of the organization. In general,employees are not aware of how their own work affectothers’, a finding that is well rooted in R&D who arguethat PIDS do not know how SD works in detail as wellas in PIDS who argue that R&D do not know whathappens after development or how the release and FOAprocedures are executed.

Within R&D, the general opinion is that it is clearlystated that development teams should be isolated, whichfrom their own perspective is perceived as beneficialsince they can focus on developing features with highquality without being disturbed. At the same time,they want to receive adequate information from thesurrounding world both internally from Ericsson andexternally from the market.

From the PM perspective, it is clear that the de-velopment teams in R&D want stability and continuitywhile receiving requirements to develop features with-out interference from PM. However, it is desired fromteams in R&D that PM is present at the start-up meet-ing for new feature development in accordance with theSD process in order to give another perspective on theoften very technical requirements mediated by systemmanagers.

From the R&D perspective, the separation betweenR&D and PIDS is seen as a proof that R&D does notneed to have any contact with PIDS since they do theirown things. However, from PIDS perspective this is seenas if incentives for delivering features on time have beenremoved, since without contact with people affected bydelays, developers will not understand why deliveringon time is crucial for other parts of the organization.

Employees in the PIDS organization blame R&Dfor delaying the agreed date for PRA, which in facthas been delayed several months on occasions. PIDSdoes not have insight in the difficulties with breakingdown features to deliverable anatoms and is thereforeexperiencing that R&D has been given a possibility tonot deliver on time according to the principles of SD,stating that a committed feature can be delayed andre-committed to a later release or canceled altogether.Thus, plan-based organizational units see the desire oftotally isolated teams as a dangerous mindset, arguingthat it is important for developers to not believe thatSD has been introduced to provide tools enabling themto delay features rather than increasing speed throughdevelopment.

Specifically, it is assumed by developers that theirrespective team leader should communicate delays andwarn for possible late deliveries toward higher managers


in the R&D line organization in accordance with theformal process. However, escalation from the individ-ual developer through team leaders and managers to-ward PIDS does not always occur early enough, whichPIDS blame the team isolation for since it defers re-sponsibility for the delayed delivery outside the teamsphere, making the team unable to understand the con-sequences that arise for PIDS when information regard-ing delays does not reach them in time.

In the end, the lack of understanding how others’work is affected by one’s actions has led to severalmisunderstandings reoccurring in the daily work. First,the organization is never learning from delays occurringat PRA because of the achievement of delivering highquality at GA, making occasional delays at PRA appearless important and reducing the experienced need forfeedback. However, by not improving or receiving feed-back on the effects of delaying PRA, the scheduled timefor validation during FOA shrinks, putting higher loadon the PIDS organization to do their work on shortertime. Second, PM and developers make promises with-out consulting PIDS on how the promises can be re-alized during the release process, forgetting that test-ing, integration and verification should be included inpromises to the customers. Third, PIDS are requestinginformation and documents from R&D which they canno longer deliver early due to their agile way of workingwhere documentation is done after a feature has beencompleted.

R3. Different time and quality limitations

At the incoming end of the studied unit, PM exhibitspressure regarding delivery date and scope from thecustomer, which is passed on to R&D. Simultaneously,at the outgoing end of the studied unit, PIDS exhibitspressure from customers regarding both time and qual-ity of deliveries, which in turn is passed on to R&D.Thus, different parts of the organization experience pres-sure from different directions, resulting in priorities dif-fering between organizational units.

For instance, it was expressed explicitly by intervie-wees that meeting a delivery deadline has higher prior-ity than continuing development of features for the nextrelease. Additionally, R&D expressed that they under-stand that PM has to promise to deliver a set scope at acertain point in time due to the selling pressure they areunder, otherwise they will be outrivaled by Ericsson’scompetitors.

R&D’s perception is that most often is time of high-est priority and feature content is of less importance aslong as deadline is met and delivery is made on time.Interviewees stated that a feature delayed at PRA canbe included in the release during FOA since several

workarounds can be utilized. The feature can either bepatched in, be added to a new build just prior to generalavailability or decreased in scope. While seen by PMand R&D as a possibility to incorporate features latefor quick delivery to customers, the experience withinPIDS is that this affects their time-plan by creatingadditional work.

Similar backups do not exist for PIDS, who aretightly bound to meet the assigned time slot at the cus-tomer site during FOA. It is therefore argued by PIDSthat the date for general availability is prioritized overthe date for PRA since the deadline toward customersmust be met in order to maintain a leading market po-sition, but the deadline toward PIDS can be stretched.The result of this is that PIDS experience reduced qual-ity during FOA, having more trouble reports to be cor-rected and extra work to be conducted during a shortertime span than planned.

In addition, it has been stated that the last deliveryprior to PRA is usually not an increment of the feature,rather the entire feature, which is argued to be a causalfactor to delayed PRA. This problem stem from a se-ries of difficulties that the developers have to cope with.First, because of problems with integration and differ-ent test scopes on the development branch and the mainbranch, developers know that quality on the develop-ment branch is irrelevant. No matter the level of quality,integration always results in problems which cannot betraced back to its derivation. Second, teams have notbecome accommodated with feature breakdown, result-ing in deliveries of features rather than anatoms in con-trast to what is stated in the SD cornerstones.

Consequently, the main branch is not of desired qual-ity, which in turn means that there are many defectsto correct at the end of a development cycle in or-der to reach the quality level expected by customers.This has therefore created a quality gap between pre-liminary builds and builds going out to customers. Al-though it has been stated that delayed general avail-ability date is unacceptable, the high concentration ofintegrations close to the last date for delivery has adirect effect on the possibility to be ready for generalavailability, mostly stressing PIDS who cannot utilizeany workarounds to compensate delays.

R4. Desired extent of customer involvement

The customer requirements are passed from customersto developers in R&D through PM and system man-agers and can therefore sometimes become distorted onthe way. Although a feature has been developed ac-cording to specification, PM sometimes misinterpretswhat the customer actually means, which may resultin delivery of a feature not matching the customer’s ac-


tual needs. However, employees in R&D argue that thiscould be avoided by having initial customer involve-ment when starting the development of new features.Customers would then be able to explain their actualneeds directly to developers, give feedback on possiblesolution suggestions and answer any questions on im-plementation details where PM lack competence, ulti-mately limiting the risk of developing the wrong featureor developing the feature incorrectly.

Although developers have stated that more customerinvolvement would be desirable, PM is under the im-pression that R&D wants stability and continuity with-out disturbance from customers. Furthermore, PM doesnot allow customers to directly affect the developmentenvironment where teams develop features for the massmarket. In the large-scale setting of Ericsson, obtainingtoo much influence by one close customer relation outof hundreds possible is by PM argued to be undesiredsince the feature might become too customer specific,serving one rather than all customers.

Apart from sometimes misinterpreted requirements,too low direct involvement has led to the developmentunit not acquiring adequate information regarding whya customer wants to participate in FOA and what isimportant for that particular customer. Since a par-ticular test scope is set for each FOA, this ultimatelyproblematizes prioritization of features and trouble re-ports during development. Because of this, all featuresdo not always get acceptance tested, which producesmuch additional work afterwards for PIDS. However,R&D states that with better knowledge regarding theFOA customer and the reason for FOA, priorities dur-ing development would improve.

5.2 Identified Friction

Apart from assessing the current state of balance be-tween agility and planning, the results in the previoussection were further analyzed in order to characterizefriction according to the definition in Section 2.2. In to-tal, seven instances of friction were identified betweenagile and plan-based parts of the organization (See Fig-ure 6).

PM F2F3

F1R&D PIDSF5

F7

F4

F6

Plan-‐based Plan-‐basedAgile

Fig. 6 Friction is present between agile and plan-based partsof the organization

The seven friction instances are elaborated below,complemented with explicit statements from the con-ducted interviews that highlights expectations and ac-tual observations spoken from employees in PM, R&Dand PIDS.

F1. Friction in the responsibilities to detailcustomer requirements

It has been shown from the interviews that it is un-clear where in the organization the responsibility lies forproviding implementation details to the developmentteams. This friction is derived from the result R1 andis further concretized through the following quotes:

”There is an expectation within R&D that PM

should feed them with requirements specific enough

for implementation” (From PM)

”R&D must elevate themselves, fill in blanks and

investigate fuzzy requirements on their own” (FromPM)

While R&D expect PM to answer questions regard-ing development details, PM lack detailed implemen-tation knowledge and do not want to be an internalsource of requirements since they fear loosing customerfocus and market perspective due to increased work-load. PM therefore expect R&D to elevate to a levelwhere they can resolve implementation details withoutPM involvement. However, with the current situationof isolation of R&D and the lack of sufficient customerinvolvement, PM experience that R&D actually awaitinput rather than taking action on their own.

F2. Friction in the degree of customerinvolvement

From the interview results, it was clear that PMand R&D had different perspectives on the degree ofcustomer involvement, i.e. R4, and that teams in R&Dexpect PM to be present at start-up meeting for fea-tures, i.e. from R2, two aspects that are illustrated bythe quotes below:

”Customers should not be directly involved in

development since that will give very few key-

customers too much influence” (From PM)

”It was decided that PM should attend start-up

meetings for features, but I have not experienced

that yet” (From R&D)

Here, friction has appeared since teams expect asmuch customer involvement as possible in order to ac-quire adequate information to develop the correct fea-ture with high speed. However, PM do not want cus-tomers to be directly involved in features that are de-veloped for the mass-market since it will give them toomuch influence, which is illustrated by the first quote.


As a current trade-off, PM is expected to act as amediator of customer needs in parallel to system lead-ers mediation of technical requirement descriptions, butR&D experience that PM actually are not present atthe start-up meetings as agreed which is illustrated bythe second quote. This spurs R&D to request direct cus-tomer contact, contrasting the view from PM and cre-ating friction in the understanding between the roles.

F3. Friction in committing to a scope orallowing the time needed by teams

The result in R3 clearly shows how R&D under-stands that PM has to commit to a scope. However, italso shows that R&D still experience that the develop-ment unit is under large pressure due to the promisedscope being too large, which is illustrated by the fol-lowing quote:

”PM have sold something that customers expect

at a certain time, but sometimes we should allow

the time it takes in order to develop a feature”

(From R&D)

While there is a mutual understanding that a scopehas to be set despite the agile way of working withinR&D, their expectation on a feasible scope is not alwaysexperienced to be met by PM, occasionally resulting ina feeling of overload within R&D. At the same time,PM expects R&D to commit to delivering features at acertain time, but with the high pressure in R&D it ishard for teams to commit. Thus friction is created inthe relation, occasionally resulting in that PM bypassesthe formal structure set by SD in order to get teams tocommit to deliveries, indicating that PM has a need tobe more agile than the current process allows.

F4. Friction in understanding others’ way ofworking

Following the result in R2, it is clear that there is alack of understanding regarding others’ way of workingand how one’s own work affect other parts of the orga-nization. Specifically, the deliberate separation betweenR&D and PIDS has created barriers between them,which is illustrated in the following quotes:

”I believe that PIDS does not have any real in-

sight regarding how SD works, at least not in de-

tail” (From R&D)

”Employees in R&D do not have a clear picture

of work performed after development; they see it

as somebody else taking care of post development

matters” (From PIDS)

The perception within R&D is that the isolationis beneficial, leading to more focused development andthereby higher quality. Howeverm, PIDS experience thatR&D want to be isolated and separated from PIDS butstill expect R&D to understand how their agile way ofworking affect PIDS. In contrast, R&D expect PIDSto understand the development context of SD, but ex-perience that PIDS have no detailed understanding ofR&D’s way of working.

Thus, friction is present between R&D and PIDS,since both organizational units expects mutual under-standing of the way of working, but actually experiencethat there is no interest in understanding how otherswork.

F5. Friction in incentives for delivering ontime

From R2, it was identified that PIDS experience theisolation of teams within R&D as something negative,since it removed incentives for delivering on time asillustrated below:

”Unclarity arises when PIDS work toward the

customer while R&D continues development at

the same time; responsibilities are more difficult

to define when development is not done as com-

mitted” (From PIDS)

Clearly, PIDS expect R&D to deliver on time, butactually experience that there is no incentive for R&Dto deliver as committed, since there exist several work-arounds for incorporation of late features. On the otherhand, R&D expects that they can work according to SDwith possibility to e.g. deliver partial features withoutnegative effects. However, with PIDS following a plan,friction is experienced when changes are made that af-fects the plan with respect to time and content of therelease.

F6. Friction in communicating delays andunderstanding their impact

From the result categories R2 and R3, friction hasbeen identified in relation to communication betweenR&D and PIDS regarding delayed deliveries, tightly re-lated to both friction F3, F4 and F5:

”It was not escalated from R&D that the feature

was not in the release, it felt as if they did not

realize, did not want to realize or did not listen

to the team” (From PIDS)

As illustrated by the quote, PIDS expect R&D tocommunicate delays or scope cuts, but experience thatR&D does not communicate early enough. On the other


hand, R&D expects that PIDS do their own thing andare not affected by delays, but PIDS actually has toredo the plan if delays occur. For the purpose of com-municating changes and delays, formal ways are presentin the SD process. However, friction has still arisen, in-dicating that the formal ways might not be clear enoughor not sufficiently agile in relation to the balanced wayof working.

F7. Friction regarding the possible degree ofdocumenting features

From R1 and R2, it is clear that friction exists be-tween R&D and PIDS regarding documentation of fea-tures and the expectation to receive documents at acertain point in time during the release cycle. This isillustrated through the following quote:

”PIDS are asking for documentation early but

it can often not be delivered until the teams are

done with developing the feature” (From R&D)

With the transition to SD, the focus has shifted fromtraditional development with extensive documentationtoward agility where documentation is seen as wasteand therefore should be reduced as much as possible.With this agility, R&D has no possibility to deliverdocuments up-front when little is known or decided.In addition, documents detailing progress in the teamexist during feature development but they are usuallynot delivered to PIDS along with the feature. However,since PIDS are still using a traditional plan-based pro-cess, they expect R&D to deliver documents as beforethe SD transition. For PIDS, these documents are im-portant and beneficial in order to prepare their work.Without them, an obstacle is created hindering PIDSto follow their planned process.

5.3 Validation Survey Findings

From the survey that was conducted through a ques-tionnaire with the 13 interviewees, validation data wasgathered in relation to the seven instances of frictiondetailed in the previous section. For each friction, re-spondents were asked to rank the degree of impact ontheir individual work, the degree of presence of the fric-tion before SD was introduced and if so, how the nega-tive impact has changed after the SD introduction. Theconsolidated result from the questionnaire is shown inTable 4.

Table 4 Validation questionnaire result

Impact on Presence ChangeID Own Work Before SD of Impact

F1 Medium High →F2 Medium High →F3 Very high Medium �F4 High Medium �F5 High High �F6 High Medium �F7 High Medium �

From Table 4 it is clear that all frictions were presentbefore SD was introduced, although to a greater extendbetween PM and R&D than between R&D and PIDS.In contrast, friction between R&D and PIDS impact thedaily work more than friction between PM and R&D.Additionally, the survey indicates that the negative im-pact has increased between R&D and PIDS while re-maining unaffected between PM and R&D by the tran-sition to SD. Together, this indicates that the relationbetween R&D and PIDS is to a larger extent exposed toSD related friction than the relation between PM andR&D.

Furthermore, respondents distributed a total of 100points between the seven frictions, assigning most pointsto the friction they felt most urgent to minimize in orderto achieve higher speed end-to-end in the organization.The average distribution from the 100 points rankingis illustrated in Figure 7.

0F2 F3 F4 F5 F6 F7

5

10

15

20

25

30

F1

Points (average)

9 9

27

1516

14

10

Fig. 7 Average distribution of respondents’ priority ranking

From Figure 7 it is clear that the prioritization madeby respondents correlates to the results of Table 4, i.e.F3 is the friction that affect the interviewees the mostas well as the friction most urgent to resolve.


Apart from F3, it is clear that respondents rankedfriction between R&D and PIDS as most urgent to re-solve. This indicates that the transition to SD has im-pacted the relation between R&D and PIDS more thanthe relation between PM and R&D. In that context, F3is hard to take into account since it appears betweenPM and R&D but has effects further down the line be-tween R&D and PIDS. With this cross-organizationaleffect, the reason for F3 being ranked as more urgentmight be explained by the simple notation that moreemployees are affected by it, i.e. it has a higher end-to-end impact.

6 Discussion

The result from this case study shows that the end-to-end perspective, i.e. the focus on optimizing the wholerather than separate organizational units, can be im-proved throughout the studied unit. This is most ap-parent in the friction regarding understanding others’way of working, where it was identified that employ-ees within both R&D and PIDS were reluctant to gaindeeper knowledge of each others’ processes. It can beargued that without this knowledge, it becomes moredifficult for the units to optimize their work in a waythat is beneficial for the entire organization, i.e. theunits risk sub-optimization.

To concretize, interview findings indicate that PMand R&D have embraced mechanisms of SD that allowfor changes in scope and reprioritization late in the de-velopment cycle, seen by PIDS as removed incentivesfor delivering on time and a lack of communicatingdelays and understanding their impact. Even thoughPIDS experience extra work load with scope changesnear the end of a development cycle, SD has enabled asignificant reduction of feature throughput time. Thus,it can be argued that PIDS are not considering thewhole organization and its opportunity to satisfy cus-tomer requests, i.e. a mutual understanding of benefi-cial scope changes exists between PM and R&D, butits positive effects from an end-to-end perspective arenot acknowledged by PIDS.

This is further supported by the friction regard-ing the possible degree of documenting features, wherePIDS requests early delivery of documents from R&D,but does not realize that R&D cannot produce thesedocuments upfront. Although, to ensure agility in de-velopment with high throughput, R&D are forced topostpone documentation of features and releases. Whileaffecting PIDS negatively, this can be seen as a prereq-uisite for an end-to-end optimization.

In contrast, a similar lack of understanding was notidentified between PM and R&D, but as the validation

survey indicated, friction between the two units wereto a less extent affected by the SD introduction. Forinstance, this might be the result of a matured rela-tionship between PM and R&D. However, it might alsobe an indication that PM has become more agile asan adaption to changing market conditions, improvingtheir capability of understanding R&D’s agile practicesintroduced with SD.

Despite the reason, friction identified between PMand R&D seems to concern priorities in the value-streamof a feature, i.e. where to focus the organization’s re-sources in order to optimize feature throughput froman end-to-end perspective. For instance, priorities differregarding the responsibility to detail customer require-ments, where R&D expects PM to mediate details fromcustomers but PM fears loosing customer focus. It cantherefore be argued that PM puts most value on gath-ering and adapting customer requirements in contrastto R&D who values understanding details of featurescurrently in development the most.

As a possible consequence of this valuation con-flict, friction in the degree of customer involvement hasarisen. With R&D putting high value on acquiring fea-ture details in combination with PM putting low valueon acting as surrogated customer while discouragingdirect customer involvement, it can be argued that fur-ther improvements from a end-to-end perspective is dif-ficult to achieve unless the units are willing to adapt orchange their current way of working.

Altogether, the lack of understanding between R&Dand PIDS and the difference in valuation between PMand R&D indicates a need for expansion of the agilepractices currently present in R&D to both PM andPIDS in order to instigate an end-to-end perspective.

These findings are supported by several previousstudies. First, Karlstrom and Runeson concluded intheir research that cross-organizational acceptance iscrucial for a successful combination of agile and plan-based processes [12, 13]. This supports the above discus-sion where it was argued that insufficient understand-ing of others’ way of working inhibits optimization ofthe whole, i.e. without a cross-organizational end-to-end perspective the combination of agility and planningis less likely to succeed.

Second, the research by Petersen and Wohlin indi-cates that transitioning from plan-based to agile soft-ware development in a large-scale setting increases prod-uct packaging and release effort due to increased num-ber of releases [20]. Similar observations have been madeduring this study, where the effect of enabling faster fea-ture throughput in R&D has resulted in increased re-lease effort for PIDS. However, it is here distinguished


that the increased release effort is beneficial from anend-to-end perspective.

Third, Petersen and Wohlin suggested in anotherstudy that the release organization should be integratedwith the development organization [21]. This sugges-tion can directly be related with this study, strengthen-ing the observation that PIDS’s separation from R&Dhas negative consequences on optimization of the wholeorganization. Furthermore, it provides a concrete im-provement suggestion, which is in line with the abovediscussion on expanding agile practices from R&D toPIDS.

Finally, Lindvall et al. concluded in their researchthat clarifying and specifying the interfaces between ag-ile and plan-based parts is required for a successful bal-ance [15]. This conclusion supports the finding in thisstudy that indicates how a lack of clear interfaces be-tween organizational units decreases the possibility toimprove work in a way that is beneficial for the wholeorganization, i.e. obtaining a successful balance.

Despite the support for this study’s findings in pre-vious research and related work, it should not be ruledout that the findings might have other causes. For in-stance, it is important to notice that the study was con-ducted at a single development unit with a condensedselection of interviewees. Although selected to cover rel-evant roles as well as knowledge of the previous way ofworking, a tendency amongst interviewees were to re-late to the ideal theoretical and not the actual way ofworking when making comparisons to the current stateof SD.

Furthermore, it should be noted that through theuse of grounded theory, the extraction and grouping ofstatements from interview transcripts is subjective tothe authors’ interpretations. Additionally, some of thederived friction instances could possibly be combinedto a single entity, e.g. F3, F5 and F6 could be joinedbut were kept separate in order to visualize their cross-organizational presence.

For further research, it is specifically suggested todeeper investigate how organizational structures incor-porating both agility and planning affect the end-to-endperspective. Furthermore, the evolution of SD at thestudied Ericsson unit indicates a need for research fo-cusing on identifying enablers to partially or completelytransition a large-scale software development organiza-tion to an agile way of working.

For the studied unit in particular, it is suggestedto incorporate PM and PIDS in the agile way of work-ing within R&D in order to reduce the observed fric-tion. With more incorporated organizational units, theunderstanding of others’ work and valuations should

increase, resulting in lower barriers to achieve a cross-organizational end-to-end perspective.

For instance, PM can become more agile through co-location with managers of R&D and PIDS. That wouldenable them to become more flexible in their communi-cation, which due to higher continuity could trigger aconsciousness of PM to consider the whole organizationwhen a promise is made or a decision is taken.

In addition, PIDS can become more agile throughinclusion in the cross-functional reams in R&D. Thiscould be achieved through creation of linking roles, i.e.dedicating a PIDS employee part-time in a team-rolehaving an outspoken focus on the release activities.Thus, it would enable instant information from PIDSto other team members within R&D while providingPIDS with better insight into ongoing R&D activities,altogether acting to shorten feedback loops.

However, barriers exist to spread agility in the or-ganization. For example, PM must accept to dedicatemore of their time to development and release ratherthan gathering and adapting customer requirements.Additionally, PIDS would need more resources in orderto have fixed roles in R&D activities and their commit-ment to customer time-slots inhibits them from becom-ing fully agile in the current market environment.

7 Conclusion

The intention of this study was to characterize fric-tion between agility and planning in a large-scale soft-ware development setting, while identifying the effectof friction on the end-to-end speed in the organization.Through a simple friction framework capturing employ-ees’ expectations and actual observations, it was iden-tified that friction was present between agile and plan-based parts of the organization.

The friction identified was related to responsibilitiesin detailing customer requirements, use of in-house sur-rogated customers, committing to a scope or allowingdevelopment to take the time needed, understandingothers’ way of working, incitements for delivering ontime and the need for communicating delays.

Altogether, the findings support that the end-to-end perspective can be improved throughout the or-ganization. With the current separation of agile andplan-based organizational units, a clear lack of under-standing others’ work and valuations limits further op-timizations of the whole organization. It is thereforesuggested to incorporate plan-based units into the agileway of working to lower barriers of achieving a cross-organizational end-to-end perspective.

These findings are important contributions to thestudy of large-scale agile software development thanks


to its contribution of empirical data on a current sparselyinvestigated subject. In terms of future research, it issuggested to deeper investigate end-to-end perspectivein relation to organizational structure and to identifyenablers for large-scale agile transitions.

References

1. Agile Alliance: Agile Manifesto.http://www.agilemanifesto.org [Last accessed110217] (2001)

2. Akerman, N.: The necessity of friction: nineteen es-says on a vital force. Physica-Verlag (1993)

3. Beck, K., Andres, C.: Extreme Programming Ex-plained: Embrace Change (2nd Edition). Addison-Wesley Professional (2004)

4. Boehm, B., Turner, R.: Balancing agility and dis-cipline: A guide for the perplexed. Addison-WesleyProfessional (2003)

5. Boehm, B., Turner, R.: Using risk to balance agileand plan-driven methods. Computer 36(6), 57–66(2003)

6. Cao, L., Mohan, K., Xu, P., Ramesh, B.: Howextreme does extreme programming have to be?adapting xp practices to large-scale projects.Hawaii International Conference on System Sci-ences 3, 30,083c (2004)

7. Cao, L., Ramesh, B.: Agile requirements engineer-ing practices: An empirical study. IEEE Software25(1), 60–67 (2008)

8. Cockburn, A.: Agile Software Development.Addison-Wesley (2002)

9. Dacker, B.: Concurrent functional programming fortelecommunications: A case study of technology in-troduction. Ph.D. thesis, KTH Royal Institute ofTechnology Stockholm (2000)

10. Dyba, T., Dingsøyr, T.: Empirical studies of agilesoftware development: A systematic review. Infor-mation and Software Technology 50(9-10), 833–859(2008)

11. Highsmith, J., Cockburn, A.: Agile software de-velopment: the business of innovation. Computer34(9), 120–127 (2002)

12. Karlstrom, D., Runeson, P.: Combining agile meth-ods with stage-gate project management. IEEESoftware 22(3), 43–49 (2005)

13. Karlstrom, D., Runeson, P.: Integrating agile soft-ware development into stage-gate managed prod-uct development. Empirical Software Engineering11(2), 203–225 (2006)

14. Liker, J.K.: The Toyota way: 14 managementprinciples from the world’s greatest manufacturer.McGraw-Hill Professional (2004)

15. Lindvall, M., Muthig, D., Dagnino, A., Wallin, C.,Stupperich, M., Kiefer, D., May, J., Kahkonen, T.:Agile software development in large organizations.Computer 37, 26–34 (2004)

16. Mehta, M., Anderson, D., Raffo, D.: Provid-ing value to customers in software developmentthrough lean principles. Software Process: Improve-ment and Practice 13(1), 101–109 (2008)

17. Middleton, P.: Lean software development: Twocase studies. Software Quality Journal 9(4), 241–252 (2001)

18. Middleton, P., Flaxel, A., Cookson, A.: Lean soft-ware management case study: Timberline inc. In:Baumeister, H., Marchesi, M., Holcombe, M. (eds.)Extreme Programming and Agile Processes in Soft-ware Engineering, Lecture Notes in Computer Sci-

ence, vol. 3556, pp. 1297–1298. Springer Berlin /Heidelberg (2005)

19. Petersen, K.: Implementing Lean and Agile Soft-ware Development in Industry. Blekinge Instituteof Technology (2010)

20. Petersen, K., Wohlin, C.: A comparison of issuesand advantages in agile and incremental develop-ment between state of the art and an industrialcase. Journal of Systems and Software 82(9), 1479– 1490 (2009)

21. Petersen, K., Wohlin, C.: The effect of moving froma plan-driven to an incremental software develop-ment approach with agile practices. Empirical Soft-ware Engineering 15(6), 654–693 (2010)

22. Poppendieck, M., Poppendieck, T.: Lean SoftwareDevelopment: An Agile Toolkit. Addison-WesleyLongman Publishing Co., Inc. (2003)

23. Runeson, P., Host, M.: Guidelines for conductingand reporting case study research in software en-gineering. Empirical Software Engineering 14(2),131–164 (2009)

24. Strauss, A.L., Corbin, J.M.: Basics of qualitativeresearch: Techniques and procedures for developinggrounded theory. Sage Publications, Inc (1998)

25. Sutherland, J.: Agile can scale: Inventing and rein-venting scrum in five companies. Cutter IT Journal14(12), 5–11 (2001)

26. Talby, D., Hazzan, O., Dubinsky, Y., Keren, A.:Agile software testing in a large-scale project. IEEESoftware 23, 30–37 (2006)

27. Tomaszewski, P., Berander, P., Damm, L.O.: Fromtraditional to streamline development - opportuni-ties and challenges. Software Process: Improvementand Practice 13(2), 195–212 (2008)

28. Womack, J.P., Jones, D.T., Roos, D.: The MachineThat Changed the World : The Story of Lean Pro-duction. Simon & Schuster New York (2007)

19

Appendix I – Interview Questions QID Question/Information

A Non-disclosure of interviewees opinions, how the recording and findings will be used B Describe the background and purpose of the study C Set the focus on agility and planning D Describe common terms that will be used during the interview

Q1 Formal role and performed activities

! Can you briefly describe your history at Ericsson? ! What is your current role and what responsibilities do you have? ! What actual activities do you perform in your work?

! Do you perform anything outside your role or responsibility?

Q2 Observed friction in general ! Given the vision of delivering to any customer at any time, what friction can

you see between R&D and PIDS (Product Integration, Deployment and Support)?

Q3 Friction in relation to the way of working

! Would you say that your current way of working is agile, plan-based or a mix? How does this affect your daily work?

! Has the vision of delivering to any customer at any time affected your own work and interaction to other departments?

! Do you feel that your ability to control your own (and if applicable also others') work has changed after SD (Streamline Development) was introduced?

Q4 Friction in relation to organizational structure

! Given that SD deliberately has separated R&D and PIDS, have this created any problems for you or other colleagues/stakeholders?

! Do you feel that responsibilities regarding product responsibility, network impact reports and upgrades is clear after delivery from R&D to PIDS (i.e. after PRA)?

! Do you feel that your communication with customers is sufficient? Do you get feedback from customers regularly?

! Where needed, is the communication interface between R&D and PIDS (or between other agile/plan-based parts) clear and specified anywhere?

! Do you know your colleagues' skills and knowledge areas? Do you know what they are working on right now?

! During your time at Ericsson, have you been included in work at other parts of the organization?

Q5 Friction in relation to technology and external forces

! How do you think that the vision of delivering to any customer at any time involves the customer?

! Does interoperability to other network products, including competitors’, require a limitation of our flexibility? Should we develop to support everything requested from customers?

20

! How do you think FOA (First Office Application) will be driven going forward? Does the current vision impose any changes to the current procedure?

! Do you have tools capable enough to support your work according to the vision of delivering to any customer at any time?

Q6 Prioritizing friction and improvements

! Given the friction we discussed, what impacts your work the most? What are your top three observed frictions?

! Do you have any suggestions on how the friction we discussed can be minimized or removed?

! What do you feel is working really well in your current way of working? Is this related to the vision in any way?

Q7 Open-ended questions

! Is there anything you expected us to ask that we did not? ! Do you have any questions for us so far?

21

Appendix II – Survey Questions Survey for validation and prioritization of friction between agile software development and plan-based business processes in the different organizational parts

F1: Friction in the responsibilities to detail customer requirements

A – To what degree was this friction present prior to the introduction of Streamline Development?

Small -2 -1 0 1 2 Large

B – How has the friction’s (negative) impact changed after the introduction of Streamline Development?

Smaller -2 -1 0 1 2 Larger

C – To what degree does the friction impact your individual work?


F2: Friction in the degree of customer involvement







F3: Friction in committing to a scope or allowing the time needed by teams







22

F4: Friction in understanding others’ way of working







F5: Friction in incentives for delivering on time







F6: Friction in communicating delays and understanding their impact







23

F7: Friction regarding the possible degree of documenting features







Prioritization: Divide totally 100 points between frictions F1-F7 below; give each friction 0-100 points where each point indicates which friction you subjectively find most urgent to resolve in order to receive a better flow in the organization.

Number of points (0-100 per friction, 100 in total)

F1 F2 F3 F4 F5 F6 F7

24

Appendix III – Example Material from Workshop

Workshop: Friction between agile software development and plan-based business processes | Ericsson Internal | 2011-05-12 | Page 1

!"#$ !%&'(&)*#%+,-%.&*,#')/&((&*,#()#-#0')1+#)%#-22)3&*,#(4+#(&/+#*++.+.#56#(+-/0

!"#$%&'%#($#)'**+#,-#"''&)#($#.%$/0)'#12)($/'%)#3#

1'%(30"#)1$.'

,- 456

456#'7.'1()#,-#($#)'(#3#8'3)09*'#)1$.'

,-#'7.'1()#456#($#&'*0:'%#.%$/0)'&#)1$.'#$"#(0/'

456#0)#8$%1'&#($#.%0$%0(0;'#(0/'#$:'%#<23*0(=

! 60)12))#(>'#8%01(0$"#39$:'#8%$/#(>%''#.'%).'1(0:')?

@A#!)#(>'#0**2)(%3(0$"#39$:'#1$")0)('"(#B0(>#=$2%#.'%1'.(0$"#$8#(>'#)0(23(0$"C

DA#!)#(>'#8%01(0$"#3#%')2*(#$8#(>'#93*3"1'#9'(B''"#3E0*'#3"&#.*3"F93)'&#$%#)$/'(>0"E#'*)'C

GA#60&#(>'#8%01(0$"#'70)(#.%0$%#($#(>'#0"(%$&21(0$"#$8#H(%'3/*0"'#6':'*$./'"(C#!8#)$+#>$B#>3)#0(#1>3"E'&C

!"#$%&'()''&"*

identifying friction between large-scale agile …feldt/teaching/master_theses/...in the following...

Documents