application of agile in product-service system development · relational uncertainty may arise in...

General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

Users may download and print one copy of any publication from the public portal for the purpose of private study or research.

You may not further distribute the material or use it for any profit-making activity or commercial gain

You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim.

Downloaded from orbit.dtu.dk on: Aug 12, 2020

Application of Agile in Product-Service System Development

Ramirez Hernandez, Tabea; Kreye, Melanie; Eppinger, Steven

Link to article, DOI:10.11581/dtu:00000069

Publication date:2019

Document VersionPublisher's PDF, also known as Version of record

Link back to DTU Orbit

Citation (APA):Ramirez Hernandez, T., Kreye, M., & Eppinger, S. (2019). Application of Agile in Product-Service SystemDevelopment. https://doi.org/10.11581/dtu:00000069

https://doi.org/10.11581/dtu:00000069

https://orbit.dtu.dk/en/publications/f5970ca0-4928-474e-b25d-6aae0bc7cef4

https://doi.org/10.11581/dtu:00000069

Application of Agile in Product-ServiceSystem Development

December 19th 2019DOI: https://doi.org/10.11581/dtu:00000069ISBN nr.: 978-87-93458-76-5

- Steve Jobs

a leader and a follower.Innovation distinguishes between

Note of ThanksWe would like to thank the case company for the possibility to conduct this research on one of thecurrent development cases. In particular we are thankful for the openness and curiosity brought forwardby the company for the research topic of agile in the development of Product-Service Systems. Thiswas strongly reflected in the extend of access to interviewees and data, as well as openness to respondto subsequent inquiries.

We hope that the case company finds the findings and carefully tailored recommendations inspiringand helpful. Feedback and interest in further research activities are very welcome. We wish all thebest for the continuing development.

Executive SummaryThe aim of this report is to provide insights into the uncertainty faced by manufacturers when developingProduct-Service Systems (PSS), and how to navigate this uncertainty better through agile managementpractices. PSS are compound offerings comprising of an artefact (the tangible or intangible product),and supporting engineering services. To provide these insights, this report describes the results ofa study undertaken in the American aerospace and defence industry. An in-depth case study ofa large-scale PSS development program, provides insights about the emergence of five uncertaintytypes: technical, environmental, resource, relational and organizational uncertainty. Moreover, theapplication of the agile method SAFe during the development provides insight about the changedability of uncertainty management.

The deductive analysis of the case study has confirmed the presence of all five uncertainty types. Inparticular, the organizational uncertainty was perceived as most challenging, and formed the root-causefor many other uncertainty types. All case results were compared with the findings of a benchmarkstudy undertaken in the Nordic manufacturing industry about PSS development and found to becoherent. This points strongly towards the general relevance of the five uncertainty types, particularlythe organizational uncertainty in PSS development. The application of agile management practices hasshown high success in the management of uncertainty. Specifically, agile provided the program withthe ability to quickly identify, communicate, and resolve uncertainty.

The inductive analysis has revealed the concepts of adoption and adaption of agile. The adoption ofagile gave rise to initial uncertainty through the challenges of learning the novel structures, processes,roles, and governance of agile in contrast to the traditional plan-based approach. This uncertaintydecreased over time as the learning curve increased. The adaption of agile gave rise to uncertaintythrough the need for modification of the agile method to the specific characteristics of the local casesetting. This uncertainty varied across the levels (or hierarchies) of the program, where the mostuncertainty was perceived in the levels most directly interfacing with the plan-based surroundingorganization.

The case company has successfully managed the adoption of agile and the navigation of the uncertainsetting trough the use of agile management practices. Potential for improvement is given in the adaptionof agile. The program would benefit among other from a clear Definition of Done, a continuous focuson agile training, the use of the architectural runway, structured stakeholder management, and a moredisciplined implementation of agile.

Concluding, the case study has shown that the development of PSS is non-trivial and gives rise to fiveuncertainty types. The most challenging uncertainty is represented by the organizational uncertaintytype. The use of agile management practices has shown strong success in the management of all fiveuncertainty types. Yet, while agile is able to reduce uncertainty, if the method is induced within aplan-based environment, the adoption and adaption of agile give rise to additional uncertainty.

6

List of Figures1 Categorization of Product-Service Systems adopted from Tukker (Tukker, 2004) 142 Uncertainty typology for the development of Product-Service Systems (Ramírez Hernández

et al., 2018) 153 The home-ground of agile and plan-based methods according to Boehm and Turner (2003) 204 Case selection in the study 225 Technical uncertainty in the case program 266 Environmental uncertainty in the case program 287 Resource uncertainty in the case program 308 Relational uncertainty in the case program 349 Organizational uncertainty in the case program 3510 Finding the balance of agile and plan-based for the specific case context 3811 Alignment of the two different work-rhythms 3912 Uncertainty and the degree of isolation 3913 Uncertainty development over time 4114 Root-cause Analysis 4315 Qualitative representation of uncertainty during PSS development 4516 Organizational uncertainty: adoption and adaption of agile 4617 Diffusion curve of Rogers (2010) 4718 Adoption of agile 4719 Adaption of agile 4820 Summary of the uncertainty types in the case program 49

8

List of Tables1 Summary of the interviewees, the supporting project management documentation, and the

observational data 252 Summary of the recommendations for the case program 50

9

Contents

Note of Thanks 4

Executive Summary 6

List of Figures 8

List of Tables 9

1 Introduction 12

2 Theoretical Grounding 132.1 Product-Service Systems and their Categorization . . . . . . . . . . . . . . . . . . . . . . 132.2 The Concept of Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Five Uncertainty Types in the Development of Product-Service Systems . . . . . . . . . 15

2.3.1 Technical Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Environmental Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.3 Resource Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.4 Relational Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.5 Organizational Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Agile and Uncertainty Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Method 213.1 The Research Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 The Case Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 The Case Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 The Detailed Case Description: A Radical Offering and Process Innovation . . . . . . . 233.5 The Case Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6 Data Collection and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Findings 264.1 Deductive Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.1 Technical Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.1.2 Environmental Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.3 Resource Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1.4 Relational Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.1.5 Organizational Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Root-Cause Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4 Inductive Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4.1 Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4.2 Adaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

10

5 Recommendations and Conclusion 505.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1.1 Technical Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.1.2 Environmental Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.3 Resource Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.1.4 Relational Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1.5 Organizational Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

References 60

Appendix 64

I Questionnaire 65

Contact Details 67

11

1 IntroductionThe quest of differentiation and competitiveness leads to the new era of engineering services. Increasingly,customers prefer more added services providing the pure functionality over the artefact alone (Vasanthaet al., 2012). The transition of manufacturers towards generating revenue from services is known as"servitization" (Baines and Lightfoot, 2013). The resulting offerings developed from the manufacturersare compound solutions comprising of the physical artefact (the product) and supporting services(Mont, 2002). Following the trend of digitalization, these Product-Service Systems are now gettingincreasingly digitized and become digital PSS (Lerch and Gotsch, 2015). Potential benefits of PSS ingeneral include differentiation, risk reduction through stable revenue streams, novel revenue streams orimproved quality of customer relationship (Raddats et al., 2016).

However, transforming an organization from manufacturing and selling products to providing Product-Service Systems creates various challenges for their internal processes but also their immediate networkof suppliers, partners, and customers (Wolfenstetter et al., 2015). Resulting challenges are i.a. theadaptation of existing processes, shift in culture, fit with the core competences and lacking capabilitiesfor the multidisciplinary development (Wolfenstetter et al., 2015). This has led to organizations notachieving all of the potential performance benefits of these new business models (Kindström andKowalkowski, 2014).

Specifically the development of Product-Service Systems remains a core challenge. The novelty of theProduct-Service Systems for many manufacturing companies means, that they lack an understandingand the relevant experience in developing these offerings. In academic terms, they face high levels ofuncertainty when developing these Product-Service Systems.

Taking inspiration form an adjacent field, agile development methodologies have shown high success inmanaging uncertain settings during software development (Martin, 2002; Dingsøyr et al., 2012). Whilethe concept of agile is maturing within that field, little is still known about its application in otherareas (Conforto et al., 2014).

Purpose

The aim of this report is to provide insights into the application of agile management practiceson uncertainty during the development of digital Product-Service Systems. To provide theseinsights, this report describes the results of a case study undertaken in the American aerospaceand defence industry. Combining a deductive and inductive research approach, the case isanalyzed regarding the uncertainty faced, and its management through agile practices.

The report is structured into five chapters. Chapter one introduces the report and its purpose. Chaptertwo gives a general overview of the theoretical background of the study. Chapter three describes themethodology applied in this study. Chapter four describes the findings of the case company. Chapterfive completes the report with suggestions and recommendations for the case findings based on mergingempirical insights from a previous benchmark study with theoretical insights described in literature.

12

2 Theoretical GroundingThis chapter offers a brief overview of the theoretical setting of Product-Service Systems and uncertaintymanagement through agile in their development. It initiates with the definition of uncertainty and itsrelevance in Product-Service System development. Subsequently the chapter elaborates five relevantuncertainty types. The chapter concludes with a brief introduction of the agile concept.

2.1 Product-Service Systems and their Categorization

Product-Service Systems are compound offerings comprising of the physical artefact (the product)and supporting services (Mont, 2002). In recent research, the definition of the product-part of a PSShas been weakened to also include digital offerings (e.g. digital PSS), where the product element isintangible (Lerch and Gotsch, 2015).

On the axis of transitioning towards servitization, different categorizations of these PSS can bedistinguished. These describe the path from still very product-related services, generating value mostlyfrom the product content, towards highly service-oriented offerings, generating value mostly from theservice content. One of the most commonly known categorizations in literature has been defined byTukker (2004) and is adopted in this context. It distinguishes product-, use- and result-oriented PSSand gradually describes an organizational transition towards service provision.

Definition

Product-Service Systems are compound offerings comprising of the tangible or intangible artefact(the product) and supporting services. They may be distinguished into product-oriented,use-oriented and result-oriented Product-Service Systems.

In product-oriented Product-Service Systems the business model is still mainly centered around thesales of the product with some extra services added. These could be product related services such asmaintenance or supply of consumables as well as consultancy services around the product.

In use-oriented Product-Service Systems the traditional product still plays a role, yet the service isnot geared towards exclusively selling the product. The product may even stay in the ownership ofthe provider and made available in a different form. These service may comprise of product leasing,renting or sharing where the user pays for the use of the product.

Finally, result-oriented Product-Service Systems describe concepts where the client and the provideragree on the result or outcome. In principle there is no pre-determined product involved (in practice ityet often bases on the core products of the companies). These concepts describe activity management,pay per service unit or agreements on functional results. A summary of the three concepts of Product-Service Systems can be seen in Figure 1.

13

Figure 1: Categorization of Product-Service Systems adopted from Tukker (Tukker, 2004)

2.2 The Concept of Uncertainty

For the present research uncertainty is defined as lack of knowledge. This may arise from not known, notdefinite or not reliable information (Kreye, 2017a). This lack of knowledge leads to an unpredictabilityof a core characteristic and thus the outcome is simply not known (Knight, 1921). The definitionimplies a dual nature of uncertainty. As such uncertainty can have both a negative or a positiveimpact on the project outcome (Perminova et al., 2008). It may threaten the outcome of the projector enhance it through e.g. increased/decreased costs, longer/shorter lead time, lower/higher quality,higher/lower risk profile or less/more resources.

Definition

Uncertainty is defined as lack of knowledge which may arise from not known, not definite or notreliable information.

In the context of Product-Service System development the concept of uncertainty requires specialattention. The development of Product-Service Systems differs strongly from traditional productdevelopment because it introduces new "soft" variables through the service component (Crawfordand Pollack, 2004). These new variables redefine the existing uncertainties for traditional productdevelopment like technical uncertainty, environmental uncertainty, organizational uncertainty andresource uncertainty (O’Connor and Rice, 2013).

One example is the redefinition of the pricing scheme. Traditionally in product development a cost-plusapproach, summing up the component costs and adding a margin, was dominant in the manufacturingindustry. This approach calls for a complete redefinition once the service aspect is taken into account.Uncertainty of forecasting the amount of maintenance and ad hoc failure challenges the industry.Moreover the value based pricing, defining the price according to the value for the customer, impliesuncertainty about value estimation.

In general the Product-Service System development process is characterized through high operationalcomplexity of developing products and services in parallel (Zhang and Banerji, 2017), the high degreeof stakeholder involvement (Martinez et al., 2010) and distinct requirements through the long life cyclesof Product-Service Systems (Zhang and Banerji, 2017). Because of these varied sources of uncertaintythe uncertainty types existing for product development need to be differentiated for the context ofProduct-Service System development.

14

2.3 Five Uncertainty Types in the Development of Product-Service Systems

Based on an exploratory literature analysis a conceptual framework of five uncertainty types occurringin Product-Service System development was developed. The literature analyzed comprised the literaturestreams of servitization, project management and (radical) innovation management. The analysiscentered around identifying relevant uncertainties occurring in Product-Service System developmentand grouping them into major uncertainty types. Moreover, suitable uncertainty management practiceswere identified from the literature analysis.

The five uncertainty types are distinguished as organizational, relational, resource, environmental andtechnical uncertainties. The framework is the basis for the benchmark of uncertainty management. Allparticipating companies will be compared and contrasted with each other based on these five categories.Moreover the companies will be compared to the uncertainties identified in the literature analysis.Figure 2 shows a general overview of the categories. A detailed description will follow in the nextchapter.

Figure 2: Uncertainty typology for the development of Product-Service Systems (Ramírez Hernándezet al., 2018)

2.3.1 Technical Uncertainty

Technical uncertainty describes the degree to which the engineering knowledge of the developed offeringis well understood (O’Connor and Rice, 2013) as well as technological challenges caused by the longlife cycle orientation of the Product-Service Systems (Isaksson et al., 2009). It mainly revolves aroundtechno-paradigmatic and complexity-related problems, in which high complexity and continued changecall for high flexibility (Melander and Tell, 2014).

In Product-Service System development, technical uncertainty may relate to three aspects: the product,the service and their systemic integration. First, technical uncertainty regarding the product component

15

is related to the degree to which the foundational scientific knowledge is well understood and appliedin form of a cost-efficient and manufacturable product (O’Connor and Rice, 2013). Moreover, itdescribes the challenge of integrating several components from multiple engineering disciplines e.g.IT, electrical engineering, mechanical engineering, mechatronic engineering, chemical engineering,metallurgical engineering (Wolfenstetter et al., 2015). Second, technical uncertainty regarding theservice component can relate to high variability of the service definition due to its customization(Nordin et al., 2011) and the uncertainty in forecasting of timing and scale of the service over a long lifecycle span (Isaksson et al., 2009). Third, the technical uncertainty related to the systemic integrationbetween product and service may be particularly challenging. On the one hand, managing all interfacesof the Product-Service System design in the context of their integration can create high complexitydue to high complicatedness (Benedettini and Neely, 2012). Technical uncertainty here arises throughthe task of complexity management. Specifically, it arises in foreseeing all possible combinations ofproduct and service modules, keeping the mutual influences between them in mind, and the subsequentchallenge to design all interfaces to be operational for all combinations predicted beforehand (Isakssonet al., 2009).

Definition

The degree to which the engineering knowledge of the developed offering is well understood.

2.3.2 Environmental Uncertainty

Environmental uncertainty refers to lack of knowledge about the external environment (Milliken, 1987).It includes the market uncertainty described by O’Connor and Rice (2013) in the context of radicalinnovation. The market uncertainty refers to the degree to which customer’s needs are well understoodand converted into a market application, appropriate markets are defined and a suitable business modelchosen (O’Connor and Rice, 2013).

Predicting these external factors and their effect on the Product-Service Systems can pose a challengein Product-Service System development. The lack of understanding customer needs and the intendedmarket segment is one of the core challenges of Product-Service System development (Spath andDemuß, 2001). Once they are understood the subsequent challenge lies in defining this new type ofvalue proposition and the surrounding business model dues to e.g. lack of readiness from the customersfor this type of advanced offering (Lay, 2014). Furthermore, larger macro-economical developmentscan represent sources of environmental uncertainty. These developments may comprise of changesin legal requirements and regulations or changes in the financial market (Kreye, 2017a). Moreover,technological developments may represent a source of environmental uncertainty (Reim et al., 2016)threatening e.g. technological obsolescence (Wolfenstetter et al., 2015).

Definition

The degree to which customer’s needs are well understood and converted into a market application,appropriate markets are defined and a suitable business model chosen.

16

2.3.3 Resource Uncertainty

Resource uncertainty refers to challenges arising from attracting and retaining the required resources(O’Connor and Rice, 2013). Resources may be defined as both tangible and intangible entities (Kreyeet al., 2015). They may consist of competences, critical information, financial resources as well as otherresources required.

The high degree of complexity of Product-Service Systems (Zhang and Banerji, 2017) and tailoring tothe customer’s needs typically requires high amounts (Benedettini and Neely, 2012) or very specificresources (Kastalli and Van Looy, 2013). These specific resources may refer to technical engineering andmanagerial capabilities (Wolfenstetter et al., 2015) or a certain seniority required for a particular activity(Atkinson et al., 2006). Due to these demanding requirements companies experience uncertainty aboutthe internal or external existence or availability of these specific resources (Wolfenstetter et al., 2015).Moreover, Product-Service System development often implies co-creation, which involves the customeras a crucial operant resource. Here the customer represents a source of resource uncertainties as theproject depends to a high degree on his input (Benedettini and Neely, 2012). A last example of resourceuncertainty may originate from the major change in cash flow. The operation of Product-ServiceSystems often requires major initial investments and implies a delayed cash flow. Resource uncertaintyarises from the need to convince external financial partners of the concept of Product-Service Systemsto bridge the initial period (Barquet et al., 2013).

Definition

Attracting and retaining the required resources.

2.3.4 Relational Uncertainty

Relational uncertainty refers to the inability to predict the partner’s future behavior and level ofcooperation offered (Kreye, 2017b). In Product-Service System development the relational uncertaintyis central because of the high degree of stakeholder involvement in the development process as well asthe large size of the internal and external stakeholder network (Baines et al., 2007).

Relational uncertainty may arise in Product-Service System development if new business modelsare co-created with customer or supplier (Kreye et al., 2015). Because the process of co-creationin Product-Service System development requires more sophisticated relationships (Isaksson et al.,2009) than traditional product development, relational uncertainty is reflected in the willingness,availability and ability of the partners to collaborate (Atkinson et al., 2006). These more sophisticatedrelationships demand i.a. increased information exchange, joint realization of innovations and especially,fast addressment of occurring disagreements and problems. Accordingly, relational uncertainty mayoriginate from e.g. lack of trust, low commitment, deficient information sharing as well as a disjointapproach to problem solving (Kreye et al., 2015) resulting in a partner’s inability to perceive or deliverthe service (Kreye, 2017b), i.e. weak inter-personal or inter-organizational relationships (Kreye et al.,2015). Another example of relational uncertainty in the context of Product-Service System developmentare challenges in service contracting. Since Product-Service Systems build upon a long-term provider-customer relationship contracting capabilities of both parties are crucial (Kreye, 2017b). Especially the

17

definition of the split of i.a. costs, risk and intellectual property (Isaksson et al., 2009) between thecollaboration partners can create challenges.

Definition

The inability to predict the partner’s future behavior and level of cooperation offered.

2.3.5 Organizational Uncertainty

Organizational uncertainty is defined as organizational dynamism both within the project, as well asbetween the project and its various internal or external stakeholders (O’Connor and Rice, 2013). It isreflected in terms of the organization’s strategy, priorities and available resources (Kreye, 2016).

The challenges for Product-Service Systems here may be similar to product development projectswhere stakeholder interests can vary, project planning and execution can be challenging, or functionalinterfaces within the organization can change (O’Connor and Rice, 2013). Yet the stakeholder networkin Product-Service System development typically is larger and more divers for Product-Service Systemdevelopment (Martinez et al., 2010). An example of organizational uncertainty here is the goal definition.Potential hidden agendas as well as different stakeholder interpretation of qualitative and intangibleresults can inhibit the clear definition of the overall goal (Atkinson et al., 2006). Besides the challengeof stakeholder management additional organizational uncertainty may arise from the mix of cultureswithin an organization. Especially companies with a traditional product development mindset requirea cultural change towards service provision. This shift may be challenging, for where the traditionalfocus was laid on efficiency and economies of scale, it now moves towards customization and flexibilityin a service provision (Gebauer et al., 2005). In this setting, uncertainties arise because competenceprofiles, functions and processes need to be redefined and external partnerships reshaped accordingto the new requirements (Wolfenstetter et al., 2015). A last example for a cause of organizationaluncertainty is the pricing of the Product-Service Systems at the bidding stage (Kreye et al., 2014).Root causes for uncertainty of pricing are i.a. connected to vagueness in cost-estimations (Kreye et al.,2014) or estimating the value for the customer in the context of performance based pricing (Barquetet al., 2013).

Definition

Organizational dynamism both within the project, as well as between the project and its variousinternal or external stakeholders.

2.3.6 Summary

Uncertainty is defined as lack of knowledge in the context of the present research. This may arise fromnot known, not definite or not reliable information (Kreye, 2017a). As the Product-Service Systemdevelopment process shows distinct characteristics when comparing it e.g. to traditional productdevelopment, the relevant uncertainty types have to be redefined. In the course of the research projectfive major uncertainty types have been identified.

18

2.4 Agile and Uncertainty Management

The concept of agile came into prominence in the late 1990’s. It was the attempt of frustratedsoftware engineers to resolve perceived difficulties with the traditional rigid, plan-based developmentmethodologies. These plan-based development methodologies showed serious shortcomings in thecontext of emerging technology and increasing volatile environments causing substantial projectuncertainty (Moran, 2016).

The concept of agile acknowledges this project uncertainty and aims to balance the process of plan-ning and control, with execution and feedback. Open communication, openness, learning, andself-organization (i.e. de-centralized decision making) stand at the core of agile. These features arereflected in the notions of iterative and incremental development activities (Moran, 2016). The conceptwas first captured in the The Agile Manifesto. It describes four core values and 12 agile principleswhich provide concrete guidance on the implementation of the four core values (The Agile Manifesto,2001).

The four core values of agile

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Theory has advanced in understanding the concept of agile and has defined the home-grounds of agile.These home-grounds represent the conditions of application, under which agile unfolds its full potential.Boehm and Turner (2003) have distinguished the home-grounds of agile, from the home-grounds ofplan-based methods. Their crucial point of distinction between agile and plan-based is based on theconcept of risk (or its underlying uncertainty). In essence, the more risk (or uncertainty) is perceived,the more agile a project should become.

Agile operates best under turbulent, uncertain conditions where the need to respond to change iscrucial. It requires a soft management style focused on tacit, interpersonal knowledge and qualitativecontrol mechanisms, and values frequent customer engagement. Under ideal conditions the offeringunder development is easily (and cheaply) refactored and possesses a simple design. Optimal agileteams are small, and consist of co-located, empowered members, which are fully staffed on the project.Figure 3 shows the result of the analysis of Boehm and Turner (2003).

19

Figure 3: The home-ground of agile and plan-based methods according to Boehm and Turner (2003)

A large variety of methods arose from the concept of agile, all if them aiming to incorporate the valuesand principles of the Agile Manifesto. These methods include i.a. eXtreme programming (XP), scrum,lean software development, feature-driven development (FDD), and crystal methodologies (Dingsøyret al., 2012). Research and practice has also advanced regarding the investigation of the application ofagile to larger projects, i.e. agile at scale. Where small-scale agile can spin completely independent,agile at scale requires the alignment of several teams to assure that they spin all in the same direction.The most famous methods of scaled agile are Scrum-of-Scrum (Scrum Inc., 2017) and the Scaled AgileFramework (Scaled Agile Inc., 2018). In addition, some scholar even went as far as to merge the agilewith the plan-based approach. An example is the combination of the plan-based Stage-Gate methodwith the agile method of Scrum (Bianchi et al., 2018; Cooper, 2016) - yet with mixed results.

Nonetheless, the underlying functionality of agile seems clear: the higher the uncertainty, the moreapplicable is the concept of agile (Boehm and Turner, 2003; Cooper, 2016; Bianchi et al., 2018).While the concept of uncertainty is old (Knight, 1921), discussions about uncertainty managementhave continued and evolved throughout the decades. The emergence of the novel concept of agilere-shuffled this discussion. Yet, it remains to be tested in all sorts of development projects to revealthe applicability and potential of agile for uncertainty management.

Scholars have made initial contributions in the fields of agile software development (Martin, 2002;Cockburn, 2006), agile manufacturing (Yusuf et al., 1999; Gunasekaran and Yusuf, 2002), agileproject management (Schwaber, 2004; Highsmith, 2009). Yet, only an initial theoretical discussion(Ramírez Hernández et al., 2019) has advanced theory on uncertainty management in PSS developmentthrough agile; the empirical evidence remains to be collected. Building on the uncertainty perceivedduring the development of PSS, this study aims to investigate the applicability of agile at scale (SAFe)in the development of digital PSS.

20

3 MethodThis chapter describes the methodological approach of the study. It elaborates the selection of theresearch method and the case, the case description, as well as the collection and analysis of the data.

3.1 The Research Method

As a research method, the case study method was applied in the present study. Case studies are richdescriptions of a particular phenomenon in its original context. They may vary between qualitative,quantitative, or qualitative-quantitative approaches. While qualitative approaches are usually used fortheory building, quantitative approaches serve theory testing (Yin, 2011).

In the present case, the theory of the phenomenon under analysis is still in a nascent stage and thus,a qualitative approach to for theory-building was chosen. To avoid bias in case study research, theobtained data is typically triangulated between various data sources (Yin, 1994). In the present casestudy, triangulated sources of data comprised of semi-structured interviews with core members of thedevelopment program, supporting project documentation, and observational data from an on-site stay.The analysis of the data implied an iterative approach between an inductive, from the data emergent,and a deductive, from theory derived, approach. As such, the theoretical concepts derived from thedata are based on the initial contributions within the theoretical field, and modified or adjusted basedon the insights gained from the case (Eisenhardt, 1989).

3.2 The Case Selection

At the core of case study research stands the case selection. As the purpose of case study research istheory building, unusually relevant or extreme cases, which grant the opportunity to study a particularphenomenon in its original environment, are ideal (Eisenhardt and Graebner, 2007).

Case Selection Criteria

Overall, the purpose of the present study was to analyze the effect of agile management practices onuncertainty during the development of PSS. Based on this purpose the requirements for case selectionwere fourfold. First, the main requirement was the development of a PSS. Second, the underlyingmethodology of the PSS development was to be an agile methodology. Third, the case was to originatefrom the manufacturing industry, as the phenomenon of servitization (the transition from productsto service offerings) is particularly relevant within this very industry (Neely, 2008). Due to the highdiversity of sectors in the manufacturing industry, a particularly extreme case is to be favoured. Fourth,the requirement of uncertainty during the development was to be fulfilled (also favorably extreme).

Four Case Selection Criteria

• Development of a PSS

• Application of an agile methodology for the PSS development

• Case context in the manufacturing industry

• High degree of uncertainty

21

The Case

Following the four case selection criteria, a case within the aerospace and defence industry developinga digital PSS was identified. It satisfies all given requirements. First, the identified case targetedthe development of a PSS (in this case a digital PSS). As this particular digital PSS comprises of avariety of digital product-service offerings, it is characterized as a use-oriented PSS according Tukker’scategorization. Figure 4 visualizes the case selection along the Tukker PSS definition.

Figure 4: Case selection in the study

Second, the development of the digital PSS was executed using the agile methodology. Specifically, theagile methodology SAFe, Scaled Agile Framework (Scaled Agile Inc., 2018), was applied.

Third, the study of a case within the manufacturing industry sector of the aerospace and defenceindustry was found highly suitable, because it represents a very extreme case. This is mainly due to thelong history of plan-based development and potential testing-challenges due to the high-risk-high-impactsetting within the aerospace and defence industry. This forms a stark contrast to the agile practices,which base on fast iterative approaches.

Fourth, the case represent the development of a radical innovation, which implied high uncertainty, asthe degree of radicality of an innovation is directly linked to the degree of uncertainty perceived duringits development (O’Connor and Rice, 2013). In the present case, this implied a radical offering and aradical process innovation. Specifically, the radicality of the offering emerged due to the disruptivenessof moving from the non-digital into the digital market-space. The radicality of the process innovationemerged from the application of agile management methods embedded within a strong plan-basedlegacy organization.

22

3.3 The Case Context

The case company had headquarters in the United States of America and operated globally in theaerospace and defence industry. It was a large OEM in this industry with a long legacy history, andemployed more than 50.000 employees worldwide.

The industry sector had undergone major developments in the last years and challenged the players tofollow a strategy focused on innovation and digital transformation. While geopolitical tensions servedan increase in order-intake, global digital trends challenged the innovativeness of the players. Artificialintelligence, robotics and autonomous systems, additive manufacturing, and purely digital offeringscalled for adoption. Yet, the high-risk-high-impact environment of the industry demanded the focus onlow-risk innovation. In addition, the small customer base of the players created additional cautionamong the OEMs, as this implied a high cost of failure. Furthermore, these new digital technologiesdeveloped with high speed. This urged the players to become more agile and respond faster to novelmarket conditions.

Operating in this competitive environment the case company sought to differentiate itself through adigital transformation. Part of this digital transformation was a program within the global servicebusiness unit. The global service business unit was at the point of analysis roughly two years old andcomprised of several daughter-companies merged under the roof of the case company.

3.4 The Detailed Case Description: A Radical Offering and Process Innovation

The digital transformation implied the establishment of the necessary digital competence, which wasto be rolled out across the whole organization afterwards, as well as the ability to work and respond tochanges in a more agile way. As such, the company launched (among others) a program represented inthe present case, which included an offering and a process innovation in parallel: while developing adigital offering, it also innovated on the development process through the implementation of an agilemethod. The program comprised of nearly 400 employees and engaged with more than 1.000 membersfrom the surrounding organization(s) on a daily basis.

The radical offering innovation under analysis represented the development of a digital platformand additional digital services. This digital platform followed the customer journey through the threestages of browsing, buying, and using a product/service through the support of the platform. The aimwas to engage in a long-term, digital relationship with the customer.

The platform followed a “Freemium model” where basic digital services were provided free of charge,and additional services were provided for purchase. The free services consisted mainly of a bundledoverview of the products and services purchased, to increase the transparency and ease of the fleetmanagement. These initial free services supported the main products’s reliability were mostly alreadyincluded in the main purchase of the product.

Services for purchase included digital support during operation and maintenance of the main product.These maintenance and operations services for purchase covered three time horizons: the planninghorizon (e.g. planning for maintenance or flight operations), the execution horizon (e.g. during flightor maintenance), and the post-execution horizon (e.g. performance data analysis after flight andmaintenance).

23

The radical process innovation implied the implementation of the Scaled Agile Framework, SAFe 4.6(Scaled Agile Inc., 2018). This process innovation was implemented within a large, legacy organizationand formed a stark contrast to the traditional plan-based approach used up to that date. A the pointof analysis the program was running since roughly one and a half years.

All in all, the digital transformation program was a radical innovation for two reasons. First, thestep from the non-digital into the digital world represented a radical offering innovation. Second, thetransformation from plan-based to agile represented a radical process innovation.

3.5 The Case Data

To collect the data, 19 semi-structured interviews were conducted and data triangulated with supportingproject management documentation as well as observational field notes from several core meetings.Table 1 summarizes the collected data.

3.6 Data Collection and Analysis

The case study was based on qualitative data and analyzed one on-going, complex development projectof a Product-Service System within the case company. Overall, three types of data was analyzed:semi-structured interviews, supporting project documentation, and field notes based from observationsof the researcher attending central meetings in the course of two weeks.

For the interviews, multiple people involved in the development project were interviewed to obtaininsights into their experience and evaluation of the situation. These people were part of developmentteams and included i.a. the program leadership, developing engineers, scrum masters, solution/releasetrain engineers, and more. Overall 19 interviews were conducted and comprised of 1 hour each. Thequestionnaire of the semi-structured interviews can be seen in the Appendix I.

Furthermore, project documentation and other supportive material were analyzed to gain a completingoverview of the development of the Product-Service System. This supportive material comprised ofi.a. performance review presentations and an in-depth organizational chart. In total 12 supportingdocuments were analyzed.

Lastly, field notes based on observations were taken. Here the researcher was on site of the companyfor two weeks and attended in total eight central meetings of the development project. The field notesfocused mainly on the attendance and behaviour of the participants, content and timing of the meeting,as well as the investigation of the central theoretical concepts emerging or defined beforehand.

After the data collection, all the data was coded according to the theoretical framing presented inchapter two. This led to a detailed overview of uncertainty during the digital PSS development ofthe case company which is the basis for chapter four. Beyond the descriptive elaboration of thedeductive analysis, chapter four also includes a benchmark reflection about digital PSS developmentwhere the case is compared to previous studies about uncertainty in digital PSS development. Thechapter closed with an inductive analysis of emerging concepts from the case study. Finally, individualrecommendations based on the best practices are given in chapter five.

24

Interviewees(19)

Supporting Documentation(12)

Observational Data(8)

-Program Director-Leader of Finance-Leader of the Program Manage-ment Office-Leader for the Analytic-Leader of Digital Marketing-Leader of the Global Service E-Commerce-Leader for Global CX/UX + So-lution Manager-Leader for Applications andPortal-Leader for Common Architec-ture and the E-Commerce Mar-ketplace-Solution Train Engineer for Sev-eral Solutions-2 Scrum Masters-Vice President for CommercialServices Business Development-Lead UI Designer-Software Development Manager-2 Release Train Engineers-Product Owner-IT Business Partner

-11 Performance Review Presen-tations from July 2018 - March2019-Organizational Chart

Observational data was collectedover two weeks on site. Partic-ularly relevant is the data fromcentral meetings during that timelasting about 1hr each.

-Check-in Meeting 19.3.2019-Daily Stand-up Meeting + con-tinued conversation of a few par-ticipants afterwards 27.3.2019-SAM (Special Attention Meet-ing) Call 29.03.2019-Daily Stand-up Meeting01.04.2019-Daily Stand-up Meeting03.04.2019-Demo Day Meeting 03.04.2019-Execution Review 28.03.2019-Daily Stand-up Meeting29.03.2019

Table 1: Summary of the interviewees, the supporting project management documentation, and theobservational data

25

4 Findings

This section presents the findings of the case study. The data analysis combined a deductive andan inductive approach. Deductively, the data was analyzed regarding the five uncertainty types.Inductively, the researchers analyzed the data regarding emerging concepts from the data. This sectionwill first present a brief overview of the most relevant uncertainty within each of the five uncertaintytypes. Subsequently, a short root-cause analysis and a benchmark comparison with other cases of PSSdevelopment are presented. The chapter closes with elaborating the emerging, inductive concepts ofthe research and a short summary.

4.1 Deductive Analysis

In the deductive analysis core concepts emerged from literature investigated. In the present studythose core concepts are represented by the five uncertainty types which are described in the following.


The case program faced technical uncertainty in terms of (1) Definition of Done, and (2) technicalinterfaces. Figure 5 and the box below summarize the technical uncertainty of the case. The subsequentparagraphs describe the challenges in detail.

Figure 5: Technical uncertainty in the case program

26

Uncertainty and Uncertainty Management

(1) Definition of DoneUncertainty arose regarding the Definition of Done of the overall program and the offering underdevelopment. Being a core element of SAFe, the uncertainty management regarding the lack ofthe Definition of Done was problematic and rather self-initiated on the team level.

(2) Technical InterfacesThe technical alignment and integration of the various solutions of the program gave rise touncertainty about the number and type of technical interfaces to be defined. The application ofSAFe in the course of the development aided strongly in managing this uncertainty with regardsto the high frequency of ceremonies and the clearly defined communication lines. In addition,the program management paid special attention to the smart definition of agile release andsolution trains to reduce the interfaces.

(1) Definition of Done

One strong locus of uncertainty was the "Definition of Done". This targeted the Definition of Done ofthe individual offerings under development, as well as the Definition of Done of the overall program.This was highly critical as the Definition of Done represents one of the core elements of the SAFeframework. The lack of the Definition of Done implied uncertainty about the "what" and "how" of theofferings. Members of the program were unsure about the final scoping of the offering, i.e. what wasto be built, and when to stop? This was particularly challenging whenever the scope of the offeringwas adjusted. In addition, due to the lacking guidance of what the final offering should represent, theteams partially lacked the ability to prioritize the tasks to be performed clearly.

The same held true for the overall program. Here uncertainty arose about coordinating the individualdevelopments (trains and/or solutions), with specific attention regarding when to stop their developmentand reallocate the capacity to other tasks. Moreover, on a larger scale, uncertainty regarding theend-date of the program arose. Members were unclear whether the program was to continue for another1-2 years, or rather 3-5 years. This created critical discrepancies among the management styles: somemanagers were willing to accept inefficiencies, which would require resource investment to resolve andamortise over a longer period of time, while others aimed at resolving them (e.g. the implementationof a common agile-tool).

The lack of a clear and coherent Definition of Done implied also knock-on uncertainty. As an example,resource planning was hampered because the remaining workload and thus, the resources boundwithin that train or solution, were unclear. In practice, the teams found "work-arounds" to handle theuncertainty regarding the Definition of Done. As such, they improvised and defined the Definition ofDone for the offering under development themselves. This led however to infringements regarding theintegration of the offerings or the alignment with the higher management.

(2) Technical Interfaces

Uncertainty regarding technical interfaces targeted mostly the technical alignment and integration ofthe various solutions under development. Uncertainty arose in particular around the number and typeof interfaces which required alignment. As an example, this uncertainty arose regarding the creation

27

of the technical integration of the various solutions, in order to create a full customer experiencethroughout the browse, buy, and use phase. Rather than difficulty, it created high complicatednessthrough the presence of many interrelated agile release and/or solution trains.

The use of the SAFe framework aided the uncertainty management strongly regarding the uncertaintyabout the technical interfaces. Particularly relevant for managing the uncertainty in this context werethe frequent ceremonies and the clear communication lines. The high frequency of the ceremoniescreated a high information exchange. The clear communication lines led the teams communicate moreefficiently. As an example a developer could raise the issue to the assigned scrum master, who could thenin turn search for the responsible contact person within other teams through raising the issue withinthe scrum of scrum meeting. In the meantime the developers could continue their work. Additionallyto the highly frequent ceremonies and the clear communication lines, the program management paidclose attention to the definition of agile release trains (ATRs) and solution trains to keep the amount ofinter-dependencies as low as possible. In sum, while the technical interfaces among the various teamsgave rise to uncertainty, agile management practices aided the program strongly to manage it.


Environmental uncertainty in the case program was reflected in two main factors: (1) a corporatebudget re-prioritization due to legal changes, and (2) a region-specific legal setting (GDPR). Figure 6and the box below summarize the environmental uncertainty of the case. The subsequent paragraphsdescribe these challenges in further detail.

Figure 6: Environmental uncertainty in the case program

28


(1) Corporate Budget Re-Prioritization due to Legal ChangesThe corporate budget re-prioritization due to legal changes caused strong uncertainty in theprogram about the impact on the program continuity. The use of the SAFe framework hasshown excellent results in managing this uncertainty. It gave the program the ability to pivotand adapt fast to the new conditions.

(2) Region-Specific Legal Setting (GDPR)A new legislation in the European Union, the General Data Protection Regulation (GDPR),challenged the company as a whole and as such the program, to quickly adapt to the newrequirements. The SAFe framework aided the team in adapting to these new requirementsthrough liberation of staff and re-prioritization of the backlogs.

(1) Corporate Budget Re-Prioritization due to Legal Changes

One strongly disruptive factor of the program was the corporate budget re-prioritization due to legalchanges. This the whole company to focus on the resolution of this challenge. These broader companystruggles created uncertainty for the program regarding the consequences this radical change mighthave on the continuity of the development. The research permitted the analysis before and after theimpact of the corporate budget re-prioritization due to legal changes on the program. In essence, allnon-substantially necessary projects were stopped or cancelled throughout the whole organization. Thisincident shifted the focus of all employees on the well-being of the whole organization, and resulted ina stark decrease of budget and headcount for the program by about 50%.

The use of the SAFe framework has shown excellent results in managing this uncertainty. Giventhat agile management shows its forte under uncertain and volatile conditions, the ability to pivotquickly enabled the team to adjust fast to this cut-back and minimize the performance impact of thedevelopment activities. As an example, the the product managers and owners quickly re-prioritized thebacklog of the solution trains or the ARTs. In addition, the clear overview of the backlogs enabled theteams to quickly identify the value and workload of the items and order them accordingly; or as SAFecalls it, the "weighted shortest job first". This visibility enabled also a clear communication across allhierarchies of the program.

(2) Region-Specific Legal Setting (GDPR)

In the present case uncertainty about a region-specific legal setting arose around the new legislationof the General Data Protection Regulation (GDPR) in the European Union. As a global player theentire company was affected and was challenged to find a unified way to navigate this new legislation.This created uncertainty within the program regarding the precise impact of the new legislation on theprogression and restrictions of the ongoing development activities. It forced strong alignment of theprogram with the surrounding organization to create a unified response to the new legislation. Hereuncertainty was created through the coordination across various business units where most lackedknowledge about GDPR. It challenged the program to quickly build the compliance infrastructure,processes, as well as legal and technological abilities to respond to GDPR-related inquiries.

Also regarding this environmental uncertainty the SAFe framework provided the development team

29

with the necessary flexibility to adapt fast to the environmental circumstances. Fast liberation of staffand re-prioritization of the backlogs to include GDPR-related items enabled the program to embracethis additional challenge and manage the uncertainty caused.


In this specific case, resource uncertainty was reflected in the challenges of (1) attraction and retentionof expertise, (2) lack of key SAFe roles on the program layer, (3) data access across all BU (BusinessUnit) entities, (4) colors of money, and (5) lack of a common business intelligence tool. Figure 7 andthe box below summarize the resource uncertainty of the case program. The subsequent paragraphsdescribe the challenges in detail.

Figure 7: Resource uncertainty in the case program


(1) Attraction and Retention of ExpertiseUncertainty arose around the attraction and retention of functional e-commerce, and SAFeexpertise. It was mainly managed through the engagement of external staff, which brought therequired expertise into the program.

(2) Lack of Key SAFe roles on the Program LayerUncertainty was caused by the lack of roles on the program layer regarding the ability to operatewith the SAFe framework. This uncertainty was two-fold: lack of actual staff, and lack ofknowledge to fulfill the role. The program managed this uncertainty through the engagement ofexternal staff and peer-to-peer coaching about SAFe.

30


(3) Data Access Across all BU EntitiesLegacy infrastructure as well as existing legal agreements of data shielding and sharing gave riseto uncertainty about data sharing between the BU entities. This uncertainty was managedthrough human "work-arounds", as well as escalations through the aid of the pre-definedceremonies in the SAFe framework.

(4) Colors of MoneyThe complex funding structure inherited from the plan-based organization gave rise touncertainty in the program regarding its ability to pivot. Uncertainty management here focusedon limiting the changes made to the original scope and escalating the lengthy applications forchanges in the funding.

(5) Lack of a Common Business Intelligence ToolThe unification of previously ongoing development projects within the program as well as theoperation in different BU entities caused uncertainty about the performance management of theprogram. This arose due to the in-transparency through the in-comparability of a diverse set ofIT-tools. Uncertainty management here focused mainly on manual translation of the tool-resultsinto the overall performance metrics of the program. Knock-on effects of technical uncertaintystimulated the discussion of the overall need for a common tool considering the "Definition ofDone" of the overall program.

(1) Attraction and Retention of Expertise

The program represented in many aspects a radical change for the company. On one side, the programimplemented the digital transformation strategy and moved into the e-commerce realm. On the otherside, the program applied a new method to develop the offering: the SAFe framework. These twodimensions resulted in two types of new expertise needed for the development: e-commerce expertise,SAFe expertise. The program perceived strong uncertainty about the ability to attract and retainthese skills for the development. An underlying wave of fluctuation and only partial-staffing on theprogram aggravated the uncertainty around the attraction and retention for the project even more.

Specifically, the functional expertise including capabilities like digital marketing, adobe, and e-commercein general, gave rise to high uncertainty. The uncertainty was particularly caused by the overall scarcityof employees with these capabilities and experience with the aerospace- and defence industry.

The uncertainty around the SAFe expertise was associated with all internal and external stakeholders,as well as members of the program. In tendency, the expertise was higher on the team level becausethe software developers had been used to work in an agile way since many years already. While mostof the leaders on the portfolio level were SAFe-trained, other members from the portfolio and programlevel were self-trained. External stakeholders did not receive any SAFe training. This gave rise to highuncertainty across all layers of the program as well as it’s stakeholders about the understanding of theSAFe framework and its application.

31

In terms of uncertainty management the program sourced the skills first internally, and then alsoexternally. The company decided as a short- and medium-term solution to engage strongly withexternals to access the necessary skills. Specifically for the agile SAFe expertise, a few agile coacheswere hired on a short-term basis to spark some agile insights. Although a steep SAFe-learning curvewas observable within the program, the uncertainty about the SAFe framework and its applicationremained for many employees.

(2) Lack of Key SAFe Roles on the Program Layer

The implementation of the SAFe framework implied an organizational re-arrangement to fulfill theroles it prescribes. While on the team and portfolio level most of the roles were filled (or an equivalentfound), the program layer lacked staffing. This created uncertainty about the execution of the SAFeframework as the crucial layer, which coordinates between team and portfolio level, was mostly missing.Depending on which SAFe-configuration the program was aiming at (Portfolio SAFe or Full SAFe), thistargeted mostly critical roles like Release and/or Solution Train Engineers, System and/or SolutionArchitects, Product and/or Solution Management.

In combination about the uncertainty regarding the SAFe expertise, the uncertainty about the lack ofSAFe roles created serious challenges for the program. Not only were roles partially not filled, butsome employees who were staffed on certain roles perceived strong uncertainty about the specific tasksto fulfill their SAFe role.

The program managed this uncertainty through the engagement of external staff to fulfill the roles.While this act relieved the initial uncertainty caused by the lack of SAFe roles, not all roles were filled.Furthermore, the engagement of externals in these key positions caused uncertainty about knowledgedrain and the ability to create a lasting cultural change within the organization.

In addition, the program laid strong focus on coaching through the employees who possessed the SAFeknowledge. As an example, a scrum master on the team level would not only support his team withguidance about the SAFe framework, but generally all people he/she would have interaction with andwere uncertain about their role. This way, employees who were required to take on a SAFe role butlacked the necessary experience, were guided in fulfilling their role through their peers. However, thismechanism could only partially compensate for the lack of SAFe knowledge.

(3) Data Access Across all BU Entities

The business unit, in which the program was anchored, was barely two years old at the point of analysis.It consisted of a merger of several daughter-organizations, under the roof of one business unit withinthe parent company. This gave rise to uncertainty in the program regarding the ability to share dataacross the previously independent legacy IT-infrastructures. Straining this condition even more, legalconfidentiality agreements for shielding and sharing data across these entities had to be redefined. Theuncertainty about data access across all the entities of the business unit was particularly challenging forexternal staff because of the additional non-disclosure agreements they had with the parent company.

This uncertainty was managed through some human "work-arounds" of data sharing or escalation ofaround the long processes of re-defining the technical and legal interfaces. The application of the SAFeframework aided the program as it provided the opportunity to fastly identify, communicate, and reactto the many individual challenges connected to the data access across the business entities.

32

(4) Colors of Money

One major uncertainty the program was struggling with, was caused by its funding structure. Tran-sitioning towards an agile organization, the funding structure had not yet been revised. Where theSAFe framework suggests the use of value stream funding, the program still had to rely on traditional,plan-based funding mechanisms based on business case approval. Given the complex structure ofthe digital program, cutting across all functions and supporting functions of the entire company, theplan-based funding mechanism resulted in the need for approval and management of a large number ofbusiness cases to attract the necessary funding.

The main uncertainty arose however after the initial funding approval; enabled through the SAFeframework, the program was in theory able to pivot quickly to better target the customer needs. Yet,the funding (supported by the detailed business cases) was not able to pivot in the same way. All in all,the program was able to pivot a little within one funded "business case project", and never across the"business case projects". This gave strong rise to resource uncertainty within the program regardingits ability to adapt to customer needs, because the value created for the customer implied often thefunding of a variety of business cases. This resulted in the under-spending of some budgets, and thelack of funding for other areas of the program.

The management of this uncertainty was to constantly apply for, and manage, the change requestsneeded for the funding. In addition, the program constrained itself in its ability to pivot with the aimto stay mostly within the approved budgets. The use of the SAFe framework helped little as it was notapplied in the context of finance (i.e.lean budgets). It only provided the teams the frequent ceremoniesto identify, communicate, and aim to resolve the financial challenges.

(5) Lack of a Common Business Intelligence Tool

The last resource uncertainty arose around the underlying business intelligence used to navigate theagile development program. The program comprised of a variety of previously ongoing developmentactivities, which were gathered under one common theme. Further development activities and fundingfor these activities were launched once the program was fully established. Due to this partial greenand brownfield planning of the program, some teams had an already existing IT-infrastructure. Theresult was the use of a variety of business intelligence tools, which partially also had different versions.This caused uncertainty about the management of the many different teams, ARTs, and even solutiontrains because of the in-transparency and poor comparability of their performance.

Uncertainty management focused initially on applying for a common tool across all teams. Obstaclescaused by lengthy IT-security approval processes for tools and an underlying cloud system delayed thediscussion about the common tool by more than one year. In the meantime, "work-arounds" implyingmuch manual translation of performance measurements were used to manage the overall program.Technical uncertainty about the "Definition of Done" of the overall program fed into the discussionabout the need for the disruption of the development through the implementation of a common tool.

33


Relational uncertainty in this specific case was reflected in challenges of (1) varying experience withagile. Figure 8 and the box below summarize the relational uncertainty of the case program. Thefollowing paragraphs describe these challenges in detail.

Figure 8: Relational uncertainty in the case program


(1) Varying Experience with AgileUncertainty arose regarding the ability to collaborate with external partners using the SAFe-Framework because the collaboration partners possessed varying experience with agile, and alsowith diverse agile methods. In addition, the large share of externals engaged in the programgave rise to uncertainty regarding the knowledge drain and ability to create a lasting culturalchange within case company towards agile.After a learning period, the SAFe framework facilitated the collaboration with the diversepartners as it gave everyone a common language and work-mode. The uncertainty aboutknowledge drain and the ability to create a lasting cultural change was accepted facing thetrade-off of too little headcount.

(1) Varying Experience with Agile

External staff like e.g. consultants or contractors possessed varying expertise in using agile. While somehad worked with very advanced versions of agile, others came in first contact with the concept throughthe collaboration with the case program. In addition, those collaboration partners with experience inusing agile had a diverse background in the agile methods they used. Some had deep experience withScrum (and scaled Scrum), while others were familiar with SAFe. This resulted in uncertainty aboutthe ability to collaborate in an agile way using the SAFe-Framework.

This effect was further enhanced by the large share of diverse externals in the overall program - about50%. Here fluctuation of the externals caused additional uncertainty about the knowledge drain andthus, the collaboration under the SAFe framework. Moreover, while some externals held supportingfunctions, others were placed in key roles like e.g. Release Train Engineers or Product Owners. This

34

created uncertainty about a lasting cultural change towards agile through (1) the use of a large shareof externals, and (2) the externals holding key positions.

The use of the SAFe framework aided the uncertainty management partially. Although an initiallearning curve was required from the participants, it gave the program members a common language andwork-mode. This eased the collaboration across many internal functions, as well as the collaborationwith a high diversity of external partners. The uncertainty about the knowledge drain and the ability tocreate a lasting cultural change was however not addressed through SAFe because it does not accountfor a high fluctuation of its team members. Facing the trade-off between too little headcount, andpotential knowledge drain and lack of cultural change, the program management decided to accept theuncertainty of the latter.


In the present company organizational uncertainty occurred in nine different challenges in the followingareas: (1) legacy plan-based organization, (2) metrics, (3) large matrix organization, (4) interfaces withnon-agile functions, (5) diversity of the teams, (6) novelty of SAFe, (7) implementation of SAFe, (8)young BU, and (9) changing BU objectives. Figure 9 and the box below summarize the organizationaluncertainty of the case program. The subsequent paragraphs describe these challenges in detail.

Figure 9: Organizational uncertainty in the case program


(1) Legacy Plan-Based OrganizationThe strong plan-based legacy culture caused uncertainty about the program to be developed,as well as uncertainty regarding the ability of individual program members to adopt an agilemindset. This uncertainty was mostly managed through an initially strong focus on learningabout agile.

35


(2) MetricsStrong uncertainty arose about the performance tracking of the program. HeterogeneousIT-infrastructure, diverse stakeholder interests, and the aim to reach the benefits of agilecreated high uncertainty about the definition of KPIs. This uncertainty was managed throughexperimentation and creation of agile-plan-based hybrid KPIs.

(3) Large Matrix OrganizationThe large matrix organization implied high complexity for the program. The resulting largenetwork of critical stakeholders with their own P&L and other plan-based commitments causeduncertainty regarding the ability of alignment.

(4) Interfaces with Non-Agile FunctionsThe many interfaces of the program with non-agile functions created uncertainty about theability to execute the program in an agile mode and thus, realize the promised benefits of agile.This uncertainty was managed through minimizing the contact with non-agile functions, and ifinterfaces were necessary, defining them well.

(5) Diversity of the TeamsHigh diversity of the teams within the program (location, needs, agile experience, IT-infrastructure etc.) created uncertainty about suitable program governance. This uncertaintywas managed through implementing SAFe as best possible, and finely adjusting for specific needs.

(6) Novelty of SAFeInitial uncertainty arose regarding the novel characteristics of the agile work-mode which had tobe adopted. This uncertainty was managed through a strong focus on learning about agile andthe SAFe framework.

(7) Implementation of SAFeThe implementation of SAFe targeted the adaption of SAFe to the specific case context.Uncertainty management consisted mostly of an trial and error approach.

(8) Young BUThe relatively young business unit, in which the program was anchored caused uncertaintythrough the aftermath of the merger. SAFe aided the program to manage this uncertaintythrough quickly identifying and communicating uncertainty, and then reacting fast to resolve it.

(9) Changing BU ObjectivesChanging BU objectives created uncertainty in the program regarding its need to re-orient. HereSAFe showed excellent results through the eased ability to identify, communicate and adapt tothe new circumstances.

36

(1) Legacy Plan-Based Organization

In the course of the long legacy history, the case company has optimized itself towards a plan-basedculture. This culture was generally reflected in a very functionalized work-mode (silos) across thewhole company, a management culture of "command and control", and very linear processes. Whilethis work-mode certainly implies advantages under distinct conditions, it represents a stark contrast tothe culture of agile.

The core cultural struggle, both internal and external to the program, can be summarized throughthe acknowledgement of the uncertainty. Where traditional plan-based methods provide a false senseof assurance, agile acknowledges the existence of uncertainty arising in projects and prepares for aflexible response. The acceptance of this uncertainty lied at the core of the cultural struggles observedin the case, both internal and external to the program.

In the present case this contrast caused strong uncertainty about the overall ability of the program to bedeveloped. Relying heavily on the input from the surrounding organization and collaboration partners,and interacting with over 1.000 employees regularly, the cultural skepticism created uncertainty for theprogram regarding the critical support of these stakeholders. This cultural struggle arose due to alack of understanding of agile. None of the external stakeholders from the organization were trainedregarding agile or the SAFe framework. Thus, the differing language, reporting style, or work-mode ofagile, were not understood.

One prominent example of the cultural skepticism included the requirement from stakeholders for theprogram to determine the scope, the quality, and the time, when applying for funding and reportingthe progress. In contrast, the agile mentality acknowledges the degree of uncertainty of developmentprojects and typically leaves one of these three dimensions undefined. As another example, externalstakeholders saw the concept of pivoting towards the real customer needs as a failure in the planningprocess and as "shifting of the goalpost". These cultural differences created strong uncertainty withinthe program about the support of the external organisation regarding the program continuation.

In addition to the cultural skepticism of the surrounding organization, the program members alsoinherited the plan-based mentality. Even though most of the members were willing and able to embraceagile, the transition towards the new culture gave rise to some uncertainty. This uncertainty targetedthe individual employee and his/her ability to adapt the agile mindset. Some surfacing uncertaintyobserved included the struggle of some leaders to decentralize decision-making and focus on a high-levelmanagement only, i.e. trust the employee and not micro-manage.

This uncertainty around the cultural skepticism forced the program to continuously insert moreplan-based elements into the agile program. To form the bridge (or buffer) between the agile programand the plan-based environment, a project management office (PMO) was institutionalized on theportfolio level. Over time, the focus of the PMO shifted from catering the teams with what theyneed to perform, towards catering to the needs of the external plan-based environment. The tendencymoved towards running the agile and plan-based approach in parallel, and not as a substitute. Thisincreased the workload strongly for all members of the program and hampered the program itself tounfold the true agile potential. In the course of the strong corporate budget re-prioritization due tolegal changes, the PMO was dissolved as an institution with the aim to become more agile again -tending towards adapting the SAFe prescribed roles. Qualitatively, this observation can be associated

37

with a subdued harmonic oscillation, see Figure 10 - oscillating between agile and plan-based until theoptimum suitable for the specific case-context is found.

Figure 10: Finding the balance of agile and plan-based for the specific case context

(2) Metrics

Derived from the cultural challenged described beforehand, uncertainty about the metrics for per-formance tracking arose. Where the SAFe framework prescribes clear metrics to be applied, thebalance between the benefits of agile and the satisfaction of the plan-based environment forced theprogram to deviate from the purely agile metrics. In addition, the heterogeneous IT-infrastructureof the diverse teams challenged the program management to define metrics which could reflect theperformance of the agile teams, could be obtained from the diverse IT-infrastructures, and wouldsatisfy the external stakeholders. Following the lean mentality of the SAFe framework, it was moreovercentral to define key performance indicators, i.e. a few central ones, and not performance indicators tobe evaluated for administrative purposes. This gave rise to strong uncertainty among the membersof the program management regarding the definition of the metrics. This uncertainty was managedthrough experimentation with diverse metrics and the discussion of agile-plan-based hybrids like e.g.USD/story point.

(3) Large Matrix Organization

Due to digital nature of the program, it span diagonally across the large matrix of the parent company.Given the large size of the case company, this created high complexity and led to a high number ofcritical stakeholders from all "layers and spans" of the organization. This created uncertainty for theprogram regarding the management, and more importantly, the alignment of the stakeholders. Thiswas particularly critical because the stakeholders could not always liberate time to attend the centralSAFe ceremonies of the program. Here time-intensive follow-up meetings were required to reach aproxy-alignment until the next ceremony. As an additional hampering factor, many stakeholders hadtheir own P&L and were in parallel accountable for assigning financial or human resources to theprogram. With this in mind, the alignment of all the stakeholders created even more uncertainty forthe program.

The uncertainty was managed through an improvised approach. Trying to follow the ceremoniesprescribed by SAFe, the program management urged the critical stakeholders to attend these meetings.

38

If the critical stakeholders could not attend the ceremony, individual and time-consuming follow upmeetings were arranged to keep them engaged in the project. The large management task laid inaligning the two different work-rhythms of the fast spinning agile and the slower plan-based approach,as visualized in Figure 11.

Figure 11: Alignment of the two different work-rhythms

(4) Interfaces with Non-Agile Functions

The program was embedded within a heavily plan-based organization and collaborated with externalpartners of a varying plan-based/agile degree. This led the program to daily interface with non-agilefunctions. It could be clearly observed that the higher the degree of isolation from the plan-basedwas, the easier the teams could apply all elements of agile. On the contrary, the more intensely theemployees were engaged with the surrounding plan-based organization, the more challenging was itfor them to apply agile in a pure form. This gave rise to uncertainty about the ability to executethe program in an agile way and achieve the benefits of agile like e.g. speed to market. Figure 12summarizes this analysis.

Figure 12: Uncertaintyand the degree of isolation

Based on the SAFe framework, the degree of uncertainty caused by thecultural challenges in the program was lowest at the team level. Hereinteractions with the surrounding organization were mostly technical, e.g.alignment of IT-infrastructure. On the team level, the program level wasmoreover able to mostly shield the teams from any disturbing influencesand isolate them.

The level of uncertainty increased however on the program level. Herefrequent interaction with external plan-based processes, e.g. IT-securityapproval processes, resource approval processes, finance approval process,added to the existing challenges. As such, the uncertainty emerged fromtechnical and process interfaces.

Lastly, the portfolio level had to fully face the external organization. Thisincluded the management of technical interfaces, process interfaces, andlastly also the human interfaces in form of influential stakeholders. Thestrong external stakeholders forced the portfolio level to form the bridgebetween the agile project and the plan-based surrounding organization.

39

This pulled the portfolio layer constantly back into the plan-based mindsetand caused struggles in keeping a firm agile management style.

The uncertainty profile of the different SAFe levels was managed differently. Within the program, eachlevel aimed to shield the lower levels from disturbing, plan-based influences. As such, the program levelaimed to shield the team level, and the portfolio level aimed to shield the program level as best as theycould. However, the portfolio level fully interfaced with the plan-based organization and had to createa bridge to the agile program. Much uncertainty remained un-resolved due to the challenging definitionof these interfaces. As a result, conflicts around accountability for delays in the program arose.

(5) Diversity of the Teams

The program was characterized through high team diversity. This diversity showed itself through theinternationality of the teams (e.g. several locations in the USA, Canada, Poland, India, Netherlandsetc.), varying agile experience (e.g. no or little experience with agile vs. some or intense experiencewith Scrum or SAFe), use of different tools (e.g. Jira, Trello, Excel), different work cadences (e.g. somefinish a sprint on a Friday, others on a Tuesday), distinct needs for agile (e.g. Marketing for a slimmerversion of SAFe, e-commerce for a more structured SAFe), and unequal allocation of teams to theleaders (e.g. one leader with one team, another leader with six teams). This high diversity amongthe teams created uncertainty for the program management regarding the governance of these highlyheterogeneous teams.

The uncertainty arising due to the high team diversity was managed through implementing SAFe"as best as possible" among the teams. SAFe gave all teams a common language and aimed to alignthem. Even though, a common cadence and co-location of all teams was never reached, the programmanagement aimed to reach the best performance possible with the operational clearance available fortheir decision-making.

(6) Novelty of SAFe

The process innovation of SAFe induced in the program gave rise to uncertainty through its novelty.The adoption of the SAFe framework caused uncertainty among the program members through itscomplexity. Specific challenges arose e.g. regarding the individual roles and responsibilities of theprogram members, or the purpose and correct execution of the ceremonies. In particular the roles andresponsibilities were challenging, because initially many program level roles remained unmanned andtheir tasks had to be spread out among the other program members. Regarding the ceremonies, theirfrequency, content, and disciplined execution demanded a learning curve as well. Here the programmanagement perceived uncertainty about the definition of these aspects of the ceremonies. Specificallytempting were the known plan-based habits of side-work and side-conversations during the ceremonies.While these habits solved other side-issues, they came at the costs of the ceremony efficiency.

The uncertainty about the adoption of the SAFe framework initially increased the overall projectuncertainty as the new work-mode had to be learned. Once the agile work-mode was adopted and mostuncertainty resolved (e.g. ceremonies and roles clearly defined), agile could start to deliver the promisedbenefits of better uncertainty management. A qualitative representation of the initial detonation ofuncertainty around the work-mode is represented in Figure 13.

40

Figure 13: Uncertainty development over time

The management of the uncertainty around the novelty of the SAFe framework targeted a focus onlearning about agile and the framework. Agile coaches were engaged initially to help guide the programin designing the new work-mode. In addition, the program leaders and other members of the programunderwent agile training. However, the focus on learning decreased after the initial set-up.

(7) Implementation of SAFe

The implementation of SAFe gave rise to uncertainty about the adaptation to the local context inorder to enable daily operation. After understanding the SAFe framework as a whole, as discussedunder Novelty of SAFe, the implementation targeted the navigation of SAFe within the specific casecontext. Initial questions arose around the suitable SAFe configuration (e.g. Portfolio or Full SAFeconfiguration?). Other questions were directed towards the strategy of the program and how to manageits execution in order to align all levels of the program with the external parent company strategy(e.g. how and which epics to define?, or if and how to create a portfolio backlog?). Deeper questionstargeted the definition of the interfaces with the overarching non-agile processes (e.g. finance, legal,resource-planning). In short, the theoretical model of SAFe was perceived as partially unsatisfactoryfor the specific case context and gave rise to uncertainty about how to adapt it.

Uncertainty management about the precise implementation, that is its adaptation, followed a trial anderror approach. Specific program circumstances due to the scale (ca. 400 employees in the program)and the complexity (cutting across all functions and support-functions of the entire parent company)led to an iterative approach between the SAFe theory and practical solution approaches.

(8) Young BU

As described in the case context, the business unit BU in which the program was anchored, was abouttwo years old at the point of analysis. It represented a merger under the roof of the parent companyof several previously independent entities. The aftermath of the merger was still felt in the programand created additional, underlying uncertainty. Functions, processes, communication lines, commoncross-entity standards, and technical interfaces were still in the process of getting clearly defined.Often long processes and on-boarding times, as well as lack of task-ownership were the consequence.This created uncertainty for the program regarding the speed of completion of program-externaltask-completion and transparency of task-tracking.

The SAFe framework aided the program in managing this uncertainty. Through the ability to quicklyidentify and communicate upcoming bottlenecks, the teams were able to fastly escalate and oftenreduce the long process time. In the meanwhile, the product-owners reorganized the team backlogs,and the teams could proceed with other tasks while waiting for the bottleneck to be resolved. All in all- the trains were moving on.

41

(9) Changing BU Objectives

Due to the young age of the BU business unit and the environmental uncertainty caused by thecorporate budget re-prioritization due to legal changes, the objectives for the program changed. Whileoriginally measured on top-line revenue, the new focus lied on the achieved margin and operationalperformance. This created uncertainty in the program regarding its need for reorientation.

The SAFe framework showed excellent results in the management of uncertainty arising through thechanging BU objectives. The ability to fastly identify, communicate, and pivot into the desired directionrepresents the forte of agile. The program was able to identify the most epics and features of mostvalue for this new orientation, and re-prioritize the team backlogs to start the work towards the newobjectives.

42

4.2 Root-Cause Analysis

Systems theory has identified, that elements within a system are typically interrelated and that hence,one part usually affects other parts. In systems thinking, this idea is transferred to the "Iceberg"-theory,where visible events usually indicate struggles with deeper lying patterns or structures (Meadows,2008).

Using this knowledge, the systems view (or systems thinking) can be applied to the present case toidentify the main loci of uncertainty through a root-cause analysis. Many of the instances of uncertaintyobserved in the case were interrelated, i.e. caused by another instance of uncertainty. Following thattrail, the real loci of uncertainty could be revealed. Figure 14 summarizes the results of this analysis.

Figure 14: Root-cause Analysis

To give an example of the root-cause analysis, some instances had one cause, while others could betraced to multiple causes. As such, the uncertainty about the different colours of money was directlyconnected to the many stakeholders and their own P&L in the large matrix organisation. Also theinterfaces with non-agile functions was caused by the large matrix organization as this increased thenumber and complexity of the interfaces. In addition, the plan-based nature of these interfaces wascaused by the legacy plan-based organization. As can be seen, all but one uncertainty instances areinterrelated and can be traced back to one of five root-causes.

Moreover it can be observed, that four of these root-causes are "home-made" in the sense that theywere of the organizational uncertainty type. Only one uncertainty instance, the corporate budgetre-prioritization due to legal changes, represented a root-cause which is not from the organizationaluncertainty type. It stands further out, that most of the instances were related to the process innovationof inducing the agile method within a plan-based context. Little additional uncertainty observed in theanalysis was related to the innovation of the digital PSS itself.

43

4.3 Benchmark

Besides the absolute assessment of the uncertainty occurring during the development, the relativecomparison with other cases provides insight into performance of uncertainty management. Basedon a previous larger benchmark study, which analyzes manufacturers who apply different uncertaintymanagement strategies during their digital PSS development (Ramírez Hernández et al., 2019), somemain conclusions emerge.

First, also in the benchmark all five uncertainty types were captured in all companies analyzed. Mostheavily, constant organizational change like e.g. company-wide or departmental re-organizations, andmergers challenged the companies. These organizational changes occurred either during or slightlybefore the execution of the PSS development projects and gave rise to uncertainty. Common otherchallenges included technical uncertainty of scoping the final offering, i.e. what was to be in- andexcluded from the development, environmental uncertainty of navigating volatile market conditions,relational uncertainty of unpredictable behavior of collaboration partners, and resource uncertaintyabout the attraction and retention of the necessary skill-set for the project. These capture only afew challenges of the broad spectrum, which the companies of the report experienced. For a detailedoverview please consult the full report of Ramírez Hernández et al. (2019).

Second, as indicated already from the previous study (Ramírez Hernández et al., 2019), agile man-agement practices strongly reduce the uncertainty. Although uncertainty cannot be prevented fromoccurring, theory and practice offer various modes of managing uncertainty in order to quickly resolveit. Also, in accordance with some pioneering scholars in uncertainty management of radical innovations(Rice et al., 2008), fast testing iterations serve the uncertainty reduction. While the present caseequally perceived all uncertainty types, it was able to manage them better than all previous companiesof the benchmark. Managing the development of PSS in a full-agile mode was beneficial due to threecharacteristics: uncertainty identification, uncertainty communication, and uncertainty resolution.

Identification

Compared to the peer companies in the benchmark the application of agile management practicesenabled the program members to identify uncertainty fast. While traditional plan-based approachestest or "stop to reflect" after long time intervals, agile aims to check and test a developed increment atthe earliest stage possible. Even though the selection of the test population (e.g. customers or internalstakeholders) demands some thought, the increased frequency of testing resulted in fast feedback-loopsand thus, early identification of uncertainty.

Communication

Agile does not only enable the applicants to identify uncertainty fast, but also to communicate it fast.Where classical plan-based approaches describe the application of lengthy meetings of low frequency,agile favors the use of short meetings of high frequency. It also focuses on less meetings and shiftingthe attention again towards executing and not administrating work. Moreover, through clear roledefinitions, agile also determines the communication paths to be followed. Thus, once an uncertaintyis discovered it can be communicated immediately and directly. The person responsible for resolvingthe uncertainty can be sure to receive attention immediately. This patters was also observed in thecase program. Short-termed meetings like the daily stand-up and the short communication lines aidedthe program to quickly connect help-seeker with help-provider in order to resolve the uncertainty.

44

Resolution

Once the uncertainty is identified and communicated, an immediate response can follow. The agilemethods assume that the environment will change over the course of the development and thus definesevolving requirements. As such, once the offering is finished, the requirements are fully defined. Thisunderlying assumption is, what enables the teams to pivot fastly, and respond (and adapt) to the newlydiscovered uncertainty. This was clearly observable in the present case study where the ability to e.g.re-prioritize the backlog gave the developing teams the ability to continue working on the offering, whileresolving the uncertainty. Contrasted with the other companies of the benchmark (Ramírez Hernándezet al., 2019), the plan-based approach did not enable this fast adaptation and those teams lost time inre-arranging for the new circumstances or failed to develop the PSS completely. In short, agile enabledthe program to fast identify, communicate and react to uncertainty.

Third, and looping back to the main insights from the benchmark, not only radical offering innovationgives rise to additional uncertainty, but also radical process innovation. In this case, the applicationof agile within a plan-based organization created a high degree of novel uncertainty for the program.This additional uncertainty was exclusively located within the organizational uncertainty type. It ischaracterized through uncertainty of learning the new method, and operating/interfacing it with adissimilar environment. Thus, while basic organizational uncertainty (as also perceived by the othercompanies of the benchmark) could be reduced through agile, the process innovation created highadditional uncertainty. Figure 15 visualizes the overall uncertainty observed.

Figure 15: Qualitative representation of uncertainty during PSS development

45

4.4 Inductive Analysis

Based on the deductive analysis of the uncertainty types, core concepts were derived inductively.Through iterations, themes of the rich data set were clustered into increasingly larger concepts. Figure16 summarizes the derived concepts and the following paragraphs will elaborate them in further detail.

Figure 16: Organizational uncertainty: adoption and adaption of agile

The case of the PSS development project was embedded within the larger organizational context of thecase company. Through the engagement of external contractors and consultants it also reached out tothe environmental context of the company. This is visualised through the three larger squares in thecenter and setts the stage for two central inductively derived concepts: adoption and adaption of theagile method.

4.4.1 Adoption

Building on the insights from the deductively analyzed uncertainty types, the "agile journey" of acompany initiates with the adoption of the agile method. The concept of adoption in the presentcase, refers to the injection of the agile method in the program. This implies the education of theprogram members about the methodology, e.g. the roles and responsibilities, the work processes, thecommunication paths and frequencies, the events, the governance structure, and more. In the presentcase the organizational uncertainty clearly reflected many challenges around the adoption of the agilemethod as was elaborated in the previous sections.

Within the academic realm this adoption process is clearly related to the theory of diffusion of aninnovation (Rogers, 2010). This innovation may be of various types, e.g. product, process etc., yet, theunderlying mechanism remains and follows a bell-curve shape. Starting with pioneering innovators,over time most of the program members became educated about the agile method. Rogers’ diffusionmodel is shown in Figure 17.

With regards to the development of uncertainty a qualitative representation of the uncertainty overtime could be mapped based on the deductively derived information of the case. In essence, at thebeginning of the program, i.e. when agile was newly introduced, the uncertainty increased strongly.The work-mode was changed and the employees who were not yet familiar with the new way ofworking, had to bridge the short period of letting go of the well-known method while not yet being fully

46

Figure 17: Diffusion curve of Rogers (2010)

knowledgeable about agile. As knowledge of agile increased and experience was gained, the uncertaintyabout the work-mode decreased. In addition, through the application of agile the program memberswere able to navigate the uncertainty even better (as previously described). As such, the curve ofuncertainty falls below the baseline uncertainty of the plan-based approach. Figure 18 visualizes thisconcept.

Figure 18: Adoption of agile

4.4.2 Adaption

Once the program members were familiar with the agile method, they began however to struggle withcore elements of adapting the method to the individual characteristics of the program. To name afew, these struggles arose e.g. through the interfaces with the surrounding, non-agile organization,as well as with partially non-agile external collaborators. Additional uncertainty arose through acultural resistance of the interfacing organization, or through strong stakeholder interests focusingon plan-based work-modes. These stakeholder interests targeted partially the metrics of the programgovernance, which created stark contrast to the agile metrics.

47

A finer view on the adaption challenges revealed moreover, that the degree of distance of the interfacedecreased the uncertainty perceived. As such, on the team level of the SAFe model, the employeeswere almost completely isolated and had mostly technical interfaces with non-agile organizations. Onthe program level, the technical interfaces remained and in addition, the employees were facing directlynon-agile processes. Lastly on the portfolio level, the employees were directly interfacing with technicalnon-agile systems, non-agile processes, and strong non-agile stakeholders. With each higher level in theSAFe framework the uncertainty perceived increased, or other, with increasing isolation from non-agileorganizations the uncertainty perceived decreased. Figure 19 summarizes this concept.

Figure 19: Adaption of agile

4.5 Summary

The development of digital PSS is non-trivial and gives rise to high uncertainty. Previous theoreticalcontributions have defined the typology of this uncertainty namely technical, environmental, resource,relational, and organizational uncertainty. While uncertainty cannot be prevented from arising,literature provides various suggestions on how to precisely to manage the uncertainty, but has not yetreached a final conclusion. Taking inspiration from adjacent domains, the use of agile developmentmethodologies has shown strong results in uncertainty management. This study thus pioneers in theinvestigation of the application of an agile development methodology to the development of PSS.

The findings of the deductive analysis of the study confirm the presence of all five uncertainty types.However, these uncertainty types did not impact the case equally. Where relational uncertainty couldbe navigated seemingly easy, the stark increase in organizational uncertainty posed strong challenges tothe program. Here, additional uncertainty arose through the application of the SAFe framework, whichcaused strong infringements with the surrounding non-agile organization. Uncovering inefficiencies ofthe surrounding non-agile organization, the program was constantly hampered by its slow responseand cultural skepticism. A summary of the main uncertainty encountered throughout the digital PSSdevelopment process may be found in Figure 20.

Furthermore this study has found a strong increase in the ability to manage the uncertainty throughagile. Three core reasons lay at the bottom of this finding. First, agile management practices enableteams to surface or identify uncertainty fast. Through e.g. close customer and stakeholder engagementduring the process, or a high frequency of testing, uncertainty is identified fast. Second, the identified

48

uncertainty is communicated fast to the corresponding team, which can provide aid to resolve theuncertainty. Examples of increased communication speed are the highly frequent ceremonies like e.g.daily stand-ups, and the short communication lines. Third, the agile methodology allows the teamsubsequently to fast adapt to the uncertainty and pivot in a new, less uncertain direction. Here theconcept of "evolving requirements" through the re-prioritization of the backlog are key. Given thesecharacteristics, the agile methodology enabled strongly enhanced uncertainty management comparedto the traditional plan-based approach for PSS development.

Nonetheless, the introduction of agile within a legacy, plan-based organization and environment comesat the cost of increased organizational uncertainty. The organisational uncertainty forms also theroot-cause for many other uncertainty instances from several uncertainty types. This increase inorganizational uncertainty arises due to the adoption and the adaption of agile. The adoption describesthe short increase of uncertainty during the learning phase of the agile methodology. This uncertaintydecreases over time as the new roles, processes, communication lines, etc. are clearly defined. Moreover,the adaption describes the increase of organizational uncertainty due to the need to modify agile to thespecific context. Agile challenges the applicants to operate in an agile work-mode, while interfacingwith non-agile parts of the organization. When applicant and environment apply diverse work-modes,uncertainty arises at the interfaces of both and calls for an adaption on both sides of the work-mode.

Figure 20: Summary of the uncertainty types in the case program

49

5 Recommendations and ConclusionThis section gives suggestions for the case program according to the insights gained from literature andbest practices. The recommendations will specifically focus on the application of agile managementpractices and their improvement to resolve the case program’s uncertainty. The section ends with aconclusion about the overall challenges of Product-Service System development in the study.

5.1 Recommendations

The following sub-sections gives specific recommendations for the case program and the uncertaintiesit encountered in the Product-Service System development. The recommendations base on empiricalinsights gained from best practices in a larger benchmark study as well as insights gained from academicliterature. Each recommendation is elaborated in detail. In the beginning of the sub-section of eachuncertainty type the recommendations are briefly summarized in a visualization. A summary of therecommendations given can be seen in table 2 below.

Uncertainty Type Recommendation

Technical Uncertainty - Definition of Done

Environmental Uncertainty

Resource Uncertainty - Focus on agile training- Use architectural runway

Relational Uncertainty - Apply AMO-framework

Organizational Uncertainty - Structured stakeholder management- Disciplined agile implementation- Apply agile metrics- Learn continuously - the I&P iteration- Agile as a change project

Table 2: Summary of the recommendations for the case program


Recommendations

Definition of DoneDefining the Definition of Done for the program (and its various elements) will enable betterplanning and structure.

Definition of Done

The Definition of Done is one of the crucial characteristics for the overall SAFe implementation. It helpsunderstanding when the delivered solution(s) need no further development, i.e. when an implementation

50

is correct and delivers the business benefits, and comprises of a set of acceptance criteria. Having aDefinition of Done for the individual stories, features, epics, and also for the overall program is thuscentral to understand when these elements are completed.

While the research has not revealed particular challenges on the story-level, uncertainty emerged aroundthe Definition of Done determining the completion of features, epics, and the overall program. A clearDefinition of Done of these additional program elements is crucial for the planning and forecasting.Knowing how much work remains to be done and the speed of the individual teams, it would bepossible to roughly calculate the remaining time frame for the features, epics, and the overall program.This provides critical insights for resource planning, i.e. how many resources are still bound to onework-stream for how long, as well as for the implementation of strategically relevant themes, e.g. theimplementation of a team-wide tool like Jira/Jammer.

SAFe determines clearly the responsibility and timing of the Definition of Done. The Definition ofDone is part of the "Behaviour-Driven Development" and supports the Build-in-Quality core principleof SAFe. As an example, the Definition of Done of a Feature is defined by the Product Manager inclose collaboration with the corresponding stakeholders during the process of writing the feature. itis also the Product Manager’s task to accept (or reject) the delivered feature after the developmentiterations. It is likely that the initial Definition of Done is further refined during the process throughinput of the team, as further acceptance criteria are discovered during the development.

Additionally, the Definition of Done provides the program with the ability to provide plan-basedminded stakeholders with a rough orientation about the completion of the feature or solution of theirinterest. This would ease some of the tensions perceived by the program leadership with the stakeholdermanagement.


Due to the specific nature of environmental uncertainty, organizations can typically only react toit and not active influence it like e.g. the region-specific legal setting (GDPR). It is crucial in thiscontext to have a strong internal monitoring system which is able to detect these disruptive changesin the environment. Only then can an organization prepare through suitable strategies like hedging,stocking, contracting, relocating, etc. Agile enables this flexibility and can help organizations toidentify, communicate, and resolve the environmental uncertainty. Accordingly the recommendationsgiven in this report aim to better prepare the case company in its ability to react to environmentaluncertainty through increasing organizational agility.

51


Recommendations

Focus on agile trainingFocus on continuous agile training enables the employees to embrace not only the methodbut the mindset of agile. Once the mindset is understood, the innovating on the underlyingprinciples can occur and the process of adaptation of SAFe to the local needs of the case cantake place. Moreover, the use of an agile coach on the portfolio level can provide strong guidancein establishing an adapted SAFe governance.

Use architectural runwayMaking use of the architectural runway reduces disruptions during the development process anddecreased technical debt.

Focus on agile training

The first experience of agile within the case company has shown how deep the changes of agile reachwithin the organization. Agile as a concept requires a highly different mindset and thus culture of theorganization. As experienced, it is not sufficient to simply apply the method without the underlyingunderstanding of the mechanisms. The ability of the team, program, and portfolio employees tounderstand not only the "what", but the "why" of their work-mode, is crucial for the implementationof agile. It enables a mindset change within the employees, and provides them with the necessaryknowledge to explain, and potentially defend, their actions towards the strong push-back of theplan-based organization.

Here continuous education is critical to achieve the full potential of agile. Only when the methodand the mindset are fully understood, it will be able for the employees to innovate and potentiallyadapt elements of SAFe to the specific circumstances. Through this knowledge they will be able todistinguish the critical elements of SAFe from the non-critical ones with regards to achieving the overallbenefits agile promises. As an example, while it is highly critical for the agile success to have therole of a product owner or a scrum master, one product owner or scrum master can (if needed) alsosupport several teams. Yet, with lacking agile understanding critical elements are easily adjusted in anunfortunate way and then hamper the overall agility of the program. One example here is to leave outcentral roles foreseen by the SAFe framework entirely. This causes strong constraints for the remainingmembers of the project to counterbalance this loss of capacity and expertise. Often this is solved byredistributing the workload of the missing role to the remaining members, which strongly distractsthem from their actual work and thus constrains the overall performance.

Lastly, the continuous use of an agile coach at the portfolio level can be strongly suggested. Theinductive analysis has shown, that the most challenging uncertainty instances arise at the programlevel interfacing on a technical, process, and human level directly with the plan-based organization. Itis also here, where the program governance is determined and the adaption of critical (and non-critical)SAFe elements is decided. Strong guidance on this level, continuing education, and the participation inthe agile/SAFe community outside the organization to clarify inquiries, are particularly central here.An experienced SAFe coach is able to provide much of this guidance. He/she will be able to speed up

52

discussions about the adjustment of agile and intervene regarding critical elements if necessary.

Use architectural runway

The SAFe framework foresees elements which create the backbone of the development performance. Assuch, the architectural runway provides the necessary technical foundation for the features and epicsthrough the development of "enablers". In the present case these enablers of the architectural runwayshould focus on the technical infrastructure alignment within the BU (and between the BU and theremaining case company). Setting aside a certain capacity for this infrastructure alignment avoidsdisruptions along the development and thus avoids delays in the delivery. It provides the program withan increased planning capability.

In addition, the use of the architectural runway avoids improvised "work-arounds" through the correctionof the underlying problem. It decreases the technical debt of the program which otherwise wouldrequire major re-engineering and revising at the end. As elaborated beforehand, the remaining timeof the program may be estimated through the Definition of Done. If the program leadership thendecides to implement a common tool across all teams, the architectural runway provides the space forits implantation.


Recommendations

Applying AMO-FrameworkProviding collaborators with the ability, motivation, and opportunity for using their knowledge(especially regarding SAFe) creates high performing work-systems.

Apply AMO-Framework

Theory of high-performing work systems argues with the AMO-framework, that all employees per-formance is a function of (A) Ability, (M) Motivation, and (O) Opportunity (Blumberg and Pringle,1982). As such, to expand the high-performing work systems and include external partners into it, thesame accounts for theme as well. If they are lacking the agile ability, i.e. the knowledge about SAFe,education needs to take place through training on their part, as well as constant interaction within theproject to learn about the local project setting and its specific characteristics. Ideally, the selectionof collaboration partners should already entail the requirement of the necessary functional (e.g. IT)and methodological (e.g. SAFe) ability. Moreover, the motivation of the external partners is to bekept through constant engagement and explanation of the individual characteristics of the project. Assuch, some "text-book-agile" elements might not be implemented as originally described but call foradaption. Lastly, the partners demand the opportunity to apply their knowledge as their ability andmotivation depends on the work context, in which they have the opportunity to apply them.

53


Recommendations

Structured stakeholder managementThe challenging interfaces with the non-agile parts of the organization require strong, structuredstakeholder management of the portfolio level to create lasting operational excellence.

Disciplined agile implementationAfter managing the large-scale adoption of SAFe, the fine-tuning needs to take place. Decidingon the SAFe configuration, alignment of the program strategy, discipline in its detailed executionare the most important next steps. The stark program cut-back provides a great chance forthe program to align in a smaller scale, and then take up tasks again once the structures are clear.

Apply agile metricsThe counterproductiveness of plan-based KPIs in an agile program, combined with the differentfocus of agile on the outcome of the project, requires the use of agile metrics.

Learn continuously - the I&P iterationThe implementation and emphasis of the I&P iteration assures continuous learning and thus,continuous performance improvement. It enables the employees to get increasingly familiar withagile and the SAFe framework in order to master and innovate on it in the particular case context.

Agile as a change projectThe disruptive change in culture required by agile implies the agile transformation of anorganization to be executed as a change management project.

Structured stakeholder management

The inductive analysis has shown, that the interface challenges were most heavily felt on the portfoliolevel. Where the team level was challenged with the technical interfaces, and the program level withtechnical and process interfaces, the portfolio level faced both as well as human interfaces through strongstakeholders. Clearly the definition of the interfaces between the agile incubation and the plan-basedsurrounding organization is the most challenging task in the context of the agile transformation of aplan-based company.

It is up to the portfolio level to create a working governance structure for the program and itsenvironment. Where the program and team level can find work-around solutions on an incident-by-incident-base, the portfolio level has to take the meta-perspective and create structures which (ideally)avoid these incidents on the program and team level. Making use of the architectural runway as statedbeforehand, is one solution for aligning at least the technical interfaces.

The alignment of the process interfaces needs to be solved through good risk- and stakeholdermanagement. Since the plan-based processes are known (e.g. the long lead time for additional fundingor staff), the PI planning has to be granular enough to identify these hurdles early on. A strongstrategic planning of the value streams and the portfolio backlog enable the transparency to plan

54

ahead, and identify these risks (at least partially) in time. If ad hoc challenges through the processinterfaces emerge, the portfolio level has to step in and negotiate a fast resolvance of these challenges.This occurs through strong stakeholder management.

Yet, the stakeholder management becomes most crucial on the portfolio level. Regarding the humaninterfaces the strong direct stakeholders interfacing with the portfolio level are crucial for the programsuccess. Given the high number of stakeholders involved in this particular program, plan-basedstakeholder management methods facilitate the overview and management of them (see PMBOKguide (Rose, 2013)). Here the continuous education about agile is central. Ideally, the most criticalstakeholders should get an agile training (especially if the whole organization is to transform lateron). This will provide both sides the necessary knowledge and language to talk about the programperformance.

Lastly, shielding the program from interfacing with the plan-based organization is a way to createquick-wins and show the program success. This is recommendable in the adoption-phase, when theprogram has to learn agile and establish its own structures. However, once transitioned into theadaption-phase, the direct confrontation with the plan-based organization will reveal all the pain-pointsnecessary to adjust. The earlier they are discovered, the earlier a working solution for the programand its surrounding organization can be found. Agile reveals inefficiencies within the plan-basedorganization. Pointing them out starts the resolvance process within the surrounding organization.The agile part can meanwhile re-adjust and focus on alternative work to be done, while the initialroadblock gets resolved.

Disciplined agile implementation

The steps taken towards implementing agile have shown already first success within the case program.After initial hurdles of the adoption of agile, the fine-tuning through the adaption of agile is the taskwhich lies ahead. Here more subtle plan-based behaviours are to be dropped and the full agile mindsetis to be adopted.

Decide SAFe configuration

As a fist step, clarity about the agile framework to be implemented is critical. Emerging from the data,unclarity regarding the actual underlying framework to be used became clear. Is the program aimingto implement the Portfolio SAFe configuration, or the Full SAFe configuration? Depending on thedecision, fundamental structural differences will be made to the program. As an example, employeesperceived uncertainty about the terminology of the elements under development: are they features,capabilities, epics? A clear decision on the SAFe configuration will support the program with a clearstructure of ARTs, solutions, and value streams, as well as a common language, to which to refer. Italso determines the critical roles to be filled and the resulting communication lines.

Aligning the strategy

A second step is the strategic alignment on the portfolio level of the program. Central aspects like theimplementation of lean budgeting and the development of value streams (instead of the funding ofbusiness cases) are critical elements for achieving success through agile. The lean budgets are a mustbecause they enable the necessary nimbleness to fastly pivot. The process of lean budgeting can bealigned with the overall budgeting process of the company, but the critical part is the freedom in theuse of the budget in the course of the development.

55

The definition of the value streams (and the definition of done of their epics) will then ease the creationof an overall portfolio backlog. Much of the uncertainty observed in the case circled around what todevelop and when to stop its development. The incremental nature of the agile development makesthe line between not-yet-done and done less clear. This demands a firm stir on the definition of donethroughout all levels of the program (e.g. stories, features, epics). Working with the pre-defined ATRsand solutions trains of the program, their strategic unification within value streams is key on theportfolio level to guide all in the same strategic direction.

Discipline in the details

As a third step, discipline in the application of agile has to be evinced. Agile arose from the leanmentality. All the processes, structures, roles, and ceremonies exist to create a form of efficientflexibility for development under uncertain conditions. This implies, that the few elements outlined inthe SAFe framework (and the little time assigned to them) are the condensed version of previouslyextensive versions. Concluding, the execution of these remaining elements like roles, ceremonies, andcommunication lines have to be followed with high discipline to avoid inefficiency.

For the case program this starts with the disciplined execution of the ceremonies. No side conversationsor side tasks, full attendance, and full focus on the purpose of the meeting are critical. Side conversations,absence, or lack of focus create inefficiencies through re-work and the need for additional follow-upmeetings. Ideally, the meetings prescribed in SAFe are the only meetings necessary for the programexecution.

Similarly the roles SAFe prescribes are to be filled. Particularly if the program level is lacking criticalroles like the system architect, product manager, or release train engineer, the portfolio level andthe team level have to stretch their own role descriptions to cover for the lacking ones. This keepsboth from focusing on the execution of their own prescribed tasks and causes overwork and confusedcommunication lines.

Along with the ceremonies and the roles come the clear communication lines. SAFe details clearlywhat the most efficient path for agile communication looks like. Jumping several SAFe levels and notfollowing the clearly outlined communication lines distracts from the focus on the execution of thedevelopment and creates inefficiency.

Moreover, the alignment of the teams is crucial. The complex situation of the globally spread out teamsand the diverse IT-infrastructure used by the teams is certainly not a quick-fix and needs portfoliomanagement evaluation, as to which degree these issues are to be accepted or solved (consideringthe remaining time of the program). However, the alignment of the teams regarding their cadenceand the aim for full-staffing are critical issues for the success of agile. Once an operational rhythm isestablished within the program, these two elements will strongly decrease the operational performanceif continued in the current state. If a differing cadence of teams is necessary, they have to representmultiples of each other, i.e. a 2 week cadence on one team, and a 4 week cadence in another team. Thecentral focus needs to lie on the continuous alignment, which can only be achieved through a commonheartbeat.

Lastly, in an ideal situation, the creation of the program represents a permanent entity within theorganizations for which only the development tasks are changing. The establishment of the SAFeframework in terms of roles, structure, processes, governance etc. requires an initial investment which

56

brings brings a return on this investment, the longer the framework remains in use. For the futureagile transformation of the organization this could be a thought worth evaluating.

A final remark on the agile implementation

Even though the program has suffered from the 50% cut-back caused by the environmental uncertaintycorporate budget re-prioritization due to legal changes, it creates a strong chance for the program toalign. Having started with 40 people and quickly grown to a size of 400, the complexity due to itssheer size clouded the priorities in implementing agile in the program. The downsizing is a chancefor the program to align the smaller structures and bring them up to operational excellence. Onceachieved, additional work can be taken up again. In a sense, the cut-back is a great chance for theprogram to demonstrate its fast ability to adapt to this cut-back, and convince the external plan-basedorganization of its operational excellence despite the faced challenges. This way, understanding andawareness about the benefits of agile can be raised and word of success be spread.

Apply agile metrics

Strong uncertainty arose around the definition of the KPIs for the program. Applying the SAFeframework the use of agile metrics is necessary and central for two reasons. First, operating underagile conditions the application of plan-based metrics is very difficult to assess by the nature of theagile work-mode. Traditional plan-based perception of performance becomes irrelevant under agile.As an example, an adjustment in scope is not a consequence of poor up-front planning, but theability of the team to adjust to the real customer needs and thus avoid the unnecessary (and costly)development of an undesired offering. Moreover, the evaluation of traditional plan-based metrics willfrustrate program members and their stakeholders as the agile mode will continuously fail to completethem in a satisfactory way. The precise up-front definition of the golden triangle of cost, time, andscope (and its tracking throughout the development) which is demanded by plan-based approaches, isconsidered inefficient because uncertainty will most likely urge these numbers to change throughoutthe development. Agile on the other hand puts the focus on the real customer value and instead ofputting effort in planning the artificial golden-triangle, it values the quality of the developed offering.

Second, the changed view on development progress of agile, which focuses more on quality and valuedelivery, does not imply to not track performance - but to track it in a different way. SAFe (ScaledAgile Inc., 2018) gives many suggestions of KPIs to be assessed for all levels of the SAFe framework, sothey will not be elaborated in detail in the context of the report. It is however critical to mention,that the ability to forecast performance of any sort is the creation of a stable and sustainable operativework-mode. As an example, in order to make any kind of forecasting about the completion of thefeature or epic, the past history of the team performances is crucial. Overworking teams falsifies thisperformance history and leads to a distorted performance forecast which will not be met. Hence thecreation of a stable and sustainable operative work-mode is central. From this work-mode, forecastswhich are relevant to the strategic planning and the communication with the plan-based environmentcan be gained.

Learn continuously - the I&P iteration

Continuous learning stands at the center of SAFe and assures continuously increasing performance. Forthe case program this emphasis targets in particular the "innovation and planning" (I&P) iteration.

57

In the I&P iteration the teams are allowed to "catch breath" after the intense sprints in order to wrapup and prepare for the upcoming ones. Tying up of loose work-related ends (e.g. final testing), criticalresearch work, and important Pre-PI-planning (and Post-PI-planning) are central tasks to be executedin this phase. It is also here, where the employees are allowed to continuously learn more about agileand the SAFe framework, and continuously improve their work mode. It is however easy to overlookthe importance of the I&P iteration if the agile mindset is not yet fully internalized.

In the Japanese culture the process of learning, mastering, and finally being able to innovate/modify iscalled "Shu Ha Ri". This mindset is particularly enabled during the I&P iteration, where all employeesare able to learn and continuously improve their work mode. The I&P iteration is part of the continuouslearning mentality of Lean implied in SAFe in the relentless improvement column of the House-of-Lean.It is only here where the program as a whole can assure to increase and optimize performance.

Agile as a change project

For any further expansion of agile within the case company, the learnings from this case and the findingsin literature have shown, that the change towards an agile organization goes deeper than just the pureuse of the method. Due to its strong cultural change, the implementation of agile needs to be managedas a change project. To a degree, the case program has followed this thought through institutionalizinga PMO to implement agile (even though the PMO became quickly too plan-based). Independentlyfrom the change model (e.g. the change management model of Kotter (1996)), the underlying thoughtof creating urgency leading to a shared vision, empowering action and supporting lasting change, arealso central to the agile-transformation of organizations. The greater organization can build on thebest-practice example of the program analyzed and learn from its success and challenges.

58

5.2 Conclusion

This report provides detailed insights into the uncertainty faced by a manufacturer when developingProduct-Service Systems (PSS), and how this uncertainty can be managed through agile managementpractices. To provide these insights, this report describes the results of a case study undertaken atthe case company in the American aerospace and defence industry developing one large developmentprogram of a digital PSS. The analysis consisted of two elements: an inductive, and a deductiveanalysis. Based on previous literature, the deductive analysis tested the case for five mutually exclusiveand collectively exhaustive uncertainty types: technical, environmental, resource, relational, andorganizational uncertainty. As part of the inductive analysis, emerging concepts from the gathereddata were captured. This study offers four key learnings about uncertainty in the development of PSS.

First, all the uncertainty types identified in the theoretical pre-study were empirically confirmed in thepresent case. Compared with a previously conducted benchmark study, the pattern shows that thesefive uncertainty types are general characteristics for PSS development.

Second, the five uncertainty types occurred to a varying degree. In general in the present case andthe benchmark study, specifically the organizational uncertainty stands out as the most challengingand complex one. The root cause analysis has shown, that for most other uncertainty types perceived(except environmental uncertainty) an underlying organizational uncertainty was the cause.

Third, the application of agile has shown strong results in managing the uncertainty arising in thecourse of PSS development. Compared to the benchmark, the case company who was applying agilewas able to better manage uncertainty. Particularly the ability of agile to quickly identify, communicate,and resolve uncertainty, represent core characteristics of agile management practices to support theability of fast adaptation.

Fourth, while agile aided the management of uncertainty strongly, it also gave rise to additionalorganizational uncertainty caused by the adoption and adaption of agile. The adoption of agile gaverise to organizational uncertainty about the familiarization of the plan-based organization with the newstructures, processes, roles, and governance of agile. Here the overall program uncertainty increased inthe beginning through the challenge of agile adoption, and decreased over time (below the initial level)due to the learning of agile and its overall ability in uncertainty management. The adaption of agilegave rise to uncertainty about tailoring the agile method to the local needs of the organization. Thisuncertainty was unequally distributed throughout the hierarchies of the program. On the team level,the interfaces with the plan-based organization consisted mainly of technical interfaces and causedonly little uncertainty. On the program level, technical and process interfaces gave rise to additionaluncertainty. On the portfolio level, the uncertainty was felt strongest due to technical, process, andhuman interfaces (strong stakeholders).

For further optimization of the agile application in the case program, the biggest levers are theclear Definition of Done, the focus on agile training, the use of the architectural runway, structuredstakeholder management, and the disciplined implementation of agile.

In sum, the development of digital PSS is non-trivial and gives rise to uncertainty. A successfulapproach of managing this uncertainty is the use of agile management practices. However, the adoptionand adaption of agile in a plan-based setting causes additional uncertainty.

59

ReferencesAtkinson, R., Crawford, L. and Ward, S. (2006), ‘Fundamental uncertainties in projects and the scopeof project management’, International journal of project management 24(8), 687–698.

Baines, T. and Lightfoot, H. (2013), Made to serve: How manufacturers can compete through servitiza-tion and product service systems, John Wiley & Sons.

Baines, T. S., Lightfoot, H. W., Evans, S., Neely, A., Greenough, R., Peppard, J., Roy, R., Shehab, E.,Braganza, A., Tiwari, A. et al. (2007), ‘State-of-the-art in product-service systems’, Proceedings of theInstitution of Mechanical Engineers, Part B: journal of engineering manufacture 221(10), 1543–1552.

Barquet, A. P. B., de Oliveira, M. G., Amigo, C. R., Cunha, V. P. and Rozenfeld, H. (2013), ‘Employingthe business model concept to support the adoption of product–service systems (pss)’, IndustrialMarketing Management 42(5), 693–704.

Benedettini, O. and Neely, A. (2012), Factors influencing service complexity: The perspective ofservitized manufacturers, in ‘International Annual European Operations Management AssociationConference’, pp. 1–5.

Bianchi, M., Marzi, G. and Guerini, M. (2018), ‘Agile, stage-gate and their combination: Exploringhow they relate to performance in software development’, Journal of Business Research .

Blumberg, M. and Pringle, C. D. (1982), ‘The missing opportunity in organizational research: Someimplications for a theory of work performance’, Academy of management Review 7(4), 560–569.

Boehm, B. and Turner, R. (2003), ‘Using risk to balance agile and plan-driven methods’, Computer36(6), 57–66.

Cockburn, A. (2006), Agile software development: the cooperative game, Pearson Education.

Conforto, E. C., Salum, F., Amaral, D. C., Da Silva, S. L. and De Almeida, L. F. M. (2014), ‘Canagile project management be adopted by industries other than software development?’, ProjectManagement Journal 45(3), 21–34.

Cooper, R. G. (2016), ‘Agile–stage-gate hybrids: The next stage for product development blending agileand stage-gate methods can provide flexibility, speed, and improved communication in new-productdevelopment.’, Research-Technology Management 59(1), 21–29.

Crawford, L. and Pollack, J. (2004), ‘Hard and soft projects: a framework for analysis’, InternationalJournal of Project Management 22(8), 645–653.

Dingsøyr, T., Nerur, S., Balijepally, V. and Moe, N. B. (2012), ‘A decade of agile methodologies:Towards explaining agile software development’.

Eisenhardt, K. M. (1989), ‘Building theories from case study research’, Academy of management review14(4), 532–550.

Eisenhardt, K. M. and Graebner, M. E. (2007), ‘Theory building from cases: Opportunities andchallenges’, The Academy of Management Journal 50(1), 25–32.

60

Gebauer, H., Fleisch, E. and Friedli, T. (2005), ‘Overcoming the service paradox in manufacturingcompanies’, European management journal 23(1), 14–26.

Gunasekaran, A. and Yusuf, Y. (2002), ‘Agile manufacturing: a taxonomy of strategic and technologicalimperatives’, International Journal of Production Research 40(6), 1357–1385.

Highsmith, J. R. (2009), Agile project management: creating innovative products, Pearson Education.

Isaksson, O., Larsson, T. C. and Rönnbäck, A. Ö. (2009), ‘Development of product-service systems:challenges and opportunities for the manufacturing firm’, Journal of Engineering Design 20(4), 329–348.

Kastalli, I. V. and Van Looy, B. (2013), ‘Servitization: Disentangling the impact of service businessmodel innovation on manufacturing firm performance’, Journal of Operations Management 31(4), 169–180.

Kindström, D. and Kowalkowski, C. (2014), ‘Service innovation in product-centric firms: A multidi-mensional business model perspective’, Journal of Business & Industrial Marketing 29(2), 96–111.

Knight, F. H. (1921), ‘Risk, uncertainty and profit’, New York: Hart, Schaffner and Marx .

Kotter, J. P. (1996), ‘Leading change’, Heart of Change .

Kreye, M. E. (2016), Uncertainty and Behaviour: Perceptions, Decisions and Actions in Business,Routledge.

Kreye, M. E. (2017a), ‘Can you put too much on your plate? uncertainty exposure in servitized triads’,International Journal of Operations & Production Management 37(12), 1722–1740.

Kreye, M. E. (2017b), ‘Relational uncertainty in service dyads’, International Journal of Operations &Production Management 37(3), 363–381.

Kreye, M. E., Newnes, L. B. and Goh, Y. M. (2014), ‘Uncertainty in competitive bidding–a frameworkfor product–service systems’, Production Planning & Control 25(6), 462–477.

Kreye, M. E., Roehrich, J. K. and Lewis, M. A. (2015), ‘Servitising manufacturers: the impact ofservice complexity and contractual and relational capabilities’, Production Planning & Control26(14-15), 1233–1246.

Lay, G. (2014), Servitization in industry, Springer.

Lerch, C. and Gotsch, M. (2015), ‘Digitalized product-service systems in manufacturing firms: A casestudy analysis’, Research-Technology Management 58(5), 45–52.

Martin, R. C. (2002), Agile software development: principles, patterns, and practices, Prentice Hall.

Martinez, V., Bastl, M., Kingston, J. and Evans, S. (2010), ‘Challenges in transforming manufacturingorganisations into product-service providers’, Journal of manufacturing technology management21(4), 449–469.

Meadows, D. H. (2008), Thinking in systems: A primer, chelsea green publishing.

61

Melander, L. and Tell, F. (2014), ‘Uncertainty in collaborative npd: Effects on the selection oftechnology and supplier’, Journal of Engineering and Technology Management 31, 103–119.

Milliken, F. J. (1987), ‘Three types of perceived uncertainty about the environment: State, effect, andresponse uncertainty’, Academy of Management review 12(1), 133–143.

Mont, O. (2002), ‘Drivers and barriers for shifting towards more service-oriented businesses: Analysisof the pss field and contributions from sweden’, The Journal of Sustainable Product Design 2(3-4), 89–103.

Moran, A. (2016), MANAGING AGILE., Springer.

Neely, A. (2008), ‘Exploring the financial consequences of the servitization of manufacturing’, Operationsmanagement research 1(2), 103–118.

Nordin, F., Kindström, D., Kowalkowski, C. and Rehme, J. (2011), ‘The risks of providing services:Differential risk effects of the service-development strategies of customisation, bundling, and range’,Journal of Service Management 22(3), 390–408.

O’Connor, G. C. and Rice, M. P. (2013), ‘A comprehensive model of uncertainty associated with radicalinnovation’, Journal of Product Innovation Management 30, 2–18.

Perminova, O., Gustafsson, M. and Wikström, K. (2008), ‘Defining uncertainty in projects–a newperspective’, International journal of project management 26(1), 73–79.

Raddats, C., Baines, T., Burton, J., Story, V. M. and Zolkiewski, J. (2016), ‘Motivations for servitization:the impact of product complexity’, International Journal of Operations & Production Management36(5), 572–591.

Ramírez Hernández, T., Kreye, M. and Eppinger, S. (2019), Applicability of agile and scrum toproduct-service systems, in ‘26th International Annual EurOMA Conference 2019’, EurOMA.

Ramírez Hernández, T., Kreye, M. and Antelmi Pigosso, D. C. (2018), Typology of uncertainties in thedevelopment process of product-service systems, in ‘25th International Annual EurOMA Conference2018’, EurOMA.

Ramírez Hernández, T., Kreye, M. and Antelmi Pigosso, D. C. (2019), ‘Analysis of uncertainty in thedevelopment of integrated solutions’, Technical University of Denmark . ISBN: 978-87-93458-63-5.

Reim, W., Parida, V. and Sjödin, D. R. (2016), ‘Risk management for product-service system operation’,International Journal of Operations & Production Management 36(6), 665–686.

Rice, M. P., OConnor, G. C. and Pierantozzi, R. (2008), ‘Implementing a learning plan to counterproject uncertainty’, MIT Sloan Management Review 49(2), 54.

Rogers, E. M. (2010), Diffusion of innovations, Simon and Schuster.

Rose, K. H. (2013), ‘A guide to the project management body of knowledge (pmbok® guide)—fifthedition’, Project management journal 44(3), e1–e1.

62

Scaled Agile Inc. (2018), ‘Scaled Agile Framework’, https://www.scaledagileframework.com/#. Ac-cessed: 2019-06-26.

Schwaber, K. (2004), Agile project management with Scrum, Microsoft press.

Scrum Inc. (2017), ‘The Scrum Guide’, https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf. Accessed: 2019-07-04.

Spath, D. and Demuß, L. (2001), ‘Betreibermodelle für den maschinen-und anlagenbau’, ZWF Zeitschriftfür wirtschaftlichen Fabrikbetrieb 96(1-2), 35–39.

The Agile Manifesto (2001), ‘Manifesto for agile software development’.

Tukker, A. (2004), ‘Eight types of product–service system: eight ways to sustainability? experiencesfrom suspronet’, Business strategy and the environment 13(4), 246–260.

Vasantha, G. V. A., Roy, R., Lelah, A. and Brissaud, D. (2012), ‘A review of product-service systemsdesign methodologies’, Journal of Engineering Design 23(9), 635–659.

Wolfenstetter, T., Böhm, M., Krcmar, H. and Bründl, S. (2015), Why product service systemsdevelopment is special, in ‘2015 International Conference on Industrial Engineering and SystemsManagement (IESM)’, IEEE, pp. 1221–1228.

Yin, R. K. (1994), ‘Case study research: Design and methods (applied social research methods, vol.5)’, Sage Publications, Beverly Hills, CA. Rick Rantz Leading urban institutions of higher educationin the new millennium Leadership & Organization Development Journal 23(8), 2002.

Yin, R. K. (2011), Applications of case study research, sage.

Yusuf, Y. Y., Sarhadi, M. and Gunasekaran, A. (1999), ‘Agile manufacturing:: The drivers, conceptsand attributes’, International Journal of production economics 62(1-2), 33–43.

Zhang, W. and Banerji, S. (2017), ‘Challenges of servitization: A systematic literature review’, IndustrialMarketing Management 65, 217–227.

63

https://www.scaledagileframework.com/#

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

Appendix

64

I QuestionnairePersonal experience:1. Role:2. Experience in company (in years):3. Experience in role outside and inside the company (in years):

Product-Service System of the company:4. Can you explain the concept of your Product-Service System?

Development Process:5. Can you explain to me your development process for the PSS?5.1. Why did you decide to use agile?5.2. Contrast agile/scrum to Stage-Gate process? (How do you think it would have gone with stage-gate?)6. What went especially well during the development project of the Product-Service System? Why?7. What went especially not so well during the development project of the Product-Service System?Why?7.1.1. How strong was the impact? How predictable/anticipated was it to happen?7.1.2. How did you manage it? Did agile help you do deal with this better?7.2. Environmental challenges7.2.1. Customers, competitors, pricing, revenue model, demand changes, changes in legislation,competitor’s actions, technological development, political developments. . .7.3. Technical challenges7.3.1. Product, Service, System integration7.4. Resource challenges7.4.1. Capabilities, Information, Financing, Interdependencies of Projects, macroeconomic resources(energy, cost of licensing, raw materials)7.5. Organizational challenges7.5.1. Intersection with functions or processes, internal stakeholders (e.g. acceptance of “service-culture”, risk aversion of decision makers, varying uncertainty perception, strategic ambiguity in theprioritization of the project. . . ), project planning + execution (e.g. goal definition, determination ofmethods, design of experiments (simulation of lifecycle), alignment of sub-projects, forecasting. . . )7.6. Relational challenges7.6.1. Which stakeholders?7.6.2. Relationship: formal/informal, split of costs and risks, Intellectual property, Quality andtiming of agreed delivery, availability and reliability, hidden agendas, commitment, actual capabilities,management of uncertainties, bankruptcy. . .

Additional information:8. In retrospective: What should have been done differently and how? (lessons learned)9. Is there anything else you would like to add or clarify?10. Could you point out any additional information that would support my research project?11. May I contact you again?

65

Contact DetailsIf you would like to have further information about this project or engage in upcoming uncertaintymanagement research in the solution development context please contact:

Principal Researcher and Author

Tabea Ramírez Hernández ∗

Tabea Ramírez Hernández is a PhD candidate at the Department ofTechnology, Management and Economics, Technical University of Den-mark (DTU Management). In her research she focuses on uncertaintymanagement in the development process of integrated solutions. Withspecific interest in agile Tabea recently focused on uncertainty reduc-tion through agile methods. As her background, she completed hergraduate studies at DTU in industrial engineering and management,and is also a mechatronics service technician by training. Throughouther whole career she has worked in different areas of the manufactur-ing industry and has gained a deep understanding of its characteristics.

Contact

E-mail: [email protected]://www.dtu.dkwww.linkedin.com/in/tabea-ramírez-hernández-3a6abb100

∗Please contact Tabea Ramírez Hernández for any inquiries regarding the present study.

67

Faculty Supervisors

Melanie Kreye

Dr Melanie Kreye is an Associate Professor in Operations Managementat the Department of Technology, Management and Economics, Tech-nical University of Denmark (DTU Management). She further holdsan external positions at the Manchester Business School, The Univer-sity of Manchester, UK. Her research focuses on uncertainty in differentindustrial and academic areas including engineering service operations(servitization), product development and solution development. Her re-search has been published in peer-reviewed journals such as Omega – TheInternational Journal of Management Science, the International Journalof Operations & Production Management, and Production Planning andControl.

Contact

E-mail: [email protected]://www.dtu.dkhttps://www.researchgate.net/profile/Melanie_Kreye2

Steven D. Eppinger

Dr Steven D. Eppinger is Professor of Management Science andInnovation at the Massachusetts Institute of Technology SloanSchool of Management where he holds the General Motors Lead-ers for Global Operations Chair. His research focuses on improv-ing product design and development practices in a wide range ofindustries, and contributes to fields ranging from project manage-ment and systems engineering to product development and productmanagement. He has co-authored two impactful textbooks Prod-uct Design and Development and Design Structure Matrix Meth-ods and Applications, and is one of the most widely cited schol-ars in engineering design and technical management disciplines.

Contact

E-mail: [email protected]://mitsloan.mit.edu/faculty/directory/steven-eppingerhttps://www.researchgate.net/profile/Steven_Eppinger

68

application of agile in product-service system development · relational uncertainty may arise in...

Documents