Adoption Hurdles Faced by Organizations Embracing Safe®

SAMINT-MILI 20040 Masters Thesis 30 credits May 2020

Adoption hurdles faced by organizations embracing SAFe®

Alexis Rodriguez Leon Khushboo Singh

Master Programme in Industrial Management and Innovation

Masterprogram i industriell ledning och innovation

Acknowledgment

This thesis work has been a journey in which we have learned more about a new framework and many methods on how to proceed with qualitative research. This could not be done without the contribution of the interviewees who have collaborated, giving great inputs about this framework. This thesis could neither be done without the collaboration of the other students that gave us some great ideas and comments on our research during the seminars. Nevertheless, the collaboration of our subject reader was the key factor for us to complete the thesis because he has given us great feedback. Therefore, we would like to thank you all for the contribution and dedicate this thesis work to all of you.

Sincerely,

______Alexis Rodriguez Leon Khushboo Singh

Abstract Adoption hurdles faced by organizations embracing SAFe®

Alexis Rodriguez Leon and Khushboo Singh

Faculty of Science and Technology

Visiting address: Ångströmlaboratoriet Agile methodology has gained wide adoption. Agile methodology, with its Lägerhyddsvägen 1 House 4, Level 0 iterative and incremental approach for software development, has gained popularity within IT organizations that are facing a dynamic business Postal address: environment. Agile software development has emerged as an alternative to the Box 536 751 21 Uppsala traditional Waterfall model in delivering software at a faster pace and having

more receptiveness towards the changing requirements. However, Agile Telephone: +46 (0)18 – 471 30 03 methodology was originally designed for small and individual teams. This makes moving Agile to large-scale organizations a complicated task. In this thesis, we Telefax: +46 (0)18 – 471 30 00 will review the challenges and success factors presented by (Dikert et al., 2016) in their systematic literature review for SAFe (Scaled Agile framework). Our Web page: http://www.teknik.uu.se/student-en/ thesis is based on empirical research. The authors have conducted interviews to gather data to underpin or dissent from the findings in the systematic literature review regarding the challenges and success factors of implementing SAFe in organizations.

Keywords: Agile methodology, SAFe®, Organizational transformation., success factor, challenges, systematic literature review

Subject reader: Marcus Lindahl Examiner: David Sköld TVE- MILI19019 Printed by: Uppsala Universitet

Popular Science Summary

Agile methodology has become one of the most appealing processes for large firms that endeavors to enhance and improve their performance. Still, Agile methodology was originally designed for small projects in software development organizations (Dikert et al., 2016). However, scaling Agile in larger organizations is complex, and there are challenges involved in introducing Agile (Dikert et al., 2016, Kalenda et al., 2018). Large projects require coordination and communication between the teams. Proper management of dependencies between the teams, various Non-Agile units needs to be done. Therefore, larger organizations require the scaling of Agile practices, which are provided by the Scaled Agile Framework (Ebert & Paasivaara, 2017).

This thesis intends to try to analyze by an empirical study the challenges and success factors of implementing the Scaled Agile Framework (SAFe). The authors of this thesis will take the help of previous studies and interview Agile experts to come up with challenges faced by organizations pertinent to SAFe. This study will be executed because there are scarce researches about the perceptions of people working on this kind of framework. Also, it will be essential to know about it for companies that are trying to implement SAFe or for people that are interested in getting knowledge about this new framework that is relatively new in the IT sector. Since the IT industry is changing in a fashion pace, this new framework will help businesses to increase their deliveries efficiently. There are already companies that have implemented SAFe, and it has helped their business to continuously and efficiently deliver value on a regular and predictable cadence.

Table of Contents 1 Introduction ...... 1

1.1 Background ...... 1

1.2 Problem Statement ...... 2

1.3 Conceptualization ...... 2

1.4 Research Questions ...... 6

2 Theory ...... 7

2.1 What is Waterfall model? ...... 7

2.1.1 Issues with the Waterfall model ...... 8

2.2 What is Agile? ...... 9

2.3 Why Agile? ...... 11

2.4 What is SAFe? ...... 11

2.5 Why SAFe? ...... 13

2.6 The Transition from Waterfall to Agile to SAFe ...... 13

2.7 Organizational Transformation: ...... 14

2.8 Success Factors ...... 16

2.8.1 The management system: ...... 16

2.8.2 System and Structure (Social system): ...... 17

2.8.3 Technical system ...... 18

2.8.4 Behavioral system ...... 18

2.9 Challenges specific to General Organizational Transformation ...... 19

2.9.1 Change resistance: ...... 19

2.9.2 Challenges related to Training and Coaching Role in Organizational Change .... 20

2.10 Challenges specific to Agile Development ...... 21

2.10.1 Management and Organization issues ...... 21

2.10.2 People Related to Issues ...... 21

2.10.3 Process related Issues ...... 22

2.10.4 Technology (Tools and Techniques) ...... 22

2.11 Change Process Models to bring about the Organizational Transformation ...... 23

2.11.1 K ...... 23

2.11.2 The Kurt Lewin Model of Change: ...... 26

3 Methodology ...... 29

3.1 Abductive Study ...... 29

3.2 Semi-structured interviews ...... 29

3.3 Selection of participants ...... 30

3.4 Validity and Reliability ...... 32

3.5 Ethics ...... 33

4 Empirical Data ...... 35

4.1 SAFe ...... 35

4.1.1 Team Level ...... 35

4.1.2 Program Level ...... 36

4.1.3 Portfolio Level ...... 36

4.2 SAFe Implementation Roadmap ...... 37

4.2.1 Reaching the Tipping Point ...... 38

4.2.2 Train Lean-Agile Change Agents ...... 39

4.2.3 Train Executives, Managers, and Leaders...... 39

4.2.4 Create a Lean-Agile Center of Excellence ...... 40

4.2.5 Identify Value Streams and ARTs ...... 41

4.2.6 Create the implementation Plan ...... 42

4.2.7 Prepare for ART Launch ...... 43

4.2.8 Train Teams and Launch the ART ...... 44

4.2.9 Coach ART Execution ...... 45

4.2.10 Launch More ARTs and Value Streams ...... 45

4.2.11 Extend to the portfolio ...... 46

4.2.12 Maintain and Sustain ...... 46

5 Results and Data generated during the interviews ...... 48

5.1 SAFe levels: ...... 48

5.2 Challenges and Success Factors combined ...... 50

6 Analysis and Discussion ...... 57

6.1 Analysis ...... 57

6.1.1 The SAFe implementation road map ...... 57

6.1.2 The Challenges ...... 60

6.1.3 The success factors ...... 66

6.2 Discussion ...... 70

6.2.1 The Challenges and Success factors ...... 70

6.2.2 The Failure of Communication between the different Levels ...... 71

6.3 Limitation of the study ...... 73

7 Conclusion ...... 74

References ...... i

1 Introduction

Agile methodology has become one of the most appealing processes for large firms that endeavors to enhance and improve their performance. However, Agile methodology was initially designed for small projects in software development organizations (Dikert et al., 2016). Agile was intended as a corrective measure to the previously used traditional Waterfall model. The waterfall model is called as a heavy-weight process because it is based on a sequential series of steps (Khan et al., 2011). In the Waterfall model, products are designed by a group of people, which are later handled to another group of people to build, and then another set of people for documentation and support (LeMay, 2018). Agile addresses these limitations by working in a cross-functional team, in which all the people involved in a product creation collaborate from its inception to its launch (LeMay, 2018). Agile is called as a light-weight process because the intention is to adapt and fit according to the situation and allows the development team to build solutions more quickly and efficiently and with better responsiveness to changes in the business requirement (Khan et al., 2011). Besides, it is an incremental process, in which the product is being completed in short iterations rather than the entire product at once. In Agile methodology, the users are actively involved in prioritizing, establishing, and verifying the requirements (Boehm & Turner, 2005). Agile is about bringing incremental change to become more flexible to changing requirements as opposed to the conservative waterfall model where the requirements are set in the beginning, and feedback is provided only after the product release.

1.1 Background Agile methodology was initially designed for small projects with a single team in IT organizations (Boehm & Turner, 2005). The potential benefits of the Agile method have made it accessible, even for the larger projects (Dikert et al., 2016). However, scaling Agile in larger organizations is complex, and there are challenges involved in introducing Agile (Dikert et al., 2016, Kalenda et al., 2018). Large projects require coordination and communication between the teams. Proper management of dependencies between the teams and various Non-Agile units needs to be done. Thus, scaling Agile becomes difficult due to the coordination of multiple teams, problems in organizational structure adaption, and issues in understanding the Agile concepts along the value chain (Dikert et al., 2016). Therefore, larger organizations require the

scaling of Agile practices, which are provided by the Scaled Agile Framework (Ebert & Paasivaara, 2017). Among various frameworks adopted, such as SAFe, Scrums of Scrum (SOS), LeSS, Disciplined Agile Delivery (DAD) by the firms, and others, SAFe is more widely used (Dikert et al., 2016).

1.2 Problem Statement A systematic literature review has revealed a lack of research regarding the adoption of Scaled Agile Framework in organizations. There have been researches on new frameworks for scaling Agile such as SAFe, LeSS (Large-Scale Scrum), or DAD (Disciplined Agile Delivering). However, the research on related challenges and benefits of implementing this Agile scaling framework is still scarce (Paasivaara, 2017). Therefore, this thesis intends to analyze by an empirical study the challenges and success factors of implementing the Scaled Agile Framework (SAFe). This thesis is based on empirical research guided by the perception of Agile experts. Our intention is to empirically analyze the success and challenges mentioned in the systematically literature review. Through the interviews, we will analyze the related challenges, success factors, and suggest possible recommendations in the end.

1.3 Conceptualization The Agile framework is better suited for the development of small projects. Unfortunately, Agile has problems being implemented in larger projects, and one of the issues is the coordination between the teams. The most popular methods used in Agile are Extreme Programming (XP) and Scrum. XP collects practices for facilitating incremental development, and Scrum focuses on project management recommending timeboxing, continuous tracking of the project but also having the customer in the center. (Hamed & Abushama, 2013). We have already mentioned that Agile was created and established in Software development; in fact, it is based on Agile Philosophy, which is captured in the Agile Manifesto. Moreover, Agile is recognized as a software engineering method that works with iterations and manages changes efficiently. (Highsmith & Cockburn, 2001) However, working in SAFe means to involve different units of an organization, i.e., HR, sales, marketing, or Research and Development teams, and still work with the basics of the Agile methodology.

Another difficulty with Agile is its inertia, which slows down organizational changes due to the size of the company, but also Agile requires changes in the already established culture in a

Company (Misra et al., 2010). In the research written by Kim Dikert, Maria Paasivaara, and Casper Lassenius (2016), they have mentioned the challenges and success factors for large scaled-Agile transformation. The importance of their research is that they have done a systemic literature review that consists of 1875 scientific papers and cases, which in the end, they removed many and ended up with only 52 relevant articles for their analysis. Their findings are the reason why we chose to follow up on the topic of SAFe challenges and success factors. The challenges encountered in their paper were about 35 and about 29 success factors. The challenges are divided into 9 different groups and the 29 success factors into 11 different groups. However, in this thesis project, we have chosen some of all challenges encountered about the transformation into Large-Scaled Agile, which are more in our interest. We want to study the challenges related to management, people, and process issues. The challenges that are related to engineering and technical problems have been left out in this thesis project.

Change resistance: The authors explained the employees' skepticism while implementing a new method. But also, when managers are imposing a new method into the system without explaining it well.

Lack of Investment: The company and managers are not investing money in training. No training results badly because the employees will rather ignore the Agile practices and probably broke the whole methodology.

Agile difficult to implement: It has a lot to do with the lack of investment since there will be a misunderstanding of the Agile concept and lack of guidance, especially when it comes to a large scale. A poorly introduction of Agile will lead to change resistance, and in the end, employees will go back to the old way of working.

Coordination Challenges in Multi-Team Environment: Most of the challenges were the interfacing between teams since Agile created flexibility at the team level but at not at the organizational level the SAFe framework, because it was not responsive enough. Independent teams obstructed coordination because teams focused more on their own goals instead of the broader goals of an organization. Also, the coordination failed because teams worked for different customers, and the building parts of a software were interdependent, and this caused different teams to have different sprint durations, which led to delays in delivery. Another challenge in this segment was distance and time

because groups could not attend to kick-off meetings; they faced communication problems due to technical difficulties and also trying to arrange continuous meetings.

Different approaches emerge in multi-team environment: The authors explained that the interpretation of Agile differed between teams since teams implemented the method without specific guidance. Also, companies tried to shift into Agile methodology by using both their current methodology along with Agile and this created confusion between the members but also causing tensions on all organizational levels.

Hierarchical Management and organizational boundaries: The challenges encountered were for the middle managers as their role was unclear on Agile methods. Agile organizations require cultural changes and notably at the intermediate management level. It was challenging to change the mindset of managers from being dependent on command and control to allow room for self-organization. One of the problems was that employees felt micromanaged due to the new roles of the managers appointed as Scrum Masters instead. Another problem was the generation of conflicts between project managers and Scrum Managers because the role of Scrum managers turned into one of policing instead of backing up the team. Other problems within the organization have been the way back to work in the old Waterfall model, even though after adopting Agile because the management focuses more on meetings and big up- front project plans. The going back to the old way of working led to keeping the old bureaucracy, which led the employees to work on two different frameworks, and employees were forced to keep double documenting every process for each framework.

Integrating non-development challenges: The challenging part was the resistance to change of other functions or units. Also, the delivery pace that it is required from different groups and units since Agile methodology works on fast changes, and it affected the delivery time cycle, for instance, the product launch activities.

On the other hand, we are interested in some of the groups of the success factors. The reason why we left out some of the success factors mentioned in the systematic literature review is that those factors are already covered in the ones mentioned below. Therefore, there was no necessity to refer to others.

Management support: The management team is involved in the development of Agile implementation. Managers make themselves visible by training the employees but also encouraging them to adopt a new way of working.

Commitment to Change: The authors mentioned that employees would commit to the change if managers are transparent about the hurdles employees might face during the implementation, but also, indicating that the new way working will fix the current and future issues. Moreover, it is necessary to mention that the change is not negotiable, and it has to be accepted.

Choosing and customizing the Agile approach: The authors explained that selecting the correct Agile method according to a company's model should be the first step for implementing the new Agile method successfully. However, it is not only about the company's current model but also having in consideration the workflow that teams have and suit a way of working for each team according to Agile. Also, an organizational chart should be simple for a better comprehension of the new framework, and it needs to be visible for each unit or team to avoid misunderstandings.

Piloting: Piloting is a way of gaining employees' trust by showing that Agile can be implemented in a few groups and that it works. Also, Piloting helps to gather insights from teams or others and helps to develop the methodology further and mitigate problems for the rest of the implementation in an organization.

Training and Coaching: Those words are the core for successfully implement a new method in an organization. The authors mentioned that training should be provided to the employees, and this will make people enthusiastic about the change. Coaching should exist in a company for the transformation because it allows employees to avoid failing in their job, and also for teams to prevent damaging the way into the change.

Communication and transparency: The authors indicated to communicate the change or implementation of Agile methodology continuously. The message needs to be transparent to reach out for feedback. An example is to hold meetings of the roll-out team in public and share positive experiences letting people know the status of the

transformation, but also giving employees information that everything is moving in the desired direction.

Mindset and alignment: The authors indicated that there is a need for sharing experiences. The success of a group helps other groups to achieve success as well and let the team members concentrate on the Agile Values. The success factors or hurdles face by a group should be shared on internal social events because it improves bonding within teams. However, we cannot mitigate that to be successful in implementing Agile, an alignment of the method is needed within the company by having a complete understanding of the methodology and how it implies for the better.

This thesis contributes an empirical study on an existing systematic literature review. It also aims to provide possible recommendations to improve SAFe implementation.

1.4 Research Questions RQ1: How have the challenges encountered in the systematically literature review been conceptualized according to the experiences of people working on SAFe?

RQ2: How have the success factors encountered in the systematically literature review been conceptualized according to the experiences of people working on SAFe?

2 Theory

The theoretical framework aims to explore organizational transformation and change models, as SAFe implementation also involves an organizational transformation process. As the study seeks to identify success factors and challenges as perceived by people working with SAFe, a brief introduction of the Agile concept, its principles, and transition to SAFe will be discussed. This will be followed by organizational transformation theories and change process model. The theoretical framework aims to provide readers with sufficient knowledge to be able to analyze our empirical findings.

2.1 What is Waterfall model? The waterfall model, also known as a linear sequential life cycle model is a classic and traditional model which is the foundation of software development. It consists of five steps, which follow a linear sequential order (LeMay, 2018). In this model, the requirement sets up from the beginning, and the feedback is received after the product has been released. This classic model starts with concept inquiry, then analysis of requirements followed by the designing, implementation, and testing. This model becomes time-consuming since the development team proceeds from one phase to the next in a purely sequential manner (Dima & Maassen,2018).

Figure 1. The Waterfall Model (LeMay, 2018)

2.1.1 Issues with the Waterfall model O a aa a a a requirements cannot be ensured until the project is finished. The model offers a well-defined set of criteria and requirement indication, before the actual start of designing and implementation phase of the project. All these factors make the model more appropriate for projects that have unchanged or stable requirements for a extended period. As per Othman, the waterfall model works with the concept that one phase needs to be finished before the next one starts (Othman et al., 2017). It poses a considerable amount of risk that errors from the previous phase are carried forward in the next phase because verification occurs close to the end of the product development process. The type of model thrives on the traditional type of management organization where requirement flows down from the top management to lower-level management and further down to employees. Also, it causes minimal to non-contact between the customers, stakeholders, and the development team (Dima & Maassen, 2018).

Figure 2. A comparison of the Waterfall model towards Agile (Moreira, 2013)

2.2 What is Agile? Agile follows an iterative sequential approach where a product is developed in several short iterations. Agile methodology is better suited for projects where requirements change rapidly, new features need to be implemented quickly, and the competition of the product field is high (Hansmann & Stober, 2010). This is because of the flexibility of customer requirements, implementation, and frequent product releases. The two main versions of Agile methodology in software development is the Scrum method and test-driven development (Dima & Maassen, 2018).

Scrum is a rough outline of processes based on iterative development, and it comprises of three roles, three documents, and three meetings. The three roles are the product owner, the team, and the scrum master. The product owner represents the interest of all the stakeholders, such as customers, marketing, the teams, etc.; also, they provide the requirements, funds for the project, as well as sign off on deliverables (Hansmann & Stober, 2010). Then, the development team is responsible for developing and testing the project deliverable. The Scrum Master is responsible for ensuring that the team can be as effective as possible, and any issue gets resolved. Also, they have the responsibility to verify that the test cases and code reviews are done.

The three documents include product backlog, sprint backlog, and sprint result (Hansmann & Stober, 2010).

First, a product backlog is created, which is a list where the customer's requirements are prioritized and selected. Afterward, the requirements are split in small iteration called sprints. Every sprint is a small and manageable iteration, and the duration is usually two weeks. A sprint contains design, development, testing, and documentation (Hansmann & Stober, 2010). The goal is to produce a stable and tested deliverable that can be submitted to the customers. In the first instance of a sprint, the team selects the most critical cases that have to be delivered in the current iteration. Those cases are referred to as a sprint backlog. The sprint backlog is negotiated between the Product Owner, the Scrum Master, and the team to use cases during the sprint, and it is documented as a sprint result (Hansmann & Stober, 2010). The successful implementation of Scrum methodology requires the involvement of development teams that have to meet daily to discuss software development progress and hurdles in order to implement requirements quickly (Dima & Maassen, 2018).

The three meetings are the Sprint planning meeting that takes place at the start of each new sprint where the Product Owner and the Scrum Master decide on sprint backlogs and what a team can commit to delivering results in one sprint.

Daily scrum meeting is done to determine progress and solve issue or problem that arises.

Sprint Review is done at the completion of each sprint where the Scrum Master, the team and the Product Owner meet to review the result achieved during the sprint.

Figure 3. The Scrum Method (Dima & Maassen, 2018)

Agile has twelve principles that are based on the Agile Manifesto (Hohl et al., 2018). It is different from the Waterfall model, in which they usually create their values and principles according to the organization's principles. This manifesto is essential and useful for organizations that pursue competencies in Agile software development. The most important values that this Agile manifesto has are the following: working software, individuals and interaction, customer collaboration, and responding to change. Therefore, the creation of the 12 principles are used to support the Agile methodology, and those are the following (Greene & Stellman, 2018):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness a aaa.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 5. Businesspeople and developers must work together daily throughout the project. 6. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity the art of maximizing the amount of work not done is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more productive, then tunes and adjusts its behavior accordingly.

2.3 Why Agile? In today's scenario, when technologies are evolving and changes are quite frequent, the lifecycle of IT and other products are getting short and newer products are launched to meet the changing customer demands. The customers' requirements are changing quickly, and new features are required to be implemented faster. Therefore, it requires a dynamic model rather than the conservative waterfall model. The Agile methodology is more appropriate than the Waterfall model due to its iterative nature. It provides increased flexibility in customer requirement implementation and frequent release of the product (Dima & Maassen, 2018).

2.4 What is SAFe? The framework SAFe is for scaling Agile in large enterprises. Dean Leffingwell introduced this new framework. The main idea behind the SAFe is Agile development, lean product development, and system thinking, and this model was created to incorporate the power of the Agile approach and be a step ahead to overcome all challenges that large-scale organizations might face. SAFe supports companies of various sizes, ranging from smaller ones with fewer than a hundred employees to larger ones with thousands of employees (Kalenda et al., 2018). The architecture of SAFe contains three different levels: the Portfolio level, the Program level,

and the Team level. At the portfolio level, multiple synchronized ART (Agile Release Train) are required to support the development of large and complex solutions that define large development initiatives. At the program level, strategies and investment funding are defined for the value streams and solutions.

The program level contains practices, principles, and roles needed to initiate and govern a set of development Value Streams. At the program level, several roles and teams are included, such as System team, program manager, system architect, and RTE (Release Train Engineer but also Business owners in order to continuously deliver solutions via an ART (Agile Release Train). ART is a virtual organization that is created to span functional boundaries, implements SAFe Lean-Agile principles and practices in order to eliminate unnecessary steps, and accelerate the value delivery. Furthermore, ARTs are entirely responsible at the program level for generating and releasing value in a flow that is needed to meet the market and customer demand.

At the Team level, Agile teams build and deliver value in the context of ART. This Team level shows how to create high-performing teams that generate high-quality solutions but also supporting both team agility and technical agility. Each team is responsible for outlining building and testing stories from their team backlog in a series of fixed-length iterations (Paasivaara, 2017).

Figure 4. SAFe for lean enterprises. (Leffingwell, 2011).

2.5 Why SAFe? Agile software development emanated from small scale setting. It is easy to adopt and introduce Agile in a small organization, but Agile processes are challenging to implement in a complex and large-scale organization. Thus, Scaled Agile Framework was developed to support the differing large-a , b a a a b a a?. I mentioned that the scale in Agile development should be based on the number of teams involved in the development project. Therefore, three levels are suggested A) Small scale (one team) B) Large scale (Two to nine teams) C) Very large scale (ten and more) (Scheerer, 2017).

2.6 The Transition from Waterfall to Agile to SAFe There is little consensus among technical reports about the evolution of Agile methodology in software development. Agile was first implemented in the Software industry and soon gained entry in various diverse industries (Rashina et al., 2018). The timeline is created to give an idea of how the Agile methodology, specifically Scrum, evolved in the software industry, followed by the Emergence of Scaled Agile Framework, such as LeSS and SAFe (Hexacta, 2018).

Figure 5. Agile Evolution Timeline

1910: Henry Gantt invented the diagram for project management. 1916: Henri Fayol brought about the concept such as division of labor, centralization of labor, unity of command 1927-32: Elton mayo through the Hawthorne experiment concluded that team productivity increases because of the motivational effect on workers.

1953: The word Software was coined 1956: Herbert D. Benington gave the first formal description of the Waterfall methodology. 1985: The United States Department of Defence standardized Waterfall methodology and made it a standard for software development. 1986: Barry Boehm Described the spiral process. Introduced iterative development to mitigate risk. In the same year, Takeuchi and Nonaka coined the term Scrum for the first time in their a N a.. 1990: Ken Schawaber used the Scrum software development process at his company. 1995: Schawaber and Sutherland published the paper Scrum. 1996-98: Rational software company developed a unified, iterative, and incremental software process, which became the standard of the industry. 1999: Kent Beck published Extreme programming Explained, setting the stage for Agile revolution. 2001: The Agile manifesto was published. a) Individuals and interactions over the process and tools b) Working software over comprehensive documentation c) Customer collaboration over contract negotiation d) Responding to change over following plan. 2003: Tom and Mary Poppendieck published their book Lean software development, a aa Ta Just in time system for the software industry. 2008: The principle Software Craftsman was established, the fifth value of Agile manifesto. 2009: T DO a a a DevOpsdays 2010: Da A Pb Kaba, a a ba Ta production system. Today (From 2011): Agile methodology was being scaled to meet the requirements of large organizations with Multi-team environment, through frameworks such as Less (Large scale scrum) and SAFe.

2.7 Organizational Transformation: An organization is a social unit consisting of people who work together to achieve a goal. Oaaa aa a D , a a in an organizational entity where the entity can be the overall organization or a subgroup within aa (Pa a., 2019). Oaizational Transformation aims to bring change for

the betterment of the organization. Transformation is carried out to ensure the survival of the organization as well as to improve the efficiency and effectiveness of the organization in delivering better products and services (Musa, 2016).

Organizations transform in reaction to the change and to remain competitive. The changes done by the high performing organization are proactively and adequately planned. Various factors cause organizations to undergo transformation (Musa, 2016). The changes depend on the organization's environment and vision. Changes can be due to new government policies, change and development of new material, change in trade policies and national or global economic conditions, technological development, change in customer preferences, development, and innovation, etc. (Stephen et al., 2005). Anderson and Ackerman mentioned three types of changes (Anderson & Ackerman Anderson, 2001):

1. Development changes: It refers to existing skills and methods. They are improvements b a a aa a. H a a need to communicate the purpose and goal of change.

2. Transitional change: It replaces something in the existing operation to better serve future or current demands. Change leaders assess the needs and opportunities to design a future state to satisfy their requirements.

3. Radical change: It is a radical shift from one state to another. It requires a shift of culture, behavior, and mindset to implement successful transformation.

As per Kotter, transformation is the adoption of new technology, major strategic shift, process reengineering, improvement in innovation processes. (Kotter & Cohen, 2002). Technological change and changes in the business processes are one of the major causes of the organizational transformation in order for organizations to retain their competitiveness and to improve their quality of products and services to their customers (Musa, 2016). Edosoman mentions that Organization transformation can play a vital role in helping organizations gain a competitive advantage to achieve leadership in their domain and improve overall performance (Edosoman, 1996). Organizational transformation requires change management practices for its proper execution. An organization has to plan the changes and several other activities in order to implement a new way of working and bring about organizational transformation (Paton, 2008).

We have tried to identify success factors and challenges of the transformational process. We have categorized the challenges related to general transformation process and to Agile Development.

2.8 Success Factors 2.8.1 The management system: It deals with policies and procedures that are enforced and maintained. The management system deals with the leadership system that sets the vision for what needs to be done and the goals that need to be accomplished (Anderson & Ackerman Anderson, 2001). In the transformation process, the leadership system plays a vital role in ensuring that all programs are properly aligned towards the realization of the goals (Anderson & Ackerman Anderson, 2001). Kotter is of the view that transformation is 70% of leadership and 30% of management (Kotter, 1995).

A leader must verify and communicate the need for the transformation to members of organizations and various stakeholders. They must develop goals and strategies, and internal support for the transformation to reduce resistance towards the change process (De Waal, 2018). Clear and consistent goals, with unambiguous metrics and milestones, are needed to ensure that progress is effectively tracked (De Waal, 2018). As per Anderson & Ackerman, a transformational change requires the right mix of leadership skills and styles. Transformation requires leaders to develop their view of people, organizations, and the change that is required (Anderson & Ackerman Anderson, 2001). The management system is also associated with good governance, which is based on accountability, integrity, and transparency (Musa, 2016). The management system needs to institutionalize and embed the transformation and incorporate new procedures in their daily routines. They should develop a comprehensive approach to achieve a subsystem congruence. They should focus and invest in the training and coaching of a a a a a a a a a aa a a aa (D aa,2018). T aa ensuring vision and commitment is significant. There must be adequate management for the planning and implementation of organizational change. The development and achievement of business strategies require successful implementation, which is dependent on the effective management of the resulting change (Musa,2016). Filomena mentioned three managerial drivers for planning a transformation mobilizing, communicating, and evaluating. Communicating refers to explaining the ongoing actions taken by the leaders to engage

members of the organization in their decisions and actions (Filomena et al., 2018). A successful transformation process requires effective communication that caters to inform, consult, and promote action that helps in overcoming both the resistance and ignorance to change (Paton, 2008). The communication acts as a building block of organizational alignment and aligns employees with the company's mission. (Johnson, 2014). Kotter also emphasized the importance of communicating the need for change by the leaders. Communication should enable the people and stakeholders to understand the vision, goal of the change and should involve feedback and maintaining an effective dialogue with the stakeholders and ensure penetration of change within the organization (Kotter,1995). Mobilizing refers to steps taken by the leaders to provide organizational members with the opportunity to pursue dialogue to foster the acceptance of a new work routine. Evaluation is carried out by leaders to assess and monitor the impact of their implementation of the transformational process (Filomena et al., 2018).

2.8.2 System and Structure (Social system): This includes organization culture, structure, motivation, rewards, the creativity of individuals and groups to ensure the achievement of organizational goals (Edosoman, 1 996). As per Anderson & Ackerman, culture is a sum of an organization s indicator of culture, for instance, leadership approach, ways of communication, use of tools and processes, etc. (Anderson & Ackerman Anderson, 2001). Moreira points to the fact that culture change is a transformation the requires most time and effort by an organization (Moreira, 2013). Structure refers to the arrangement of the organizations to represent the various divisions and relationships between the divisions. The transformation process requires a robust organizational structure compatible with the approach and direction (Musa, 2016). The motivation of employees is required during transformation at all levels of the organization. Leaders and change agents need to facilitate the individuals' awareness of the need for change, stimulate the interest, commitment and engage in counseling and therapy to minimize fear in order to reduce opposition (Musa, 2016; Paton, 2008) as the resistance and opposition could ultimately block the change process. They must be capable of socializing within the network of stakeholders and managing the communication process (Paton, 2008). They also need to motivate the employees through rewards and training and coaching that act as a significant catalyst for the change (Scheepers, 2013). Training and coaching support individuals and organizations change performance by increasing consonance with the change mission by facilitating the creation of an organizational culture that values and fosters the transformation (Paton, 2008). Creativity and talent are required for employees to

have sufficient skills and knowledge to assist in bringing out the transformation (Musa, 2016; Edosoman, 1996).

2.8.3 Technical system It refers to the tools, resources, and mechanisms required to bring about the transformational process (Edosoman, 1996). A successful transformation requires proper work plans, processes, redeployment, and realigning of scarce resources towards new activities (Musa, 2016; Edosoman, 1996; De Waal, 2018). Organizations must evaluate their current conditions, processes, tools, and resources to bring about the change (Musa, 2016; De Waal, 2018).

2.8.4 Behavioral system It refers to the attitude, cognitive & psychomotive elements, perception, mindset, and other fundamentals of the human side (Edosoman, 1996; Musa, 2016). The behavioral system is often difficult to change, but when it is changed, it greatly speeds up the organizational and process transformation (Edosoman, 1996). Gustavsson believes that culture, mindset, and behavior are crucial factors for long-term change (Gustavsson, 2016). Anderson & Ackerman mentioned that change in the mindset causes behavioral changes in leaders and employees, thereby creating a shift in the organizational culture to adapt and change, which eventually leads to a successful implementation of change and achievement of business imperative (Anderson & Ackerman Anderson, 2001).

Overall, with the help of the above-mentioned founding elements (Success factors) that are tightly knitted to each other, Organizations need to rethink, examine, and evaluate all current conditions of the organization. The strengths and weaknesses need to be identified before heading for the transformation (Edosoman, 1996). SWOT analysis of the internal and external environment is essential to ensure that the transformation plan developed is comprehensive and has frameworks in place that consider various aspects (Musa, 2016). A proper evaluation of an organization's mission, goals, and values needs to be addressed to bring real value from the transformation (Edosoman, 1996; De Waal, 2018).

2.9 Challenges specific to General Organizational Transformation

2.9.1 Change resistance: Resistance can be thought of as an opposite reaction that shifts the direction of a change initiative. The reason that people resist changes is that it changes their routine, consistent and ab aa a . Oaaa a a comfort zone that causes resistance. Individuals join organizations for a role, congruency and consistency and not for being continuously put into a change driven chaos and turbulence. Organizational changes sometimes threaten the values, behavior, belief, and job of the individuals within the organization. This fear encourages them to protect and defend themselves. It is a direct propionate reaction, and the more is the fear, the more is the resistance. Increasing the magnitude of a change entails a stronger resistance. However, resistance is not always negative; occasionally, resistance can prevent change agents from committing a serious mistake (Anderson, 2011).

Aaron Anderson, in his book engaging resistance, mentioned the following reasons for the change resistance (Anderson, 2011):

Inherited Culture: The employees feel reluctant to relinquish their existing culture and acquire a new culture brought about by the change process. The new transformation requires different leadership styles, expectations, and vision, so the resistance comes from the established culture of the prior administration.

Reluctance to take on new work: Additional work brought about by the change processes make people resistant towards the change process. People expect to continue what they are doing while also tackling new priorities brought about by the change process.

Status quo protection: Change process shakes up the status quo. Being good at or excelling at one's job keeps employees working by the method they are familiar with and resist any change that can challenge their status quo.

Culture clash: Organizational transformation shred the fabric of the institution by removing the cultural fibers of tradition that glues an organization together.

Fear: Threat of job loss, uncertainty about new initiatives, methods, and processes creates discomfort and confusion among the people that generate fear. The change process involves many irregularities, and those affected did not always have enough information to see the bigger picture.

Legitimate concern: Some resistance is caused by the legitimate concern about a process or product being feasible. Problems with change processes and a mistake made by the change champions can cause grave concern among the employees. They reach their well-considered conclusion that the proposed plan will not work.

Unfair champion behavior: Sometimes, resistance may occur when champion behavior is construed as unfair or hypocritical. Trustworthiness is one of the crucial parts of the change equation. Asking other people to change without changing yourself can be construed as hypocrisy.

Personality clashes: All transformational processes must consider personal beliefs, personalities, and values. Resistance occurs when people are intolerant to one another. Some people resist just because they do not support a particular champion.

2.9.2 Challenges related to Training and Coaching Role in Organizational Change Organizations are operating in a dynamic and challenging global environment. To cope up with the change, organizations need to manage change and develop or apply new knowledge and skills (Rosha, 2016). A change process requires competency development. A strategic training plan is required for managing the organizational transformation to ensure that existing HR remains competitive to serve as the key forces in supporting and implementing reforms of systems and processes (Musa, 2016).

One way to ensure Competency development is through training and coaching (Musa, 2016). Coaching is a training process that helps in developing self-confidence and self-efficacy. The cores of coaching lie in learning and change. Coaching facilitates the learning and development b a a a a a a

in achieving organizational goals (Morten et al., 2012). Coaching is a way to support individuals in an organization's change performance by increasing the congruence with the mission (Stevenson, 2014). However, coaching takes time, skills, and proper planning of the resources. Lack of resources and planning can cause hurdles in the coaching that can pose to be a factor inhibiting the change process (Gallo, 2015).

2.10 Challenges specific to Agile Development

2.10.1 Management and Organization issues As mentioned in the transformation element, organizational culture has an impact on the structure of the organization that influences the behavior and action of people. Culture has a significant influence on the decision-making process, problem-solving strategies, planning & control mechanism, and innovation. The values and norms are stabilized and continuously reinforced over time, which is reflected in the policies incorporated in organizational routines. Culture and people's mindsets are difficult to change. Agile methodologies require a change in the organization's culture. A shift from the command and control management to leadership and collaboration requires the right blend of autonomy and cooperation to achieve the advantage of synergy while being flexible and responsive at the same time (Nerur et al., 2005). The knowledge management process also requires significant change. In a traditional heavy process-centric organization, there is a requirement of maintaining much of documentation. The agile methodology emphasizes on lean thinking and cutting on overheads such as documentation. (Misra et al., 2010). It parts away from heavy documentation to more on show working solution approach. Most of the knowledge in Agile development is tacit and remains in the head of the members of the development team. Ii makes organizations heavily depend on the development team rather than the management. A significant change in organizational culture from the individual development attitude of the team members to that of working in the team. From a non-customer centric to a customer-centric approach (Misra et al., 2010).

2.10.2 People Related to Issues Agile methodologies require cooperation by collaboration, coordination, and communication between team members who value and trust each other. It requires the collaboration of cross- functional teams. People related issues also involve training and coaching of employees to make them empowered and gain sufficient knowledge about Agile. Team members must be self-

motivated to make continuous changes. Team members must be set up for the accountability of the work instead of the managers who need to be set back (Nerur et al., 2005). As required, they should develop the habit of collectively owning solutions and earn the trust of customers and stakeholders (Misra et al., 2010).

In an Agile environment, the development team and the customers make most of the decisions. It makes the decision difficult because of the pluralistic decision-making environment caused due to diverse background, attitude, and goals of team members. Decision-making in an Agile environment becomes difficult compared to the traditional approach where managers are responsible for most of the decision making (Nerur et al., 2005). Decision-making shifts from the individual and centralized to decentralized and shared that causes coordination problems. Moreover, the success of Agile development lies in the customers who are willing to participate in the development process actively. Changes in the attitude of customers are required, such as trusting the development team and negotiating when required (Misra et al., 2010). Customers are required to be knowledgeable, collaborative, and committed.

2.10.3 Process related Issues Changes from heavy process-centric to short iterative people-centric. A change from life-cycle based development to feature driven evolutionary and iterative development (Misra et al., 2010). Traditional processes are compliance-driven and activities and measurement-based for providing assurance. Agile methodology hinges on speculation, planning as everything is uncertain. They stress on assuming rather than measuring and are highly tolerant of change. The idea to move from a life-cycle model to the one that supports feature-based development using iterative and evolutionary requires a significant investment of time, effort, and capital. It requires alteration to tools and techniques, problem-solving strategies, and communication channels (Nerur et al., 2005).

2.10.4 Technology (Tools and Techniques) A aa a a a significant impact on the efforts to migrate to Agile methodology. Organizations planning to adopt Agile methodology must invest in tools that facilitate and support iterative development and other Agile techniques. People must also be trained to use these tools and technologies effectively.

From the theoretical framework, we can make out that some challenges mentioned in the systematic literature review might be associated with the general organizational transformation issues, where some are Agile specific transformational issues (Nerur et al., 2005).

Change Resistance General organizational transformation Issue

Lack of Investment General organizational transformation Issue

Coordination Challenges in Multi-Team Agile specific transformation issue Environment

Different approaches emerge in multi- Agile specific transformation issue team environment

Integrating non-development challenges Agile specific transformation issue

Table 1. The challenges to General organizational and Agile specific transformation issue

2.11 Change Process Models to bring about the Organizational Transformation In the previous section, we have mentioned certain elements that are crucial to bringing about the transformational process. However, as the transformational process is a change activity, it is done in a series of steps incorporating the elements mentioned above. The change process models provide a roadmap to follow for implementing and designing future state. They guide what to do and in what order to accomplish the change. (Anderson & Ackerman Anderson, 2001). We will be discussing the two-process model. First by Kotter and the second one by Kurt Lewin.

2.11.1 Koers model As per Kotter, the transformational process or change process goes through a series of steps that usually requires a considerable length of time. A holistic and consistent approach should aa a . (K, 1995 & K, 2012). K M emphasizes the importance of elements of the management system, the behavioral system, and

the social system such as leadership, culture, vision & goal, motivation, and communication style.

1. Creating a sense of urgency: Aggressive cooperation of many individuals is required to get the transformational process started. The individuals need to be motivated to direct their efforts towards the change process. Establishing a sense of emergency helps others to see the need for the change that fosters cooperation to drive the transformational process. A high sense of urgency helps in guiding coalition together within the managerial rank. As per Kotter, more than 50% of organizations failed in the first phase as executives failed to estimate the effort required to pull the people out of their comfort zones.

2. Creating a powerful enough guiding coalition: A minimum mass effort requires in the early phases of the transformational process. The transformation process is brought about by mutual effort, and a powerful coalition of competent people leads it. This mass effort should be carried out in early phases; if not, it can lead to failure. In a successful transformation chairman or division general manager in addition to another 15 or 50 people form a coalition and develop a shared commitment to excellent performance. As per Kotter in successful transformation cases, a coalition is always powerful in terms of titles, expertise, reputation, and relationships. Companies usually fail in this phase as they underestimate the difficulties in bringing change management as well as the importance of a powerful coalition. Efforts without a powerful coalition eventually hinder and stop the process of change.

3. Lacking a vision: A vision clarifies the direction an organization needs to move. A vision is the picture of a future that is easy to communicate to customers, stakeholders, and employees. Without a sensible vision, transformation efforts can fail and dissolve into a list of incompatible and confusing projects that can take the organizations in the wrong direction. A failed transformation has a lot of plans and directives but no clear vision. In less successful cases, organizations have a sense of direction, but it is too a b . K a a a a someone in five minutes or less and get a reaction that signifies both understanding and , a a aa .

4. Communicating the vision: Transformation is possible only with the involvement of hundreds or thousands of people who are willing to help, to the point of making short- term sacrifices. With a credible communication, employees get to believe that the user change is possible. Kotter states that in more successful transformation efforts, executives use all possible communication channels to broadcast the vision. They turn the ritualistic and tedious quarterly meetings into exciting discussions of the transformation.

5. Empowering actions and Removing obstacles to the new vision: A guiding coalition empowers people to act by successfully communicating the new direction, but at times only the successful communication is not enough. Obstacles need to remove, which may be the organizational structure: narrow job categories, inadequate compensation, or performance appraisals. In the starting phases of the transformation processes, no organizations have the time to get rid of all the obstacles. However, the big one needs to confront and removed.

6. Systematically planning and creating short wins: The transformations process is a mammoth task and requires time. If there are no short-term goals to meet, there is a risk the change process loses momentum. In a successful transformation, managers sought out ways to obtain performance improvements. They set goals in the yearly planning system, achieve the objectives, and reward the people involved with some kind of recognition. Kotter argues that short-term wins help to keep up the urgency level, and pressure to achieve the short-term wins can be a useful element in the change effort.

7. Declaring victory not so soon and consolidate change: Hard work vested in the transformation process might tempt the managers to declare the victory soon after the first definite performance improvement. However, Kotter is of the view that celebrating the win is fine, but declaring the war won until the change sinks deep into a company´s culture, can be catastrophic. He feels that instead of declaring victory, leaders use the success of short-term wins to tackle even more significant problems.

8. Anchor changes in the organization culture: Change persists in the organization aa ba. U a ba are deep-rooted in shared values and company culture, they are prone to degrade as soon

as the pressure for the change is removed. Kotter mentioned two factors that a a a aa .

a. The first factor is an attempt to show people how the new culture has helped to improve performance. The change, when percolated through effective communication, is long-lasting.

b. The second factor is to make sure that the next generation top executives personify and imbibe the new approach.

2.11.2 The Kurt Lewin Model of Change: A model of change is designed by Kurt Lewin (Lewin, 1951). He recognized three stages in the change process.

1. Unfreeze: The first phase is when an organization prepares itself for the change process by looking at its internal and external environment challenges and changes. Organizations challenge current practices and strive to take actions that can lead them in the right direction. For this phase, a sense of urgency is developed within the organization. A proper coalition and vision to ensure the organization is heading towards the right direction regarding their transformation process.

2. Transition / Moving Phase: It is when the organization implements the appropriate programs. It develops a program that is required for the transformation agenda to be implemented effectively. It involves the training and coaching of the employees and develops new behaviors and attitudes for the individuals, departments, and the entire corporation.

3. Refreezing: The steps take the organization towards a new level of equilibrium. It brings stability in the organization through reinforcing the new organizational state, such as organizational culture, rewards, and structures. The three steps described in the Lewin model of change are quite broad. Even though Lewin's model of change is older a K , L a a be mapped to the Kotter´s eight steps towards the transformation process. We are mapping the new model to show the similarity in thoughts between the two models.

Koers model of transformation process Leins model of ransformaion process Creating the sense of urgency Unfreeze Creating the guiding coalition Developing the vision Communicating the vision Empowering broad-based actions Moving Generate short terms win Consolidate gains Refreeze Anchoring changes in the organization culture

Tab 2. Pa K a L aa

From our perspective, Kotter's and Lewin's model rely on human transformation, and they do not focus on business content or design requirement, i.e. it does not mention the analysis of the current state of organization requirement before proceeding for change. Even Anderson & Ackerman Anderson, in their analysis, found that current process models such as Kotter and Lewin provide a partial picture of the transformation requirement. They suggest a nine-step process model that overcome some of the problems in Lewin's and Kotter's model. We are of a a a K a aa for assessing the current state to determine the design requirements. However, Anderson & Ackerman are aware that the transformation journey is full of uncertainties and not a straight line and that the change process model should be customized as per organization requirements (Anderson & Ackerman Anderson, 2001).

Figure 6. The customized Change process model

3 Methodology

This thesis is based on empirical research and scientific approach, and the research process is based on two main steps. The first step is to define the method used for our scientific approach, which is an abductive study, and the second step is the method used for our data collection of empirical studies, which is semi-structured interviews. Additionally, the validation of methods used in this research, both internal and external validation, is being considered, but also the reliability part of it by using the principles of trustworthiness and the technique of respondent validation. The qualitative research has some drawbacks in both validity and reliability, according to Guba and Lincoln (1994); therefore, the criteria of trustworthiness will help the research validation and reliability. Moreover, some ethical considerations are added to the methodology. The ethical principles considered for this research are the consent of participation, transparency of information, utilization of data, and demand of confidentiality

3.1 Abductive Study Abductive studies are a combination of both inductive and deductive. The approach is to involve research strategies and a mix of theories (Alvesson & Sköldberg, 2008), i.e., the authors of this thesis move among empirical data and theories in order to have a better comprehension of the subject over time. Deductive studies aim to test the theories with empirical data. On the other front, inductive studies aim to generate or create theories based on empirical studies (Bryman & Nilsson, 2011). On the contrary, abductive studies consider new interpretations or observations throughout the study. Additionally, there are many research studies about the implementation of Lean-Agile or similar with highlights about obstacles found during the time of implementation of a new framework. Therefore, in order to analyze the themes of SAFe, we needed to understand the theories of SAFe and its implementation roadmap, as well as the empirical data gathered through interviews; therefore, an abductive study is more suitable for this thesis.

3.2 Semi-structured interviews Semi-structured interviews are one of the most commonly used methods in qualitative research, and it is because of the flexibility it has by adjusting or addressing the questions to different situations. Since the interviews are conducted face to face, it allows respondents to feel freer when answering questions, letting the authors focus more on the participants' opinions, experiences, and feelings. Moreover, it can give more insights into what is considered to be more relevant or essential to the main research questions (Bryman & Nilsson, 2011).

The interview questions might differ between the participants. Therefore, we generated a guiding template to adjust the questions according to the situations, and the main area that is investigated. The interviews have been conducted with one participant at a time. Meanwhile, one of the authors ask the questions, and the other one takes notes and adjusts the tools for recording the interviews. The approach is to use the same performance on every interview and focus on the sampling of the respondents without the intended structure.

3.3 Selection of participants The participants have been selected through a meet-up community, where people share their experiences about the SAFe framework. The participant experiences were both in the implementation phase, and also just working on the framework. The people selected for interviews are people that have been working within the framework and have around one to five years of experience. We considered the participants' experience before we chose them to participate in the interviews. Their background was the most interesting factor because the participants have been working before on a more conventional Agile way of working and now working on SAFe. Therefore, the participants that have been chosen for the interviews have been valuable for this research, because they have knowledge about working within two different frameworks. During the interviews, we asked each interviewee about their knowledge concerning both frameworks. The intentions were to understand if the participants had the necessary knowledge about both frameworks and especially about SAFe, and this was checked by letting the participants explain how they think SAFe structure works. The table below shows an overview of the participants' background and their experiences working on the levels of SAFe.

Years of Experiences of Industry Participants Current title SAFe working on SAFe working experience level

A Tester Banking 2 Team Level

Software Team Level and B Scrum Master 3 development Program Level All the levels as a C SPCT trainer IT 3 trainer Software D Developer 2 Team level development Product Team Level and E IT 4 Owner Program Level Product F Banking 2 Team level Owner All Levels as a G Agile coach IT 5 coach

H Manager IT 1 Program Level

I Developer IT 2 Team Level

Table 3. Overview of the interview participants

We have also used the snowball sampling method, which consists of contacting a smaller number of people who are significant to the thesis' study in order to later get in touch with additional people (Bryman & Bell, 2011). In fact, in this community, the authors were able to contact four people who, in the end, resulted in being the ones to introduce even more people that would like to participate in the interviews. In this thesis work, the total amount of participants was nine people. One of the weaknesses in the selection of participants was the years of experience. SAFe is still new for many companies or enterprises; therefore, there is a lack of even more experienced people, but this can be achieved in the future. So far, we tried to be as reliable as possible by choosing the correct participants and as well as choosing the correct sources for the data gathered for the whole thesis.

3.4 Validity and Reliability For the validation of the methods used in this area, both internal and external validation has been considered. Internal validity is a property of scientific studies or research that usually reflects a causal conclusion that is based on the warranty of the study (Bryman & Nilsson, 2011). The mentioned warranty is about reducing bias on the extent of a study. Therefore, we have tried to be as unbiased as possible when it comes to the interpretation of the data collected during interviews or conclusions that supports this thesis work. In fact, in order to remain unbiased, we interviewed people with different backgrounds and experiences and let the interviewees review their statements and findings during the interviews.

On the contrary, external validity is about the measurement of general conclusions that can be deduced from the conducted study (Bryman & Nilsson, 2011), i.e., it is about the generality of the results obtained in the studies towards other organizations and people. In this study, we focused on studying the hurdles that people have faced, meanwhile SAFe was implemented, and there is no focus on organizations at all. Therefore, external validity can implicitly be assumed as low.

Since qualitative research has some drawbacks in both validity and reliability, according to Guba and Lincoln (1994), the criteria of trustworthiness will help the research in order to improve the research validity and reliability.

The principles of trustworthiness consist of four different criteria, such as credibility, which parallels internal validity; transferability, which parallels external validity; dependability, which parallels reliability; and confirmability, which parallels objectivity. (Bryman & Bell, 2011).

Credibility: For the credibility of the research, we used the technique of respondent validation. This technique helps to redress the power imbalance between the authors and research by providing the participants with a degree of authority about the writing of the final thesis work account (Bryman & Bell, 2011). We contacted the interviewees in order to relook into the statements written on this thesis work and have the correct statements not to generate contradictions or assumptions that could be made by us as authors of this thesis.

Transferability: The findings of this research can be transferred into other areas besides SAFe implementation. As Guba mentioned before, "hold in some other context, or even in the same context at some other time, is an empirical issue" (Lincoln and Guba, 1985). Therefore, the information demonstrated in this thesis can be applied to other frameworks. It could also be taken into considerations for both new enterprises that would like to implement a new framework or just a group in a company that would like to make changes or use it as empirical findings for future research since the findings are being validated.

Dependability: For the dependability of the research, we audio-recorded the interviews. The authors of this thesis were verifying if the findings were consistent with the data gathered and compared if their interpretation or conclusions were similar in the research or analysis of the data gathered. The findings in this thesis can be applied to future research in the area of SAFe implementation.

Confirmability: For the degree of conformability, we have been as transparent as possible in order not to allow personal values to intrude the findings or conclusions, and not be biased at all. Instead, we intend to be as objective as possible.

3.5 Ethics In this thesis, ethical considerations have been taken. Since this study consists of interviews, there are four different but fundamental principles used for each performed interview. The ethical principles selected for this thesis work are found by Bryman and Nilsson (2011), and those are the following:

Consent of participation: This principle gives the participants the right to decide if the person would like to participate or not in the study.

Transparency of information: This principle allows the respondents to have the right to know the purpose of the study in every single step.

Utilization of data: This principle means that the utilization of the data collected; in this case, the data generated during the interviews, should be used only for the research purpose.

Demand of confidentiality: This principle gives the right to the participants to remain anonymous, and the participants should remain and be treated as confidentially as possible.

In order to highly fulfill the principles mentioned above, we asked the participants if they would like to participate in the interviews. Also, the interviewees were asked for permission, and the purpose of the study has been explained to each participant. Also, a confidential agreement has been signed between both partners, letting the participants know that they will remain anonymous during the whole thesis process, and even after that. One of the reasons why we used those principles for this study is because we wanted the participants to feel free when answering the question and feel secure that they will remain anonymous. If this were not mentioned to the people that have been interviewed, there would probably be a risk, such as thoughts would not come up or leave out some aspects that could matter to the thesis. Also, we tried to be as transparent as possible by focusing on the interviewees' opinions or reflections, and try not to influence the participants by thesis' intentions.

4 Empirical Data

An explanation of all relevant concepts will be described in order to have a better understanding of what SAFe is and how it works. Also, the roadmap of SAFe implementation will be reviewed. Furthermore, the significant data gathered during the interviews will be available in the empirical data section.

4.1 SAFe SAFe is a framework that helps businesses to address challenges of development and deliveries of software and systems in short periods. This framework is based on the first three bodies of knowledge, such as Agile Development, System Thinking, and Lean Product Development. SAFe contributes and facilitates the synchronization of alignments, collaboration, and the association of deliveries of a large number of Agile Teams. Normally, SAFe supports solutions for both complex systems, which require thousands of people as well as for groups of 50 125 practitioners. Therefore, this framework is flexible and can be adjusted according to a company's needs. SAFe has three different levels, such as Team, Program, and Portfolio level. A short introduction of each level will be presented in which the essential facts are reviewed for the readers' understanding. See figure 4 for an understanding of the SAFe structure.

4.1.1 Team Level Teams are the basis of SAFe and Lean enterprises, as they execute the clear majority of the work that carries customer value in the context of Agile Release Train (ART). The team level describes the structure, activities, roles, events, and processes of all Agile teams working towards building solutions. The roles needed for this level working in the context of ART are Agile teams, Development Team, Product Owner, and Scrum Masters. In this level, each team has individual contributors who cover all principal roles to build up the quality of value for each iteration. Every single team is responsible for defining, building, and testing stories from the product backlog that has been assigned by the Product Owner. All the events used in the team level will synchronize and coordinate the activities among the teams that work within the ART. Such events are Iteration Planning, Iteration Review, Iteration Execution, Iteration Retrospective, Backlog Refinement, and Innovation and planning (IP) Iteration.

In this level, the overall capability of an Agile development project is distributed into small and cross-functional teams. The teams will work in synchronized cycles of two weeks in order to deliver software functionality. The benefits of the synchronization are that they can easily coordinate and collaborate on the plan of the releases but also explore dependencies at the program level.

4.1.2 Program Level The program level is the one where development teams, stakeholders, and other resources are dedicated to a system development mission. Although this is called the program level, ARTs are the long-lived having the ultimate responsibility for creating and releasing value inflow at the frequency needed by a company or enterprise to meet the market and customers' demands. It means that all roles and activities in the program level need to deliver solutions through an ART continuously. All ARTs are virtual organizations designed to span functional boundaries, eliminate wastes, and accelerate value delivery by applying SAFe Lean-Agile principles and practices. Also, the practices and mindsets of this level contribute to a company's competency of DevOps and release on demand. The roles needed in the program level for guidance and direction of the ART are Product Management, System Architect/Engineer, Release Train Engineer (RTE), and Business Owners.

The core activities that help the coordination of the ART in the program level are the PI planning, System Demo, and Inspect & Adapt. All stakeholders involved in the program level meet periodically in order to ensure that the ART is progressing toward the devoted PI objectives, but also to manage risks and dependencies. Those meetings are for synchronization in which are including Scrum-of Scrum, where the RTE and Scrum Masters participate, PO Sync, where the Product Management and POs are involved, and also the ART sync, where both the PO Sync and Scrum-of-Scrum synchronize together.

4.1.3 Portfolio Level The portfolio level is the highest level of SAFe. There can be multiple portfolios in a company, but each portfolio defines its value stream and solution. The company's strategy drives the portfolio strategy. People in charge of these portfolios report to the people responsible for designing the company's strategy. This final segment provides a mechanism for predictability and visibility of deliveries and the project's roadmap goals. This is the level that sends the

visions and strategic guidance that the program level needs. The roles needed in this level are the Program Portfolio Management (PPM), Epic Owners, Enterprise Architecture, Portfolio Kanban system Overview.

The required elements in the SAFe portfolio are the value stream, Lean Budget, Product Kanban system, Epics, Portfolio Backlog, and strategic Topic. This portfolio level sees the organization's strategy as an investment topic. Usually, the management roles are the ones that review each investment topic and also allocate the budget and resources to each theme, depending on the expected return of the investment and strategy. To sum up, the project backlog is the one that compiles all development items that are being initiated, and those can be extended over multiple releases. Therefore, a Kanban-style approach is necessary to control the work in progress, manage the flow of work, and optimize the capability.

4.2 SAFe Implementation Roadmap

Figure 7. SAFe implementation Roadmap. (Leffingwell, 2011)

The implementation roadmap of SAFe consists of 12 different articles that describe a set of activities and strategies that, according to Leffingwell, are proven to be efficient in implementing SAFe successfully. See figure 7.

In order to achieve this implementation, enterprises must embrace Lean-Agile Mindset but also understand the Lean-Agile principles. Furthermore, enterprises must identify value streams, ARTs, build quality in continuous value delivery and DevOps, and of course, the culture must evolve as well.

Leffingwell mentions that the SAFe implementation roadmap is based on proven organizational management strategies. Therefore, the graphic showed above, and the articles series describes the steps that a company or enterprise takes in order to implement SAFe in a reliable, orderly, and successful fashion. However, there are some points to have in mind; first, it is not the only way to roll out SAFe, this has to be seen as a suggestion of a pattern guide because the important part of it is the intention of how it implements. Secondly, SAFe transformation is a large-scale change, and this must be managed continuously because there are many pitfalls to be aware of lengthwise. The importance of each step will be reviewed accordingly.

4.2.1 Reaching the Tipping Point It describes the need for a change of an enterprise, and it is the first article in the process of the SAFe implementation roadmap. Before starting a change effort, the organization must clarify the impetus for change. For instance, a general acknowledgment to the employees about improving the way of working since it is inadequate for delivering the performance needed at the moment and in the future. Usually, an organization falls into one of the two categories. One of the categories is the burning platforms, which means that an organization is failing to compete against other organizations, and the current way of working for doing business is not producing the desired results. The other category is the proactive leadership in which an organization is seeking for continual improvements.

The "Tipping Point" means the point in which an organization's need is to achieve the change, rather than resist it (Gladwell, 2002). Kotter (2012) mentions that a "vision for change" is a core responsibility of leadership. Therefore, organizations might reach this by establishing a vision for change with the following three key benefits. In other words, the tipping point is just the beginning of the whole implementation process, and it is about forming a guiding coalition.

Kotter mentioned that a powerful guiding coalition should accompany a clear vision in order to carry the vision forward (Kotter, 2012).

4.2.2 Train Lean-Agile Change Agents After reaching the tipping point, the hard work begins with the second article. It means that there is a need for a powerful coalition. This article aims to introduce a process that will develop people having the knowledge, skills, and resources needed in order to implement SAFe successfully.

To be effective with the coalition, it will require leaders that can help the organization by setting up the vision, showing the way, and also removing impediments to the change. Moreover, there is a need for practitioners, change agents and managers who can execute specific process changes. Also, it will be necessary to achieve sufficiently organizational credibility in order to be taken seriously, and together with it, have the necessary expertise to make the changes fast with smart decisions. Therefore, in order to create a SAFe coalition, there is a need for training Lean-Agile change Agents, Executives, Managers and Leaders, and Lean-Agile Excellence (LACE).

4.2.3 Train Executives, Managers, and Leaders As mentioned before, the second article emphasizes the need for having many stakeholders and executives to ignite the transformation. Some of the leaders will be involved in the ongoing support for the change by participating in the LACE. However, some other will be involved in the implementation itself, or be managing, leading, and influencing other stakeholders in the transformation. Also, their roles will include direct participation in launching ARTs or working on eliminating impediments that might arise in the enterprise's current governance, practices, and culture. Leaders and managers might exhibit the Lean Agile-Mindset, which includes, Lean thinking which is based on the SAFe House of Lean (See figure 8) and embracing agility. Therefore, without strong and active participation from the managers and leaders, the change will take a longer time and even be less successful than it should be. However, the leaders and managers should implement into the organization the SAFe Lean-Agile principles (See figure 9).

Figure 8. The SAFe House of Lean

Figure 9. SAFe Lean-Agile Principles. (Leffingwell, 2011)

4.2.4 Create a Lean-Agile Center of Excellence LACE is a small group of people who compose a team in which their primary task is the implementation of SAFe way of working and empower to do so. It is the third element for the

creation of a powerful guiding coalition. The size of a team will vary according to the organization's size, as Kotter mentioned, "The size of an effective coalition seems to be related to the size of the organization (Kotter, 2012). Change often starts with just two or three people. The group in successful transformations then grows to half a dozen in relatively small firms or small units of larger firms." However, it is recommended to have a group of four to six dedicated people. They will manage to support a hundred practitioners. Though, their responsibilities are generally shared with numerous SPCs that probably might or might not be part of the LACE.

4.2.5 Identify Value Streams and ARTs The The articles before established the urgency for change, and now with a sense of its urgency and the powerful coalition in place, it is the time to start implementing SAFe. First of all, it is necessary to point out that there are two types of value streams. One is the Operational Value streams, which are used to deliver end customer value, and the second value is the Development value streams, which is used to build the systems and capabilities that enable operational Value streams.

However, the company's operational value streams have to be identified to determine the development value streams that support them. The identification of value streams and ARTs requires the understanding of a new organizational model, which is optimized to simplify the activities, flow of value within functional silos, and boundaries.

The ARTs design will depend on the number of people that do the work; however, there are three different scenarios (See figure 10) which are the following:

Multiple development value streams can fit within a single ART A single development value stream can fit within an ART Multiple ARTs are required for large development value streams

Figure 10. Three possible scenarios for ART Design. (Leffingwell, 2011)

4.2.6 Create the implementation Plan Now it is time to create a plan. For the creation of the plan it is required to firstly, pick up the first value stream, by picking one target will the company be allowed to put the effort of their newly trained SPCs and leaders to focus on a specific starting point for the SAFe implementation. Secondly, is the selection of the first ART, this will generate knowledge that might apply to other ARTs. The idea is finding an opportunistic ART (See figure 11). Thirdly, there is a need to create a preliminary plan for additional ARTs and value streams. The focus of this article is about beginning a planning process using an Agile mindset. However, the idea is to plan enough in order to get started and learn by doing.

Figure 11. Finding an opportunistic ART

4.2.7 Prepare for ART Launch Now is time for the execution of all necessary activities in order to create a successful ART launch. The SPCs are responsible for the execution because they will lead the implementation and the initiation of the ARTs. However, the SPCs should be supported by the stakeholders that are SAFe-trained, and also received the collaboration of the LACE's members. Since it is crucial for the change-management to start the first ART launch, it will require some activities to follow. The activities that define the ART are:

set a launch date and cadence for the program, train the ART leaders and stakeholders, Project Managers, Product Owners, Scrum Masters, System Architects, Engineers, Establish Agile teams, Asses and evolve launch readiness and prepare the program backlog.

The most challenging activity is the preparation of the Program Backlog. This program backlog defines the scope of the PI, and it includes the set of upcoming features, nonfunctional requirements, and architectural work that will define the future needs of the system. Therefore, the SPC and stakeholders usually meet together in for the ART in order to prepare a common

backlog, in which they divide it in series of backlogs together with other activities (see figure 12).

Figure 12. Preparing the Program backlog and related activities (Leffingwell, 2011)

4.2.8 Train Teams and Launch the ART Agile teams are essential to SAFe because they constitute most of the ART members, and they are the ones that build the systems that are needed by the business. Therefore, those people must know what actions are going to happen in the business and give them knowledge about the SAFe way of working. The training is vital for the teams because they will provide coaching that goes beyond the way of working on Scrum practices. There are many ways to start the launching of the ARTS, and there is no specific cadence for readiness activities, as we have described in the past articles. However, there is a recommended way of doing it. Below explains the ART Quickstart elements approach:

Day 1 2 The Agile team's big room training takes place, as described above. Day 3 4 Team training is followed immediately by PI planning. This way, the teams are still present and in context, and their first PI planning experience builds on the priority day's training.

Day 5 This day is reserved for mentoring people in their new roles, tool training, discussion of needed Agile technical practices, open space, and any other activities that the teams need to get ready for the first iteration.

4.2.9 Coach ART Execution After the execution of the steps before, all teams are trained, and the PI planning is ongoing. However, it does not mean that everything is understood, and the implementation is done. On the contrary, it has just provided the opportunity of becoming Agile. Now it is time for the SPCs and Lean-Agile leaders to coach team-levels and ART-levels in order to deliver value in shortest sustainable cadence while producing the highest quality. Therefore, the coaching at the team levels will focus on mastering the roles and ceremonies of SAFe. It includes Iteration planning, Backlog refinement, Daily stand-ups, Iteration reviews and system demos, iteration retrospectives, and Scrum-of-Scrum, PO SYNC, and ART sync. Therefore, in order to transform the ART into engaged, empowered, and aligned Agile-teams that will deliver value in short lead-time, there is a need for coaching and support for the ART.

4.2.10 Launch More ARTs and Value Streams The time has come to the next higher gear of the transformation since the company is enabled to consolidate and produce even more change. Now is the time to launch more ARTs and value streams. After the launch of the first ART, a company starts to realize the greater return of its investment, such as higher quality, faster time to market, higher productivity, and the incrementation of employee engagement. In order to launch more ARTs, the pattern should still be the same as the first ART launch: Prepare for ART launch, Train Teams and launch the ART, and finally Coach the ART Execution. However, the company has to think even further, and they have to implement large solutions, roles, artifacts, and events. Large value streams will require a development of the organization's Lean System Engineering Competency, but also some of the additional events, artifact, and inclusive roles of the SAFe Large solution level will be required. Each new value stream will represent the same challenges and opportunities to integrate all the change management steps that have been described so far, from Identify Value streams and ARTs to Coach ART execution.

4.2.11 Extend to the portfolio Now, it is time to expand the implementation in order to include maturity in the company's Lean Portfolio Management competency and also anchoring a new approach in the culture. The past article has already described how the leaders facilitate and drive the implementation of SAFe. Also, by the success of the last article mentioned above, it created a buzz in the organization concerning the new way of working. Therefore, the more ARTs are launched, the more demands are added in the portfolio, and this needs to be accommodated and enhanced for the new way of delivering value.

This is the point when the Lean-Agile leadership is the most important of the competencies that have to be active in order to address those remaining legacy challenges. The mindset will evolve with training and engagement in implementing SAFe, and it will lead to changes as the example given in figure 13.

Figure 13. Evolving traditional mindset to Lean-Agile Thinking (Leffingwell, 2011)

4.2.12 Maintain and Sustain At this moment, almost all the stakeholders have been trained. The ARTs and value streams have been transformed and are delivering value. The new way of operating is becoming part of the culture that has been embraced from the Team level up to the Portfolio Level. Therefore, this last step is the beginning of a new journey with relentless improvement. Now, the company started to operate with the new way of working in which relentless improvements are beginning to be the norm. However, a company cannot give it for granted. Sustaining and improving requires dedication to the primary and advanced levels of practices, self-reflection, and also

retrospection. Therefore, in order to ensure relentless improvements, some activities within the company need to be performed. Those activities are the following:

Foster relentless improvement and the Lean-Agile Mindset Implement Agile HR practices Advance program execution and servant leadership skills Measure and take action Improve Agile technical practices Focus on Agile Architecture Improve DevOps and continuous delivery capability Reduce time-to-market with value stream mapping

5 Results and Data generated during the interviews

This section summarizes the interview findings of what was said by the interviewees regarding SAFe. Excerpts from the interviewees have been consolidated to give the readers an overview of the interviewees' perceptions about the challenges and success factors related to SAFe.

The interviews performed in this research are semi-structured, and those meetings had some basic questions that helped us to follow up on the subject but also to have a more fluent conversation in order to gather relevant data for the perception of the interviewees about SAFe. As mentioned before, we interviewed nine people, and each was interviewed alone within 90 minutes.

The interviewees are people experienced in working on SAFe. They all have different positions and experiences of working on SAFe, and they all work in different companies. Almost three- fourth of the interviewees have experience working on large-scale projects involving SAFe. However, all the participants worked in a software development environment. Below, we will post the relevant statements that have been said by the interviewees, which was about the implementation of SAFe and their own perception of this framework. Excerpts from the interview mainly mentioned are the challenges.

Our interview questions were related to SAFe levels, challenges, and success factors relevant to SAFe. In this section, we will mention the response we received Regarding SAFe levels and the Challenges and Success factors combined.

5.1 SAFe levels: In our interview, we asked interviewees about the SAFe levels and at what levels they are currently working or have worked.

1. Team level: All the interviewees agreed that team level is the most basic level, and that is primarily applied. They said that Scrum is the most common Agile framework applied at this level. However, other teams, as per their organization setting, can also apply another framework such as Kanban or XP. As per person H, Manager, said:

"Consider team level as one Agile team. There can be Multiple Agile teams in an ART that requires coordination and synchronization between them."

2. Program Level: Interviewees told that this level is used in their organization. As person G, Agile coach, mentioned: "Think of program level as an ART consisting of multiple Agile teams." The critical role identified at this level is the Release Train Engineer (RTE), System Architect, and Product Manager. All the interviewees agreed that PI planning, Inspect & adapt, and system demo is carried out regularly to assist in the coordination of ARTs. However, few interviews told that they use the Kanban process at this level while others told that they use Scrum at this level too. The majority of interviewees felt satisfied with the SAFe framework. We got an idea from the interview that among the basic level of SAFe, the program level has a more complex setting and bigger dependencies than the team level. Pair programming used at the team level is less complicated than the activities at the program level, such as PI planning that deals with organizing the bigger event with multiple teams at different locations (Leffingwell,2011).

3. Value-Stream Level: Interviewees mentioned that this level is optional. Person F, Product Owner, mentioned that the value-stream level is applied in his organization, while person D, Developer, said that this is not applied in his organization. Person F, Product Owner, said: "When an organization is large and requires multiple ARTs, practitioners and suppliers, then an additional level is a good way to synchronize multiple ARTs and suppliers."

4. Portfolio Level: Interviewees did not give much information about this level. Some said that this level is not applied in their organization yet. Person F, Product Owner, mentioned that this level organizes the lean-agile enterprise flow of value through one or more value streams. We got an idea that this level is generally not applied at the beginning of SAFe transformation. It is only applied when SAFe implementation has become mature in the organization with the basic teams and program level in place and fully implemented in the organization.

SAFe Levels applied in Organizations Agile methods used

Portfolio level Still not applied in most of the Kanban organization.

Value stream Only applied in large organizations with Kanban level multiple ARTs (Optional).

Program level Always applied in Organizations. Kanban, scrum.

Team level Always applied in Organizations. Kanban, Scrum, XP.

Table 4. Overview of the levels applied in the organization and the methods used on each level

During the interviewees, we received the responses as per the experiences of the interviewees. The authors of this thesis have tried to sum up the main findings into the Six major relevant categories. The responses received are interrelated, and the Six categories are also closely interrelated. Moreover, we have not categorized the responses as challenges and success factors as many topics related to the success factor and Challenges mentioned in these categories are interrelated. We have just mentioned a few excerpts from the interviews to give the reader an idea of how our interview proceeded.

5.2 Challenges and Success Factors combined 1. Change resistance: Almost two-thirds of the interviewees talked about the resistance faced in some or another form. Some interviewees said that it was due to cultural change, i.e., shifting from control and competence to a more flexible and collaborative way of working, and people were reluctant to change their way of working. Person G, Agile coach, said: "Well I guess failure in SAFe transformation was due to cultural issues. Organizations are based on control and competence culture, while Agile and scaled Agile requires cooperation. Often the problem is not people's culture but the organization's culture". The results pointed to the fact that shifting from the waterfall model to SAFe required change in the organization culture and much learning, compared to the situation, here an organization has already adopted the Agile way of working

in some or another form. Person C, SPCT Trainer, mentioned: "When the organization is working with Agile, it is easier to switch to SAFe, compared when an organization works on the Waterfall framework because a culture changes and much learning is required." Interviewees also mentioned that people are not eager to learn new things, especially if employees have expertise in an area that is threatened to be replaced when implementing SAFe. Person A, Tester, said: "I could never understand the reasons why we are moving into a new way of working. This cost us a lot of time, and I feel like in the way we were working were good already, and we deliver results." Person B, Scrum master: "Teams normally work in fashion time. However, some group members still worked with the old structure but still delivered on time". Also, the authors figured out during the interview that resistance was faced because people had no idea about the benefits and workings of SAFe. As per person C, SPCT trainer: "I have noticed that great efforts are invested without well-stated objective and motivation. There is a lack of employee involvement, lack of training and coaching through the effort. Senior management as change agents generally are not educated and experience in the change management process. Thus, it is better to hire a SAFe coach with change management experience or expertise".

The last comment pinpointed the problem of lack of motivation from the senior management and lack of training and coaching. Interviewees agreed that enthusiasm and motivation by senior management and proper SAFe education played a huge role in mitigating resistance. The Senior management should try to identify the underlying reasons, perhaps through a Q&A session, that is causing the resistance and try to have a dialogue with the employees to understand their perspective and try to resolve the occurring conflicts. Person G, Agile coach, mentioned: "I met managers and leaders that were confused about the goals and processes of the way of working in SAFe. It was good to have many meetings, and workshops together were they easily ask questions about the processes and how to go over the challenges that emerge in a group. Also, we encourage them to continuously advise the groups about the challenges and let them know what has to be fixed and what has been fixed". Interviewees also mentioned that resistance sometimes occurs due to genuine concern by the employees regarding the suitability of the new change initiative for the organization. Some interviewees suggested that piloting this framework in a small project and then implementing it throughout the organization can mitigate this type of resistance. Person C, SPCT Trainer "Some companies did not PILOT this framework before and just decided to implement it without testing it first and probably not even explaining to employees why this new framework is good."

2. Role of Executives in SAFe transformation The majority of the interviewees talked about the role of executives. However, the definition of the Executives seemed to be unclear. Every interviewee had different terminology for the executives, but when the interviewees have been asked about the terminology, we figured out that they were referring to senior-level managers, change agents, or leaders of the change management process. Kotter describes executives as senior managers who have the power, and are the key players in bringing about the change. They are the ones reducing the forces of inertia (Kotter, 2012). Senior management has the onus to lead the change, to provide proper education and communication to the middle-level management, low-level employees, and to lead the change to move away from control and command to more self-organizing teams. Person C, SPCT trainer, said: "Executives should be able to obtain resources and funding for the implementation process. They should be able to communicate properly about the SAFe initiative and why it is good for the organization. There is a need to manage resistance among senior and middle management and eventually mitigate resistance across teams. Executives should provide education and coaching at all levels". Interviewees were unequivocal about the fact of the senior managers' nonchalant attitude, and their insufficient knowledge about the SAFe ideology and framework can pose a severe challenge in the implementation of SAFe. Person I, Developer, mentioned: "Sometimes due to improper management, employees are reluctant to speak about challenges and issues they face in the implementing the transformation." Person I, Developer, said: "I do understand the new framework but still do not know what the purpose of the change is. I talked to my manager to support me in that by giving me a better explanation, but it seems that my manager does not have the necessary knowledge or skills to explain it better."

3. Training and coaching Almost three-fourth of the interviewees talked about the importance of training and coaching. They were of the view that any organizational transformation requires training and education for the people, and there should be unified coaching across all the levels to ensure common direction in SAFe implementation. Person E, Product owner, said: "Implementing SAFe is also a change management process. You need to educate, motivate, inspire, and transform. SAFe deployment can be treated as a change management project. It provides visibility and importance to SAFe within the organization. Adding objective and motivation add clarity to SAFe deployment". They talked about how organizations sometimes are reluctant to invest in the most critical aspects of bringing out the change process. Person D, Developer, stated: "It is

important to invest in training as it makes people more comprehensive. If one person does not know SAFe or its framework, the person can be a real stopper for the project". It can be inferred that training and coaching is one of the ways resistance could be minimized. Training can be the way to gain the trust of employees in the organization regarding the change process. Training can also be used to receive feedback and opinions of the employees about the change process. This process can also mitigate the risk of implementing a transformation process that can be detrimental to the organization. However, above all, the success of training and coaching initiatives depends on the willingness of the people coached, whether the employees are willing enough to take up the training sessions. This willingness factor needs consideration and further exploration of how there can be some evaluation and processes to increase people willing to learn.

4. SAFe / Agile Mindset Interviewees stressed on having a proper mindset. However, the term mindset can be interpreted in many ways, and it is dubious about defining the mindset. The responses received during the interviews indicate that mindset can be interpreted as to not only being in the state of Agile but also having an understanding of the Agile principles in general. Interviewees were of the view that the Agile mindset is not only to do "Agile" but also be "Agile" to achieve true SAFe benefits. The Agile mindset can be related to the Agile twelve principle we have mentioned above in theory. Person C, SPCT trainer, responded: "When I think about the Agile mindset, I think of the Agile principles to realize what the mindset refers to." Interviewees admitted that changing the people's mindset is quite tricky because it requires the process of believing and internalizing the change. Person H, Manager, replied: "SAFe implementation needs change in the people mindset, that causes them to resist the change. Lack of motivation and knowledge makes employees indifferent to change. Agile coaches should pay attention to these people. I feel that resistance to change is a challenge, but this is a problem encountered".

Person B, Scrum Master: "I have analyzed that sometimes there is a lack of enthusiasm among the team for deploying SAFe in the project. People do not want to change. Some employees do not even have sufficient knowledge about SAFe principles and its advantages."

This finding of the mindset is also closely related to the other findings mentioned above. Almost 60% of the interviewees stated that a proper mindset is required for the successful implementation of SAFe. Training and coaching develop the Agile/SAFe mindset and leads

everyone to have a common understanding of SAFe and its principles. Person C, SPCT trainer, answered: "I believe proper education and awareness about the change process can help an organization to align the people's mindset with the organization goal. In the case of SAFe implementation, I have noticed that normally, everything goes as planned during the workshops we provide to the employees. All the time, we try to explain the way of working and how to overcome challenges that might arise during the implementation. The problem is that sometimes, people just do not ask questions or leaders, and managers could not attend the workshop because of other reasons, and that might influence the implementation because they do not know how to act in certain situations."

The role of executives here is vital in guiding and motivating people in guiding their mindset in the right direction. Person A, Tester, declared: "Managers are not interested in relinquishing their power. They think command and control are excellent for managing work."

Even too large extent resistance is caused when people do not have the right knowledge and understanding of the SAFe principles and values, which causes them to be indifferent to change. Person H, Manager, stated: "Some employees preferred to have a leader that controls them, they are afraid of going wrong. I feel this mindset is contradictory to the Agile or SAFe approach."

5. Communication & Coordination issues The interviewees stressed upon the coordination problems emanated from the multi-team environment in SAFe. This problem is specific to SAFe because there are multiple teams at various levels and also distributed teams (where teams are dispersed rather being collocated). Person B, Scrum Master, remarked: "It is difficult to coordinate the ART because many inputs come from different perspectives, and everyone wants to prioritize their own needs or activities."

Agile methodology is implemented in small teams, but in SAFe, when several teams have to cooperate in a project, the communication and coordination problems elevate. Person G, Agile Coach, said: "Sometimes a lot of miscommunication occurs due to insufficient knowledge at different levels. SAFe operates in a Multi-team environment, and this causes a lot of challenges in coordination and communication. Employees need to know the updates, as you know, SAFe

involves multiple teams and different levels where information trickles down from the top. Therefore, a plan for continuous communication at different levels is important."

Interviewees stated that coordination problems in a Multi-team environment were not a problem when they were working with Agile methodologies in small teams. However, when the organization implemented SAFe, the coordination problem arises. Person E, Product owner, mentioned: "What we need to do is collective planning. SAFe brings complexity in terms of multiple interdependent teams that work for a common goal, and interdependent teams coordination becomes important. So, if you really want to deliver an end-to-end process, you need to align different teams and collaboratively plan their development. This, I would say, is something tricky and hard."

Interviewees emphasized that communicating the new vision and objective is a crucial thing in successful SAFe implementation. Two-Third of interviewees agreed that there is insufficient communication either regarding the information on the change or how it will be conducted. The communication problem emanated mainly due to a lack of information and understanding of the SAFe framework at different levels. Person F, Product Owner, claimed: "One of the problems is that communication is not proper, and the information is not dissipated efficiently. For instance, I have noticed that information and training sessions are often dedicated to IT or other technical teams, and less information flew down to the business side". One of the interviewees told us how some teams in a distributed setting still cling to the Waterfall model while claiming to be working with SAFe methodology.

The problem is also due to the lack of management support because interviewees mentioned that it was a management responsibility to train everyone involved in a project dealing with the SAFe framework. Interviewees stated the communication should consist of a two-way process, where coaches and executives should educate people about the SAFe framework and allow people to give their feedback on how they feel about the framework. As John Kotter stated for the transformation to be successful most of the people need to understand the change, it can be said that communication problem could be alleviated by proper educating different people involved in the SAFe processes.

6. Tools and processes for Agile / SAFe: Some interviewees pointed out the fact that there are situations when organizations do not have proper tools and processes to manage SAFe, to support rapid releases and delivery. Person F, Product owner, said: "Sometimes a lot of complexity in the processes refrain agility adoption. Some organizations prioritize their processes over Agile manifesto, whereas others emphasize more on Agile principle and mindset over the actual processes." Some Interviewees agreed that organizations adopt and understand SAFe but fail to change their mindset and way of working. Interviewees also mentioned about the technical debt arising in previous processes that created hurdles for the adoption of SAFe. Parisvaara also mentions the challenge arising out of technical debt in their analysis of large Scaled Agile transformation at Ericsson. .

6 Analysis and Discussion

This section connects the theoretical framework with the empirical findings. Firstly, we analyze the SAFe implementation roadmap with the change process model. Secondly, we go through each of the challenges and success factors mentioned in the systematic literature review and try to analyze if they pair with our theoretical framework and empirical findings.

6.1 Analysis 6.1.1 The SAFe implementation road map After analyzing the twelve steps, we found that the SAFe implementation road map could be mapped together with the Kotter's and Lewin's model of change. The SAFe implementation roadmap has been discussed in the empirical data to provide the readers a comprehensible understanding of the SAFe implementation steps and a connection between the implementation road map and change models. We have noticed earlier that Lewin's model is older than the Kotters' model, but it does not lose its credibility and reliability when applied in the SAFe implementation process.

Table 5. Comparison of SAFe a aa K a L model of transformation process.

We have mapped the implementation roadmap and adjusted the sequence steps to match with Kotter's eight steps..

1. Sense of urgency: It is the same as reaching the tipping point. Both steps strive to compel the organization to change with well-articulated reasoning and vision statements to change.

1. Building a guiding coalition: SAFe requires steering teams for execution and communicating the progress of transformation, someone who can set up the vision and have sufficient credibility in the organization to be taken seriously. In the SAFe framework, the coalition is created by:

1. Training lean-Agile change agents: To provide the necessary knowledge 2. Training executives, managers and leaders: To sponsor and support change 3. Creating a Lean-Agile center of Excellence: This group act as focal point and continuous source of inspiration.

2. Creating a Vision: In SAFe, the vision of change is created in the first step, "Reaching the tipping point." With the help of proactive leaders, that are continuously seeking to improve, a vision for change can be created. The theory also states that "The vision and clear goal is the foremost priority of a change process." (Kotter, 2012).

3. Communicating the vision and systematically planning: In SAFe, the implementation is done in an Agile and incremental way. Plan a bit, execute a bit, and learn a bit. It also relates to Kotter's step of creating short term wins. In SAFe Lean- Agile Centre of excellence is responsible for communicating the change. Training Agile teams and launching ARTs is the way to communicate the vision. Agile teams need to be trained about the new method, behavior, and skills required for the change.

4. Empowering action & Remove Obstacles: In SAFe, empowering action is related to identify value stream and ART's which are the organizational backbone of the SAFe initiative. They are primarily constructed for understanding, organizing, and delivering value in SAFe. However, in Kotters' steps, removing obstacles meant minimizing resistance through training & rewards. In SAFe implementation, there is no direct

mention regarding minimizing resistance. However, the roadmap throughout emphasizes training people at different levels so that change is understood by the people at all levels uniformly. This will eventually help to minimize the resistance.

5. Create Short wins: In SAFe, the first ART implementation is essential. After identifying Value streams, ARTs, and establishing an implementation plan, a critical moment arises when the plan moves towards the implementation. The preparation of the first ART launch is crucial, as its successful implementation creates initial short- term wins that propel an organization to build momentum to carry out the implementation further.

6. Consolidate changes: Training teams is an essential step before the launch of ART to help them master new skills, attitudes, and techniques. In this step, Kotter is of the view that real changes should run deep. There should be evaluations, and continuous improvements to continue building on the change started. Similarly, in SAFe, the coaching of the ART execution is done by daily stand up meetings, iterative reviews, retrospectives, backlog refinement to help people master their roles. Further, more ARTs and value streams are launched with the same pattern and the same moves that worked successfully for the first time. This helps to consolidate change and provide higher returns on investments.

7. Anchor changes to the organization culture: By the launch of more ARTs and value streams, a wider implementation of SAFe is facilitated. The benefit in quality, productivity, and time to market is noticeable. At this point, the success needs to be extended to the portfolio level to facilitate the anchoring of the new approach in the culture.

The above comparison of the SAFe roadmap with the change process model reaffirms our view that SAFe is a transformational process and requires a change process model for its implementation and proper execution. The SAFe implementation is a radical transformation process because it requires a shift of culture, behavior, and mindset to implement successful transformation (Anderson & Ackerman Anderson, 2001). Kotter's transformational model is a generic model for any transformational process, and it can be concluded that the SAFe

implementation roadmap has been redesigned and adapted, and it is tightly knitted to the Kotter's model.

However, we are of the view that all organizations should first analyze their current situation before implementing a new framework. In this case, it should be better to analyze what the organizations require, its situation, and later implement the SAFe framework. Thus, both Kotter's model and implementation road map should have an additional step together with "The sense of Urgency or Reaching the tipping point" to assess the current situation about the business and process content in order to determine design requirements (Anderson & Ackerman Anderson, 2001). This can then be followed by designing the state and analyzing its impact and further to the implementation plan.

6.1.2 The Challenges

1. Change resistance: Change resistance was the challenge interviewees talked about the most. They mentioned that it is a general change management challenge. This challenge can be directly inferred from our findings and support the theory that change resistance is a general change management problem (Anderson, 2011). Interviewees agreed that resistance is faced in almost all the transformation initiatives. When we analyzed the statements and responses of the interviewees, we found that the reasons for the resistance resonated well with the reasons for change resistance we had mentioned in the theory section. However, the most prominent one, as mentioned by Anderson and also agreed upon by all the interviewees, was related to inherited culture, status quo protection, and reluctance to take on the new work (Anderson, 2011). Paasivaara also mentions this fact in their study of large-scale transformation at Ericsson; some people were not willing to change their way of working at all, or the willing have different views on transformation and how it should be conducted (Paasivaara et al., 2018). Both the empirical and theoretical findings showed that culture change is difficult and is an essential element of the transformational process (Moreira, 2013). The response from the interviewees indicated that the majority of the companies adopting SAFe stem from a traditional, hierarchical based organization culture. SAFe requires a shift from hierarchical culture to a flexible and collaborative culture, from non-customer-centric to customer-centric. (Nerur et al., 2005). Nevertheless, resistance stemming out from

cultural change needs a better understanding of the way that there is a need to understand the different nuisance of cultural change. It might be possible that control, a hierarchical way of working, may not be a company culture rather than a country's culture. Then this cultural change issue requires a further in-depth analysis from this perspective.

The responses from the interviewees underpinned our assumption that change resistance is a general change management problem and not particularly related only with the SAFe implementation. However, the authors realize that some form of resistance is always required. It is a legitimate concern among the employees that if the change process goes wrong or change agents make mistakes, it can be detrimental to an organization. For instance, it could be possible that for some of the organizations, the Waterfall model is a more efficient way of handling their projects. Therefore, implementing SAFe just out of fashion without analyzing the actual need might cause an organization to invest valuable resources without gaining any advantage. An evaluation and SWOT analysis are required before undertaking a transformational process (Edosoman, 1996; Musa, 2016). Therefore, we agree that some level of resistance is necessary in order to circumspect that the transformation process will benefit and not harm the organization in the long run. We also tried to identify the relation between resistance and time. Interviewees talked about the resistance, but we analyzed that any form of transformation is met with resistance, and it requires some time to mitigate it. Perhaps, a systematic planning can help to reduce the time to mitigate the resistance. However, this correlation is difficult to state because of various factors involved in the systematic planning and other factors that have caused resistance among the employees. One more interesting fact we found is that resistance is caused because people think that Agile is aimed for a software development project and not for other kinds of projects. We see that one way to reduce this type of resistance is to replace the word "Software" mentioned in the Agile manifesto and principle (Greene & Stellman, 2018) with "Product" because it creates an impression that Agile methodology is not limited to Software projects.

2. Lack of Investment: The interviewees talked about the importance of training and coaching in the general transformational process and also in SAFe. They also addressed the role of a manager in bringing the necessary funds for the SAFe execution and training and coaching of the

employees. Thus, the challenges related to the lack of investment in the area of training and coaching can be inferred by the Empirical findings. Even the theory states that the importance of training and coaching in any general organizational transformation process and the lack of resources or investment in this area can cause a significant hurdle (Gallo, 2015). However, the majority of interviewees pointed out that in their respective organizations, line managers were investing in coaching, tools, and processes related to SAFe. So, we feel that the lack of investment in training and coaching can prove to be a hurdle if the organization does not address it. However, since most of the organizations seem to pay heed to train their employees, we see that this challenge is diminishing by the increased awareness of the organization towards this challenge.

3. Agile Difficult to implement: Interviewees mentioned that improper training and education on SAFe could cause a lot of misunderstanding regarding the SAFe concept. They mentioned that reluctance to change the organization culture from control and competence to flexibility and collaboration could cause the hurdle in the implementation of SAFe. So, this challenge can be related to Safe specific transformational challenges. What can be inferred from the interviewees is that "Agile is difficult to implement" is a challenge due to improper education about the concept: Nonchalant attitude of executives, wrong mindset, and reluctant to change the attitude of the people. Thus, our findings reinforce the theory regarding the people and process-related issues specific to Agile transformation and the systematic literature review for this challenge. One factor that Dikert mentioned is that understanding the Agile or SAFe concept is difficult due to the lack of guidance from the literature (Dikert et al., 2016). However, interviewees said that understanding the literature specific SAFe concept was more manageable, but adapting it to the mindset and culture of the organization was a daunting task.

However, we perceive the contrary, Agile or SAFe fails in some organizations not because the employees have improper guidance from the literature but because the Agile culture and the mindset are missing. Interviewees talked about the lack of an Agile mindset; therefore, there is a need to improve this mindset by setting up workshops about culture and the way of working on Agile or SAFe. Interviewees further mentioned that Agile implementation was difficult also because many of the employees felt that

Agile or SAFe is related to software development and cannot be implemented in projects pertaining to manufacturing or banking.

4. Coordination Challenges in Multi-Team Environment: Interviewees talked about the coordination and communication problem in the Multi- team environment, and that challenge is particular to SAFe. Dikert mentioned that coordination challenges arise when Agile teams have to work with other teams in the organization, which is not working agile and responsive enough. The coordination problem is also prominent when coordinating the work with other Agile teams (Dikert et al., 2016).

The interviewees mentioned that SAFe or Agile transformation is limited only to the IT department because it causes misalignment with other teams. They agreed that dependencies on other Agile release trains (Multiple teams) during PI planning causes difficulties in the organization of the work. They argued that often it is difficult to plan in each sprint due to the dependencies on other teams that result in continuous work and additional burden. We also agree that IT can be the starting point for the implementation, but it should be carried out with other departments to avoid misalignment with the rest of the company. Dikert emphasized the global distribution as a cause for the coordination challenges, and the interviewees agreed that teams with distributed settings create more of a coordination problem due to time zone differences, different environment, and organization settings (Dikert et al., 2016). This challenge can be directly inferred from the empirical findings. The theory also supports that this challenge is specific to Agile transformation. Theory mentions that Agile requires cross- functional teams, and SAFe goes a step further to work with multiple cross-functional teams that create complexity (Nerur. et al., 2005).

5. Different Approach Emerge in Multi-Team Environment: Interviewees mentioned that due to lack of training and coaching at the different levels in the organization, the interpretations of Agile or SAFe between the teams differed. Dikert mentioned that the interpretation of Agile differs between the teams and that often new agile methods are used in parallel with the old ones. Interviewees expressed their concern that when teams are working Agile, but still the old structure is in place, it is easier to come back to the old ways of working. Thus, this challenge can be implied

from the empirical findings. This challenge is associated with the process-related challenge specific to Agile mentioned. The move from Traditional heavy-process centric process to short iterative people-centric process causes challenges. It becomes a challenging task for all the teams involved to alter the strategies pertinent to SAFe in a similar fashion and henceforth to provide a unified approach to SAFe implementation throughout the Organization (Nerur et al., 2005).

6. Integrating Non-Development Challenges: Interviewees talked about change resistance and also communication & coordination problems related to synchronization of teams working with different organization functions. More often, development teams working with Agile or SAFe require assistance from other organization's functional teams, which might not be working with SAFe or Agile. This creates coordination problems and affects the delivery time of the product (Dikert et al., 2016). The interviewees mentioned the misalignment of Agile teams with other functional teams not working with Agile. However, they did not mention the challenges particularly related to adjusting to product launch activities and incremental delivering pace, as mentioned by Dikert (Dikert et al., 2016). One reason that the interviewees did not talk about the specific problem could be that they did not want to divulge confidential information about their company unintentionally. However, this challenge is correlated with the communication and coordination problem. Thus, some aspects can be inferred from the empirical findings. As this problem is related to the coordination problem, it is related mainly to Agile and SAFe.

7. Hierarchical Management and Organizational Boundaries: Interviewees talked about the Role of Executives, change agents, and also how their behavior and mindset can affect the SAFe implementation to a large extent. This challenge is related to management problems emanating from the change of roles, for instance, from Project Managers to Scrum Masters. Interviewees mentioned how the Agile culture requires flexibility, expecting the Scrum Master to support the team and not policing them like Project Managers and expecting the people and team to be self- organized rather than to be dependent on Managers. Interviewees mentioned that when large organizations changed to Agile, they try to be Agile, but the Waterfall environment remained embedded. A lot of traditional roles and project plans need to be changed. Person A, Tester, for instance, said that a traditional project plan has clear deliverables

and deadlines. In contrast, Agile is suited for unpredictability, making decisions as late as possible to avoid irreversible decisions. Interviewees also mentioned that Agile or SAFe replaces traditional roles, and years to come Manager's role will be more diffused as teams will be required to be more autonomous and self-organized. This resonated well with the theory about Agile specific people-related issues in which stated that in an Agile environment, team members would be autonomous, self-motivated and accountable for their work instead of the managers who will need to be set back. (Nerur et al., 2005).

One challenge that we did not mention in the systematic literature review, but was mentioned by the interviewees, is that organizations sometimes do not have proper tools and processes to manage SAFe. The interviewees said that some organizations try to adjust Agile principles as per their existing processes that somewhat deem to fail in the long run. They agreed to the fact that the first Agile mindset and culture should be developed, and then processes should be adjusted as per the Agile culture. As agile requires different approaches towards the processes; for instance, Agile or SAFe requires a shift from heavy-centric processes to short iterative people-centric processes (Misra et al., 2010). Traditional processes are compliance-driven, whereas Agile is based on speculation and planning as to everything is uncertain (Nerur et al., 2005). We are of the view that customizing Agile as per organizational need is essential, and there can be continuous improvement so that Agile culture and processes develop as per the Agile or SAFe framework suits the organizational goal. The SAFe framework and the underlying processes should be compatible with each other so that they solve a purpose and meet the organizational goals.

As mentioned, SAFe is also a transformational process. Thus some of the challenges faced in the implementation are general transformational challenges. Through the analysis, we concluded the following:

The challenges, such as change resistance and lack of investment, are general organizational transformation issues. The challenges, such as coordination challenges in a Multi-team environment, the emerge of different approaches in a Multi-team environment, and the integration of non- development challenges are Agile specific transformation issues.

6.1.3 The success factors

1. Management Support: Almost all the interviewees unanimously agreed that management support is one of the success factors in SAFe transformation. However, they differed on the kind of support expected from different management levels. For instance, Person C, SPCT trainer, sees support from HR-Managers as crucial and thinks that they play a crucial role and facilitate change by development and training program, recruitment of talent, and creating an attractive workplace. Interviewees believe that management is the ones to set goals, vision, and how the change should be carried out, as mentioned by Ander de Waal (De Waal, 2018). We agree that management plays a key role in establishing a clear vision and strategy. However, the management team will tend to fail if the employee does not understand the purpose of transformation. Filomena underlined that communicating and engaging employees to the ongoing action is a key role played by the management (Filomena et al., 2018). Interviewees agreed with the Paton view that leaders need to facilitate individual awareness for the need for change and stimulate interest and commitment. (Paton, 2008). Thus, management support as a success driver can be directly inferred from the Empirical findings, which states the role of Executives in motivating and providing training and coaching to the people, which facilitates successful implementation of SAFe. The authors analyzed that the management role is connected to all the above findings. Whether it is about mitigating resistance, providing funds, providing training and coaching, changing the mindset of people by motivating them, and maintaining proper communication at all levels. Managers are the ones aligning the whole organization towards the change. Furthermore, the authors see that the management role cannot alone be a success factor. If the organization does not have an Agile culture, not even a proper management that has the capability to align the whole organization towards the change will not work well. As per the interviewees' responses, we analyzed that the management role becomes crucial only when some form of Agile culture is already eminent in the organization. Organizations that suddenly switch to SAFe way of working from the Waterfall model without having any significant Agile culture tend to fail in SAFe implementation, even though there is proper management support. Therefore, improvements towards influencing people on

having an Agile mindset should be a task before, during, and after the implementation to successfully implement a new framework or, in this case, SAFe.

2. Commitment to change: Interviewees mentioned that motivating people and giving them proper training can help to mitigate change resistance and can make people committed to change. Dikert mentioned that a strong commitment is required by the managers so that a message is communicated that the change is not negotiable and the old way of working cannot be returned (Dikert et al., 2016). However, the interviewees did not mention this success driver in particular. The reason might be that they already talked about the management role and how they can motivate people by staying committed themselves. The commitment alone cannot make the transformation successful until the management has engaged employees to make them understand the purpose of change and make employees committed to change. We believe that Managers should have proper knowledge about the SAFe implementation before they try to make employees committed to the change process. Managers need to have an in-depth understanding and experience of working in an Agile environment; only then can they proceed with the implementation of SAFe and further see the results on motivating other employees.

3. Choosing and customizing the Agile approach: Interviewees mentioned that organizations should do circumspect in order to determine whether SAFe is a suitable choice for the organization and should have an open-minded approach to see if a particular solution works in their organizational settings. Person D, Developer, said: "in the company I work for, the organization tried different set up of teams, and if something did not work, it was changed quickly as per their organizational requirements." In the theory section, we mentioned that proper evaluation of the current condition should be done before a transformation is carried out (Edosomwan, 2016; De Waal, 2018) so that it is done as per the organizational needs. Several organizations have agreed that the customization of Agile methodology is one of the best approaches to start with (Rodriguez et al., 2013).

4. Piloting: This factor can be inferred from the results. Interviewees mentioned that successful piloting through a small project could lead to greater acceptance among the people and

mitigate resistance. Piloting can help to ensure that SAFe is a suitable option for the organization and can lead to a valuable learning experience and help in mitigating challenges when implemented in other larger projects. Interviewees agreed to the fact that piloting, if successful, increase the will of other teams to make more significant changes further on. Anderson and Ackerman mentioned the fact that transformation should be first applied to a small group of people and in a smaller project to know its impact (Anderson & Ackerman Anderson, 2001). Piloting was a successful action in Paasivaara's case study and emerged as an important step common to not only Agile or SAFe but also in other transformation processes (Paasivaara et al., 2018).

5. Training and coaching: Almost 80 % of the interviewees agreed that sufficient training and coaching at all levels in the organization could lead to successful SAFe implementation. It helps not only in mitigating resistance but also motivating and aligning people's mindset with the organization's goal of the change process. Interviewees mentioned that the absence of unified coaching across the site leads to a lack of common direction in SAFe implementation that eventually causes different approaches towards the framework and causes a lack of unified agile mindset and understanding. The theory mentions that training and coaching align and unifies individual actions with organizational goals. (De Waal, 2018; Stevenson, 2014). It ensures competency development to cope with the organization's changing requirements (Rosa, 2016). Few interviewees were of the view that the effectiveness of training depends on the employees and how the course is conducted, whether employees are positive, negative, or neutral towards the change. In this case, Agile coaches have a greater responsibility to identify the negative ones, reach out to them, and change their perspective. Overall, we think that apart from these criteria, the structure and content of the training should also be insightful to generate interest among the attendees towards the change.

6. Communication and transparency: Almost all the interviewees stressed the importance of proper communication for the successful implementation of SAFe. It can be inferred from the results that interviewees agreed that there should be transparency in the sense that people must be aware of the change process, and they should be given a chance to provide their feedback. Interviewees were of the view that communication combined with management support

and education plays a vital success driver. Communication aligns employees with the company's mission (Johnson, 2014). Filomena explained that communication helps the employees, stakeholders, the goal of change, and it should include feedback and effective dialogues with employees to ensure penetration of change within the organization (Filomena et al., 2018). Thus, the success factor of proper communication and transparency can be directly inferred from the results.

7. Mindset and Alignment: Interviewees discussed the importance of proper mindset in achieving the successful implementation of SAFe. They stressed the fact that proper training and motivation helps to align people's mindset with the organization's goal of the change process. Ackerman and Gustavsson believe that culture, mindset, and behavior are crucial factors for change. Change in mindset causes behavioral change, eventually creating a culture to adapt and change (Gustavasson, 2016; Ackerman Anderson, 2001). Interviewees agreed that companies should begin with behavioral change, changing the mindset (Agile routine and practices), and creating an Agile culture followed by a small iterative structural change. In the theory section, behavioral and structural systems are mentioned as success factors (Edosomwan, 2016; Musa, 2016). The behavioral system is about perception and mindset, and a robust structural system compatible with the change process should be built. Interviewees were of the view that structural change should be secondary to behavioral change and should support behavioral change. We also believe that in order to achieve a permanent change, behavior change should be initiated first, followed by structural change.

After analyzing all the challenges and success factors, we found that they are closely correlated with all the elements for successful transformational process mentioned in the theory section. However, we are of the view that one success factor that was not mentioned by the interviewees, and it is in the Systematic literature review. We are referring to the importance of a clear purpose and asking "why" a SAFe transformation is required.

Interviewees mentioned that organizations should evaluate and examine the current status of organizations, understand the underlying problem, and then come up with a purpose as to why SAFe transformation is required. A proper evaluation of an organization's current condition is essential to ensure that the transformation plan developed is comprehensive (Musa, 2016).

Kniberg mentioned that it is essential to find the root cause of a problem and ask "why" before jumping on to a solution. A clear goal and purpose are essential for the initiation of a change process followed by effective communication of the purpose to the employees (Kniberg, 2014). We also pointed out in the theory section that a clear and consistent goal with unambiguous metrics and milestones should be there to ensure the progress is effectively tracked. (De Waal, 2018).

6.2 Discussion 6.2.1 The Challenges and Success factors As per the literature review, Managers and change agents play an essential role in motivating the employees. By having transparency and proper communication, they can make employees committed to change. However, despite the proper management support, why in some organizations, SAFe implementation fails, and in some others, it succeeds. Through the interviewees' responses and analyzing the SAFe trajectory, we think that companies that had adopted Agile culture before switching to SAFe were successful in implementing SAFe compared to the companies that switch to SAFe without having any previous Agile culture experience. As per the transition history of SAFe, the Waterfall model was followed by an Agile way of working, which was then scaled to meet the requirements of large organizations with Multi-team environment, through frameworks such as Less (Large scale scrum) and SAFe (Hexacta, 2018). SAFe is an extension of the Agile way of working, and if the employees do not adopt an agile mindset and culture, they are prone to revert to their original way of working. Therefore, it is crucial to make employees realize that Agile is a way of working and is not only limited to software development. Once employees adopt the Agile mindset, it will not only limit the resistance posed by the employees but also make it easier for management to implement SAFe methodology.

We analyzed that the successful implementation of SAFe also depends on the company where implementation is taking place. For instance, in companies where Agile seems to be a dominant way of working throughout the whole organization, those companies can be better in implementing SAFe than an organization where the way of working is mixed. We are referring to the sense that some departments require an Agile way of working, and other departments require the traditional waterfall model. This possibly happens because, in the latter case, not all the teams from various departments are working on Agile, it creates different approaches in the

Multi-team environment, causing teams to switch from Agile or SAFe to revert to the old ways of working.

Agile is a way of working. Projects differ in their complexity, iterations, demands, and objective. It is always necessary to evaluate the way of working a project seems to be most suited for Agile or waterfall, and this fact is one of the key criteria before switching to SAFe. As per the interviewees' responses, it was eminent that SAFe roadmap works well for some of the companies while failing for some of them. Therefore, SAFe roadmap needs to include the evaluation step regarding the current situation of the organization. Any single change management system has mentioned this step stated in this thesis report. It seems to be forgotten by the other authors. However, we consider this as a mandatory step before going ahead with a consideration of implementing any kind of new framework or philosophy in a Company. The success of SAFe implementation depends on various factors, such as what kind of company it is being implemented, whether the company had previously been working on Agile or the Agile way of working was suddenly thrown on them, the kind of projects undertaken, etc. After an in-depth conversation with the interviewees, we think that the roadmap and change models can be used as a guiding tool and should be customized as per the organizations' requirements and not just be blindly followed. Further, an evaluation of a company's current situation and its requirements are needed before going ahead with the implementation.

6.2.2 The Failure of Communication between the different Levels SAFe and its roadmap implementation have been described in the empirical section to give the readers an explanation of the SAFe structure, and the recommended guidelines for implementing this framework. We noticed that usually, people from the team level and program level work together in the ART, and they are in contact all the time for coordinating the project and ARTs. This can be seen in the implementation roadmap that it involves much training. During the implementation and creation of the first ART, only employees from both team and program levels are involved, and it concerns the creation of the upcoming ARTs as well. Those meetings are useful not only for sharing their knowledge and input but also for the discussion of the SAFe process itself so that everyone gains more knowledge about the process, and minimize the lack of uncertainty when employees are proceeding with their operations. However, there are also some drawbacks. People in the portfolio level usually are in contact with the people on the program level but less in contact with the people on the team level. See figure 14.

Figure 14. The communication flow between the SAFe Levels

Each portfolio comes out with their own values and solutions, and this is communicated from the Portfolio level to the Program level. When the Program level is about to start the projects, they meet the team level for going through the project and coordinate it. However, there can be some lack of communication between the team level and portfolio level as perceived by some developers. Some developers were not motivated because there were no explanations from the upper management or Portfolio level, and this is happening in SAFe. Therefore, we believe that the people from the portfolio level should also be involved in the ART meetings, in order to resolve the people's uncertainties that query the process. Therefore, the authors suggest having more communication between the Portfolio Level and Team Level. See figure 15.

Figure 15. Suggestion of communication flow

6.3 Limitation of the study One of the main points that the authors would like to improve is the number of participants for gaining even more reliability. Unfortunately, one of the restrictions for not studying this even more in-depth with more participants is the restriction of the project cadence. However, we believe that the analysis is still reliable because we conducted in-depth interviews with the participants in which each interview was performed face to face. Another reason for not having more participants in the methodology chosen for the thesis. We decided at the beginning of the thesis project to have the interviews more personally instead of opening the doors for people that probably could be part of it through other communication channels as Skype conference calls, for instance. Also, the snowballing method for reaching more people has not been successfully performed. When we reached the first four participants for this thesis project, we permitted the participants to ask their colleagues to participate in the interviews. Instead, we should have tried to reach their colleagues by ourselves directly at the office and leave our contact information for contacting us.

The sources used for explaining the SAFe way of working and the SAFe implementation roadmap are taken the creator Leffingwell's website. Therefore, we consider that this data gathered from the webpage might be too positive and hide the negatives of the framework. In the end, Leffingwell, with his team, sells the education, and the way of attracting customers is showing the positive sides of it. Therefore, a sense of impartiality has been taken into consideration in the analysis.

7 Conclusion The selected method for this research, face-to-face interviews, proved to be the right decision in collecting in-depth experiences of the interviewees. Moreover, the interviews performed with some previously semi-structured questions helped us to focus on what we wanted to ask instead of beating around the bush during the interview. We performed an in-depth discussion about the interview questions, and having preparations before the interview saved ours and the interviewees valuable time.

In the method section, we explained the selection of participants. We pointed out that the most important reasons for selecting those interviewees were their background because they worked in two different frameworks, both in Agile and currently on SAFe. In this research, there have been nine participants for the interview process. In order to minimize the weaknesses of it, we had an in-depth interview with each person and understood if they have the necessary knowledge about SAFe, which is an essential part of this thesis work. We consider that the information gathered from those interviewees is enough for getting our conclusions. The main results and findings of the interview underpinned the systematic literature review findings and our theory.

Returning to our research questions:

RQ1: How have the challenges encountered in the systematic literature review been conceptualized according to the experiences of people working on SAFe?

We conclude that our findings underpin the six challenges mentioned in the systematic literature review. All the challenges in the literature review are directly or indirectly inferred from our . A a a Ia -development a b , a a a challenge can be inferred from the findings.

RQ2: How have the success factors encountered in the systematic literature review been conceptualized according to the experiences of people working on SAFe?

T , aa a a a factor in the SLR. Thus, the success factors mentioned in the Systematic literature review is underpinned by our findings.

Recommendations:

1. Piloting and stepwise transformation approach: As mentioned in our analysis, piloting is an excellent way to experiment if a solution would work in an organizational setting. It generates an Agile mindset to try, fail, and quickly make changes to adapt (Inspect & adapt). Moreover, in the case of SAFe transformation, step by step approach can be adopted as it is challenging to plan everything beforehand. The stepwise approach supports the Agile mindset of unpredictability as it allows space to try, inspect, and move ahead.

2. A W: I a aa a aaa b switching t a aaa . A a a a aa wants to implement a change is a prerequisite. For instance, a SWOT analysis can be performed to introspect the organizational need; it will also help in assessing the design requirements and the impact it will create before actually making an implementation plan.

3. It is recommended to follow the SAFe implementation road map but customize the steps as per the organizational settings.

4. Continuous Improvement: Implementing SAFe is a transformational process, and it is required to work with it continuously, improving it and not just ticking a box that it is complete and done. The key to the SAFe introduction is having an Agile mindset of continuous improvements.

To sum up, the research helped us to identify important aspects to be taken into consideration when implementing SAFe. Through the interview results, we came up with a conclusion that if

an organization wants to have a successful SAFe implementation, the organization should focus on removing the challenges and enforcing the success factors mentioned in this thesis. However, we are aware that this framework is relatively new, and interviewees are yet to see the real success of the SAFe transformation with the passing time.

References

Al-Baik, O., & Miller, J. (2015). The Kanban Approach, between Agility and Leanness: a Systematic Review. Empirical Software Engineering, 20(6), 1861-1897. Alvesson, M. & Sköldberg, K. (2008). Tolkning och reflektion: Vetenskapsfilosofi och kvalitativ metod. Studentlitteratur. Lund, Sweden. Anderson, A. (2011) Engaging Resistance: How Ordinary People Successfully Champion Change. Stanford University Press. California, US. Anderson, D. & Ackerman Anderson, L.S., 2001. Beyond Change Management: Advanced Strategies for Todays Transformational Leaders. D. Bradford et al., eds., San Francisco: JosseyBass/Pfeiffer.

Agarwal, R., & Umphress, D. (2008). Extreme Programming for a Single Person Team. Paper presented at the Proceedings of the 46th Annual Southeast Regional Conference on XX. (Agrawal & Umphress,2008) Boehm B., Turner R. (2005) Management challenges to implementing Agile processes in traditional development organizations, IEEE Software, vol. 22, no. 5 Bryman, A. & Bell, E., (2011). Business Research Methods. Third edition. Oxford University Press. New York, US. Bryman, A. & Nilsson, B. (2011). Samhällsvetenskapliga metoder. Liber. Malmö, Sweden. De Waal, A. (2018) Success factors of high-performance organization transformation. Measuring Business Excellence, Vol. 22 Issue: 4. Dikert K., Paasivaara M., Lassenius C. (2016). Challenges and Success Factors for Large-scale Agile 45 Transformation: A Systematic Literature Review. Journal of Systems and Software, vol. 119, pp. 87108.

Dima, A.M., Maassen, M.A. (2018) From Waterfall to Agile software: Development models in the IT sector, 2006 to 2018. Impacts on company management. Journal of International Studies Ebert C., PaasivaaraM. (2017) Scaling Agile. IEEE Software, Volume: 34, Issue:6

Edosomwan, J.A. (1996) Organizational transformation and process reengineering. St Lucie Press and the Quality Observer Corporation, Fairfax, VA and Delray Beach FL. Filomena Canterino, Stefano Cirella and Abraham Baruch (Rami) Shani (2018) Leading organizational transformation: an action research study. Journal of Managerial Psychology, Vol. 33 No. 1, pp. 15-28

Finch, E (2011) Facilities Change Management. John Wiley & Sons, Incorporated. Oxford, UK. Gallo, A. (2015) Overcoming the toughest common coaching challenges. Harvard Business Review. Retrieved on 2019-04-02 from https://hbr.org/2015/04/overcoming- the-toughest-common-coaching-challenges

Greene J.,Stellman A., (2018) The Agile Principle. Retrieved on 2019-04-05 from https://learning.oreilly.com/library

Guba, E. G., and Lincoln, Y. S. (1994). Competing Paradigms in Qualitative Research, in N. K. Denzin and Y. S. Lincoln (eds). Handbook of Qualitative Research. Thousand Oaks, Sage Publication. Gustavsson, T., 2016. Agil projektledning, Stockholm: Sanoma Education

Hansmann, U., Stober, T. (2010) Agile Software Development - Best Practices for Large Software Development Projects. Springer International Publishing.

Hexacta (2018) Infographic: Timeline of software Development methodologies. Retrieved from https://www.hexacta.com on 2019-04-05

Johnson, A. (2014). How to get employees to align with the company´s mission. Retrieved from https://www.bizjournals.com/ on 2019-03-25.

Kalenda M., Hyna P., Rossi B. (2018) Scaling agile in large organizations: Practices, challenges, and success factors. Journal of Software: Evolution and Process, Volume: 30, Issue: 10. Khan, R. J. Qurashi and U. A. Khan (2011) A comprehensive study of commonly practiced heavy and light weight software methodologies. Int. J. Comput. Sci. Issues, vol. 8, no. 4.

Kniberg, H., 2014. Spotify Engineering Culture. Spotify. Available at: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ [Accessed July 18, 2019] Kotter, J.P. (1995). Leading Change: Why Transformation Efforts Fail. Harvard Business Review. Boston, US. Kotter, J.P. (2012) Leading change. Harvard Business Review Press. Boston Massachusetts, US.

Kotter, J. &. (2002). The Heart of Change. Harvard Business School. New York, US. Leffingwell D. at al. (2011) Scaled Agile Framework® SAFe® for Lean Enterprises. Available from: https://www.scaledagileframework.com/ , Last update: 2018

LeMay, M. (2018) Implementing and scaling Agile in the enterprise: A goals-first approach. O'Reilly Media, Inc. California, US. Lewin, K. (1951) Field Theory in Social Science. Harper & Brothers Publisher. New York, US. Lincoln, Y. S., and Guba, E. (1985). Naturalistic Inquiry. SAGE Publication. California, US. Marchesi, M., Succi, G., Wells, D., Williams, L., & Wells, J. D. (2003). Extreme Programming Perspectives (Vol. 176): Addison-Wesley. Misra S.C., Kumar V., Kumar U. (2010) Identifying some critical changes required in adopting Agile practices in traditional software development projects. International Journal of Quality & Reliability Management, Vol. 27 Issue: 4.

Moreira, M. E. (2013) Being Agile: Your Roadmap to Successful Adoption of Agile. First edition. Apress. New York, US.

Morten J., Berg E., Karlsen J.T. (2012) An evaluation of management training and coaching. Journal of Workplace Learning, Vol. 24 Issue: 3.

Musa, A (2016) Organizational Transformation Concepts and Implementation Techniques. Penerbit USM. Gelugor, Malaysia.

Nerur G. S., Mahapatra R., Mangalaraj G. (2005) Challenges of migrating to Agile methodologies. Communications of the ACM. Vol. 48, No. 5.

Nikitina, N., & Kajko-Mattsson, M. (2011). Developer-driven big-bang process transition from Scrum to Kanban. In Proceedings - International Conference on Software Engineering Nikitina, N., Kajko-Mattsson, M., & Stråle, M. (2012). From scrum to scrumban: A case study of a process transition. In 2012 International Conference on Software and System Process

Othman, M. Ismail, M.H., & Wahab, N.A. (2017) Computing Research & Innovation (CRINN). Perlis Branch. Vol 2. University Teknologi Mara.

Paasivaara M. (2017). Adopting SAFe® to scale Agile in a globally distributed organization. Proceedings of the 12th International Conference on Global Software Engineering, Argentina.

Paasivaara, M., Behm, B., Lassenius, C. et al. Empir Software Eng (2018) 23: 2550. https://doi-org.ezproxy.its.uu.se/10.1007/s10664-017-9555-8

Paton, R.A. & McCalmain, J. (2008). Change management: A guide to effective implementation. Third Edition. SAGE Publications. California, US.

iii

Paul C. Hong, Tomy K. Kallarakal, Mariam Moina and Margaret Hopkins (2019) Managing change, growth and transformation: Case studies of organizations in an emerging economy. Journal of Management Development, Vol. 38 No. 4, pp. 298-311

Rashina, Hoda & Salleh, Norsaremah & Grundy, John. (2018) The Rise and Evolution of Agile Software Development. IEEE Software. Volume: 35, Issue: 5.

Rodríguez P, Mikkonen K, Kuvaja P, Oivo M, Garbajosa J (2013) Building lean thinking in a telecom software development organization: strengths and challenges. In: Proceedings of the 2013 International Conference on Software and System Process, ICSSP13, 98107

Rosha, A.; Lace, N. (2016) The scope of coaching in the context of organizational change. J. Open Innov. Technol. Mark. Complex. 2016. Vol 2. No 2.

Scheerer, A. (2017) Coordination in Large-Scale Agile Software Development: Integrating Conditions and Configurations in Multiteam Systems. Springer international Publishing. Scheepers, CB (2013). Coaching Leaders: 7 P Tools to Propel Change. Knowres Publishing, Randburg, South Africa. Stevenson, H. (2014) What you need to know about coaching services. Retrieved from http://www.clevelandconsultinggroup.com/articles/coaching-services.php on 2019-03- 04.

Turk, D., France, R., Rumpe, B. (2014) Limitations of Agile software processes. Third International Conference on Extreme Programming and Flexible. Available at: https://arxiv.org/pdf/1409.6600.pdf