Realization of Agile Methods in Established Processes: Challenges and Barriers

Abstract

This paper presents an explorative study and the results of 17 interviews with informants from different companies. Its purpose is to identify the challenges associated with implementing agile methods along with the established procedures for early design. The study exemplifies project leaders’ experiences and implementation efforts. As leaders of design projects, they have proposed the use of a new method that involves teams engaging in testing and evaluation, which aids in the understanding and introduction of change initiatives. The challenges that are identified are as follows: (1) a lack of approval not only from top managers but also from critical peers; (2) an unprepared organization that did not allow teamwork; and (3) a lack of specific company success factors to support new methods.

1. Introduction

By the mid-1980s, the business environment was already being described as fast-paced and competitive. Speed and flexibility were crucial for product design and development teams [1]. Design and development change are even more important in the current digitalization era, e.g., technologies are continuously replaced with smarter ones, digital platforms for business and marketing come and go, along with technical platforms, and delivery must not only be managed in supply chains but also in digital ecosystems across multiple partners and third-party service providers. In line with these changes, the servitization of manufactured products has become possible, but companies are still unsure of how to implement it. Nevertheless, approaches to closing the gap between customers’ needs and the technological transformation are considered to be important for more appropriate engineering processes [2]. Thus, seeing digital progress as mainly technical is a mistake. The digital transformation is expected to reach beyond the benefits for companies’ and industries’ processes, since it is an opportunity to solve societal challenges, such as sustainable development [3,4]. Thus, by default, a digital transformation insists on combining social, technical, and business factors in the early design stages. It is not news that the tasks of design work are a matter of balancing social and technical activities [5], and the fact that design behavior and performance are social features that are central in engineering design has also been established [6]. These traits are thus becoming even more important in light of the fourth industrial revolution, or Industry 4.0. The trends of Industry 4.0 not only describe the introduction of data-driven ecosystems and digitalization but are also rooted in a new type of digital service value creation process in the manufacturing industry [7]. Product–service systems, PSS [8], are grounded in Industry 4.0 and have been established in the manufacturing industry but under different brands, e.g., total offer, service provision, servitization, functional product development. PSS targets sustainable development and a circular economy by taking both production and consumption into account in engineering work. These kinds of efforts demand teamwork, in which the understanding of user behavior has to feed directly into the early stages of design [9], and a better and more disruptive innovation process has to become the basis for the development of new solutions [10]. The socio-technical perspective is seen as an enabler to address the magnitude of concentrated and complementary competences needed for the design of sustainable service deliveries—for instance, new types of business models, making use of crowd communities, automated analyses and diagnoses, the feedback of real data, and creative value design [7]. Digital services and the servitization of products are predicted to radically challenge established routines and procedures in design and product development [11,12]. Smartness and connectedness have the potential to aid in the management of changing business environments and opportunities, but a complete transformation of the work organization is recommended [13,14].

Companies are therefore more or less forced to rethink how to apply innovative and creative design processes. Such approaches need to be adaptable to customers’ (or users’) different requirements to deliver customized solutions to generally ill-defined problems or, as Rittel and Webber [15] concluded long ago, methods that are capable of dealing with wicked design problems. Adaptability to change, complex problem solving, and skills that relate to advanced engineering processes and developments have been highlighted as essential future skills for engineering professionals [16]. So-called traditional approaches can be seen as structured and sequential, but these terms do not reflect the complexity of contemporary product–service design and development projects. Projects in which the goal is clear but the solution is unclear benefit from the use of agile approaches [17,18]. Agile development [19] and human-centered innovation are non-rigid approaches, which have inspired and progressed design thinking [20,21]. Design thinking has been introduced among firms but as an innovation process, rather than a new and agile design rationale. A transformation of design and development work is truly challenging, since it also requires a shift in reasoning, i.e., mindset [22]. It is well known that the task of simply integrating a user perspective is not straightforward in manufacturing design and development processes [23,24]. This imperviousness to change is still noticeable among product and service companies. In this context, it has become interesting to study how agile design methods are introduced and implemented in established engineering processes and to understand the barriers encountered by the proponents in the introduction of what are, to them, new methods. For this purpose, we have investigated project leaders’ efforts to implement agile methods from design thinking [25] in their current design processes.

The steps in design thinking are described by Kelley [26] as “a method to our madness”, since the steps are used differently, depending on the design situation. The main steps are described as understanding users, using a variety of techniques to observe behavior, brainstorming and visualizing ideas, and evaluating and refining prototypes, which are all conducted in a series of quick iterations [26] (pp. 6–7). This means that design thinking is not only problem solving, but also problem formulation. This capability of framing and frame creation is critical in design [27], simply for ensuring that the main design problems are understood. The possibility of applying different methods to fit a specific situation, which is the opposite to following standardized processes, is the power of design thinking, i.e., its agility. The term agile, which we use in the context of the studied companies, means that the company representatives made efforts to implement agile methods derived from design thinking. Hence, we do not refer to these activities as involving a complete transformation of the design process or implementation of agile development by definition; instead, we use the term agile methods in general, without referring to specific ones.

2. Methodology

The data for this study were gathered in a range of different industries and thus in different types of design practices, e.g., product design, service design, user experience design, and interaction design. The informants represented a mix of national and international firms. Their businesses could be categorized as innovative product and technology development from the domains of manufacturing, the process industry, IT communication, software and management consultancy, and engineering services. Thus, a mix that represented the actors in both product and service design was achieved. However, the unit of analysis was the matter of introducing agile methods, meaning that the phenomena to study exist in different businesses but the focus is a single entity [28].

For this study, explorative and inductive approaches were used [29]. An exploratory qualitative research approach provides a rich basis for understanding real-life situations [28]. Empirical data from 17 interviews serve as the basis for the paper. The interviews lasted 1 h on average and were conducted using an online meeting technology, with recording functions. The informants from the companies were selected based on their interest in design thinking and expertise in leading design and development projects. Access to the companies was provided via a research project for innovation processes. The selection was based on the idea that the informants expressed that they applied a transformative leadership [30] style to foster and act on social capital [31]. This implies that they manage change and, in some sense, self-generate their working conditions. They therefore possess what Courtney, Kirkland, and Viguerie [32] (p. 73) call a “shape the future” authority. The informants’ interest in agile development was thus known ahead of their selection due to their participation in different earlier research collaborations. Their formal leadership was expected to allow them to introduce changes, implement them, and set new standards in their own design projects. The informants were all male, all had a leading role in early design, and all had acquired a university-level education in different fields (mechanical engineering, computer science, social sciences, etc.), as shown in

Table 1. Overview of the businesses and positions of the informants.

Id	Type of Business	Expertise Area
1	Software development	Agile expert
2	Aerospace	Specialist
3	Manufacturing industry	Innovation designer
4	Construction industry	Engineering services
5	Management consultancy	CEO and founder
6	Industrial electronics	R&D manager
7	Manufacturing industry	IT development
8	Industrial electronics	Human resources
9	Management consultancy	Visionary designer
10	Mechanical engineering	CEO
11	Technical innovation	Process developer
12	IT consultancy	Business developer
13	Process industry	Application developer
14	Production industry	Global developer
15	Manufacturing industry	Product unit manager
16	Medical technology	R&D manager
17	Incubator and science park	Business model developer

.

The interviews followed a planned strategy but could be labeled as semi-structured, i.e., based on a broad and open topic, which allows for a flexible structure and has an investigative nature [33]. This semi-structure allowed for follow-up questions that differed, depending on the informants’ answers [34]. This approach is useful when the research aims to find variance by collecting and analyzing qualitative data about people’s interpretations, perceptions, and experiences in a situation [33]. Qualitative data thus become a vital resource when the research seeks to understand ordinary multidimensional daily work, particularly interactions between people [33]. The aim in gathering qualitative data is to gain rich data on a specific phenomenon, so the sampling is based on finding a number of respondents possessing interest and expertise in the chosen area [35,36]. In qualitative research, there are several ways of interpreting an event and no single “correct” interpretation—only plausible ones [37]. Statistical generalizations are hence not sought for, nor are qualitative patterns in the material. Saturation guided the fulfilment of the interviews, i.e., patterns in the material could be identified when expressions/themes occurred multiple times [33]. The online meeting technology made it easy to record the interviews, which were subsequently transcribed. The transcriptions have been read in three iterations: literally, interpretively, and reflexively, which is an established approach to the analysis of qualitative data [28,33,35]. The result of the analysis should be a number of excerpts from respondents that represent “constructions of explanations” [33] (pp. 170–171), which are grounded in the material [38], e.g., a typical expression for the situation. All of the presented excerpts are from the recordings. The text has been analyzed using an open coding approach, where obvious (explicit) and embedded (implicit) expressions have been searched for. This means that the respondents’ statements indicate connections to theory—in this case, the field of agile methods and, specifically, the underlying logic presented in the following Section 3. Here, the topic agile methods guided the final coding in relation to the concept of “implementation efforts and challenges”, i.e., terms that convey the meaning of the study [28].

The results of the study were presented in an additional workshop addressing the topic of design thinking and its agile methods. The participants in the workshop were representatives from the included companies but also additional representatives from other companies. Our interpretations of the data were revised by three project leaders from three additional companies, who evaluated the study’s relevance to implementation efforts. The data are presented in a specific non-company way, and the companies and informants are kept anonymous as far as possible. This is due to a request from the informants, who identified the thoughts and insights that they shared as sensitive.

The following section provides a theoretical perspective which originates from the iterative and open coding approach in the analyses of the empirical material. Section 3 hence supplies a framework and a theoretical background to positioning the excerpts from the respondents, i.e., in Section 4.

3. A Philosophy to Guide Agile Methods

An agile philosophy, or design rationale, establishes that value resides in people, in testable deliverables, in customer collaboration, and in responsiveness to change, which, in turn, lays the groundwork for its methods. The agile philosophy originated in the software industry and was a radical response to, e.g., the problem of belated user involvement and testing [19]. Not all software developers exploited the full potential of the methods. Dorta, Kinayoglu, and Boudhraâ [39], for example, claimed that the industry was not “agile enough”. In particular, they did not support quick and easy idea generation sessions for early design. The way of thinking and acting in an agile way is very different from a traditional development logic, and its implementation is found to be much harder than companies tend to expect [19]. One important insight is that neither top-down nor bottom-up initiatives might be successful. Instead, an agile mindset is pervasive and includes people’s acceptance to work towards an unpredictable end state [19]. The design thus needs to be supported by quick and effective communication between actors, e.g., clients, managers, and developers. The accomplishment of appropriate communication builds upon the application of empathic principles [40]. Examples of empathic principles are understanding why/the purpose, instilling formative progress, sustaining motivated people by addressing creative design challenges, and embedding re-learning in procedures [41]. In sum, the use of agile methods needs an organizational culture that allows for proactive learning in order to achieve continuous improvements [16,42].

Design thinking and its agile methods [25,43,44] have, over time, received increased interest from manufacturing firms as a way to intensify innovation and to make better use of the practical insights of real user situations in early design [45]. The introduction of design thinking is expected to be eased due to a fit to the already established lean manufacturing and flexible manufacturing system ideas [46].

3.1. Teamwork: Essential for Agile Methods

Sequential development models indicate that work can be a structured and plan-driven, stepwise process, rather than the “battlefield situation” that it actually is [47]. Takeuchi and Nonaka [1] (p. 137) suggested that firms “take up rugby” as a metaphor for guiding teamwork in innovation projects. The metaphor visualizes a coherent unit that passes the ball back and forth and uses different tactics to reach a goal. The rugby visualization gives a totally different impression of how work is done, compared to looking at a sequential, segmented model. The idea of this kind of teamwork is to make the best use of the total project time, while keeping customer value at the center [48]. However, the whole organization, at all levels, needs to be involved in the full implementation of human-centered and agile methods [49].

3.2. Characteristics of Agile Methods

Previous studies have found that companies have implemented new design methods without recognizing them as agile [50]. If these methods were only implemented as processes or methods, this may be because they were built upon a mindset that is not evident. Agility is rooted in the characteristics originally suggested by Takeuchi and Nonaka [1] (pp. 138–144). The six characteristics have to be seen as a whole, i.e., each piece does not solely result in a complete implementation. The characteristics presented here, which also were found in the empirical material, describe additional standpoints related to design and innovation processes.

• Built-in instability: the development starts, not from a detailed design brief, but rather from a broad vision or general strategic direction. The team will experience a wide degree of freedom, but it is also challenging to develop achievable sub-goals for their task. This is related to the open innovation situation in early design, which is needed for solutions that lead to disruption in businesses [51]. Preserving ambiguity is a key activity for finding radically new and innovative solutions to the wicked design problems [20]. Typically, actions that involve searching and exploring these situations include framing and reframing the problem [27], as well as assuming new rules [52].
• Self-organizing project teams: the agile team has to show three specific conditions: (i) autonomy, which means that top management should provide guidance, a budget, and authorize the task, while imposing limited involvement in the actual task; (ii) self-transcendence, which means the capacity to drive exploration and discovery as part of the quest for novel results; and (iii) cross-fertilization, which means having the skills to interact truly with a wide variety of elements, e.g., bridging business, design, and development [53]. Sull and Spinosa [54] suggest committing to a promise, which takes its form in an open discussion between those involved. They will be more engaged and motivated to collaborate and deliver, since the promise has been made public to peers and managers.
• Overlapping development phases: agile teamwork has to generate a unique rhythm of concurrent progress, called a pulse. The sense of a pulse can be discerned as a disagreement between diverging activities, e.g., idea generating, and converging activities, e.g., integrating or synthesizing. If there is a sudden halt in the pulse, something has gone wrong. If no one dares to confront the situation, the project will become yet another business-as-usual approach. Thus, the conflicts and tensions between standpoints should not be a reason for finding a convenient consensus. Kaner et al. [55] name this “battle” the “groan zone” and conclude that teams that are capable of managing conflicting views will innovate better and come up with radically new ideas.
• “Multi-learning”, which is based on empathic learning in two dimensions: (i) across several levels (individual, team, and organization); and (ii) across multiple functions. It is important to allow for different types of individual learning (observations, surveys, readings, etc.) and to share the lessons learned across individuals and teams. This type of “across” capability is in line with T-shaped competences [56], i.e., people having a depth in one expertise area, while having a personality that is capable of integrating multiple perspectives to benefit the design work. In relation to this, it is suggested that job careers should match changed business environments, rather than following a linear progression [57].
• Subtle control, which relates to autonomy, i.e., letting the team work on their own, but without abandoning them. Management has the responsibility to, for example, monitor group dynamics as best they can by adding or subtracting members when needed, creating an open work environment, encouraging the team to interact with customers to observe and listen to what they have to say, and turning mistakes into lessons learned, which are captured in success stories. The notion of guided emergence describes how managers can support self-organizing teams, i.e., enabling a work environment that is based on the team’s behavior and own organization. This is not a top-down, bottom-up, or any other type of imposed order [57].
• Transfer of learning: the dissemination of the lessons learned outside the team and project. This can be achieved by members moving to another project or by converting lessons learned into success stories. However, there is a danger of taking success stories too far, as it can put the flexibility and possibilities for adaptations at risk. Unlearning old lessons is important and can be achieved by, for example, problematizing or confronting aspects that are taken for granted. Active listening, critical thinking, and supervising self and others are suggested as key job qualifications in the digital era [58].

The fixed focus on innovation, rather than routine work, is important for new product and service development, but there are a number of problems. For example, Horlach and Drechsler [59] present a number of paradoxes and conclude that there is a difference in “doing agile” in the sense of following such methods and “being agile” in the sense of continuously improving the agility of the work and organization. Based on these two perspectives, it is suggested that the methods can first be introduced by “doing agile”, but this will not bring about organizational changes, until it is turned into “being agile” [59]. Other examples of problems are related to having or gaining experiences [59]. Positive experiences can originate from previous work in traditional design situations. If so, a preference for stability and predefined requirements become barriers for implementation. However, project members can also become too comfortable with certain agile methods, thus introducing inertia when using them in all types of design situations [59]. On the topic of problems with self-organization and autonomy, a split between (a) getting things done, or exploitation or incremental innovation, and (b) promoting change, or exploration or radical innovation, can occur. Thus, the projects’ results are threatened. These paradoxes, or tensions, are found not to be negative; rather, they can form a basis for organizational learning and change processes [59].

4. Discussing Empirical Insights into Implementation

In the following, excerpts from the informants are interpreted and reflected upon. The aim is, in accordance with how qualitative data are organized, to provide a description of implementation issues, which is grounded in the informants’ own words and in the connections to theoretical characteristics that emerged from the analyses, i.e., as presented in Section 3.2.

The informants have in common that they discover agile methods when they “stumble upon a book”, start reading it, and find that the methods can solve the problems they have in their daily work. From this, the first step, they continue to search for additional books and information. They describe this approach as “old school”, referring to their experiences from university education. Yet, what they describe can also be interpreted as having a learning interest and capability, i.e., a multi-learning characteristic [1]. They describe, further, that they take “something” that they find useful from the literature, adapt it to fit their context, and rename it themselves. This is due to them perceiving that a “debate” in defining words and concepts does not lead anywhere. Instead, they seek to encourage a dialogue about the method’s usefulness in relation to their current design task, thus introducing a method, albeit under subtle control. By doing so, the introduction is not imposed, either through a top-down or bottom-up approach; it is rather an example of guided emergence [57]. The dialogue and test can also result in the team discarding the method, yet it is at least introduced as an alternative, which can be useful in future situations. Thus, the informants indicated that measures need to be taken to achieve a transfer of learning [1].

The informants perceived that the companies generally focus on getting projects started, rather than finishing them. It is easier to declare, “we have actually started”, than “we have not done anything yet” (id.no.6). It was also explained that there were consequences for not starting, but very few for not delivering. In projects that were slow in the beginning, it was found to be practical to benchmark other companies’ methods, which means to just copy something, adjust it, rename it, and start doing something. The consequence of separating the philosophy or mindset from the agile methods was explained by one informant. He said that he certainly applies agility differently than the others; he combines methods differently; and he can only be successful if the underlying meaning is understood. Thus, the difference between “doing agile” and “being agile” is identified when implementing methods [59].

The informants experienced situations when members, one or several, of the design team were convinced that there was only one methodology and that one “works well for everything” (id no. 1), no matter if the task is radical innovation or incremental new product development. In order to change the situation, one informant found it better to communicate what the team should accomplish by using “any kind of support”, being clear regarding the requirements for teamwork, “…collaborate actively, communicate well”, explaining what kind of support they will get from him as project leader, and “...empower people and teams to make decisions, so as to get things done…” (id.no.1). In fact, this means exercising subtle control and self-organization [1]. Other informants describe the implementation efforts as a “sort of internal agile work” (id.no.12), since the methods are not used “by-the-book” (id.no.9). Such expressions indicate that the informants apply agile methods but indicate that the rationale is not internalized in the organization, i.e., they are “doing agile” [59]. One informant described the consequences of agile methods, which he adapted differently for each design task: “… we tinker around with our approach and try to adapt it in accordance with the task. The price we have to pay is that it becomes a bit messy every time”. He continues his explanation by indicating that “…what we gain is better transparency and better communication in the project team”, i.e., the team is “being agile”. Additionally, this indicates the important built-in instability and overlapping development phases [1], which are key characteristics of agile methods. Finally, the informant concluded that agile methods may seem messy, but “… it is actually not about less structure, but more structure. It takes a lot of discipline...” (id.no.16).

Overall, the companies involved in the study established process-oriented development approaches. Process orientation means, in this case, that there is a focus on standards, roles, and analyses to improve workflows and organization. However, one informant explained the challenges related to such processes: “I just move information… it is actually a problem. Information does not flow as freely as one might think. My work should not be necessary, but it is.” (id.no.12). The informants positioned agile methods to the “level below” the formal process. One informant clarified the difference between formal process models and day-to-day work: “there are formalized ways, which are explained in documents and perfectly in order, yet what this means in practice—that’s a big difference!” (id.no.4).

One informant indicated that in situations where new methods are introduced to replace the established ones, prestige by top managers becomes a barrier. He explained the problem: managers are trained in some tradition, and they get too attached to it, seeing it as the only way to do things. Additionally, there is a misconception among managers that they become redundant when using agile methods, and the team self-organizes. He concluded that “…what has happened is that the world has evolved in such a way that it is not even possible to manage work as we are used to, but organizations have not figured that out yet. […] The boss leaning over you and controlling every detail… which, of course, does not work… trying to watch every move that anybody makes” (id.no.5). Instead, skills in leading self-organizing project teams were explained as “keeping an eye on the process” (id.no.1), but not to interfere with how things are being done. Hence, subtle control [1] was found to be important.

The informants identified that they, as project leaders of design and development teams, had to shift between different types of leadership, i.e., make quick decisions in critical situations, increase motivation in most cases, and all the while be a role model for team workers. How to manage these shifts was explained by one informant: “…as a leader, you have to get some dirt under your fingernails, doing tasks that are not formally stated in your work description. Additionally, as a leader, when you do so, you will inspire a programmer to also do testing, and vice versa, thus encouraging the formally subordinate role, as a tester, to provide comments on coding” (id.no.16).

The informants said that existing products and services are “of course” the bread and butter for the companies, at least in stable conditions. One informant explained his previous experiences of competition: “We were reactive in our way of approaching the opportunities, which resulted in us being followers, and the thing is—we have no ambition to be that!” (id.no.15). Bringing about changes in the organizational culture in order to improve the design process was considered by the informants to be one of the main challenges: “So, we hire [an expert in agile methods], we bring him in, and he fails miserably. The reason why he fails is that he knows how to function in an environment that is already using agile methods, but he has no skills associated with the transformation of work” (id.no.1). One informant described his personal experiences in relation to his own failure: “…there is a culture to make fun of those who fail, you know, like poking fun during coffee breaks and so. It is meant to be fun, but you know, it touches one so strongly—no one wants to be mocked by their equals” (id.no.15).

A major difference between agile methods, particularly those related to idea generation, was described by one informant: “We commonly used long, endless Excel documents. Everyone said that they did not provide an overview or motivation. This is not to say that they are in fact boring. Instead, I suggested that the team draw a landscape showing areas for our products, what’s on the mountain, in the darkest forest, etcetera. This immediately created both an overview and creativity, so we could dig deeper into those percentages that did matter” (id.no.15). Additionally, visual project status reporting and so-called standups were found to be an appealing feature of agile methods: “I think that it is from this unpleasant experience [being seen by his colleagues to be late to work] that I learned what the approach is…maybe it is born here! The sense of urgency and that work has to be done” (id.no.14).

The informants had difficulty describing successful implementation. How could they know that agile methods had been better than the ones they were used to applying? They described the importance of first-hand experience: “How can I describe when a team gets momentum and everything just works!? That’s tricky, you have to experience it!” (id.no.13). Even though successful implementations in the team and its design processes were evident for the organization, the informants were not sure that it could be used independently of their efforts: “If we [the team] would not do it, would it continue? I am not sure.” (id.no.6). Thus, the informants identified the transfer of learning [1] as important for internalizing the agile mindset.

The analyses of the empirical material made it feasible to identify that there were signs of a missing underpinning logic of agile methods, i.e., could be connected to theory as described in Section 3.2, and exemplified here by the respondents’ excerpts. Thus, the logic of being agile was not explicitly implemented or integrated in the projects but was rather perceived as a challenge.

5. Conclusions

The purpose of the presented study was to investigate project leaders’ efforts to implement agile methods in their current design processes. The study is based on the background of changing business environments for product and service development companies, particularly due to the digitalization and servitization of products. These drivers insist on methods that support radical innovation and user orientation, i.e., agile methods for early design activities. This study shed light on the challenges and barriers associated with the implementation of agile methods, which the project leaders experienced as problematic. The findings describe some challenges and also how the project leaders have struggled to overcome them.

In sum, the study indicates some implications for practice. First, there might be a lack of approval, not only from top managers but also from critical peers. Second, the organizational culture has to be prepared to allow self-organization, trust, and different leadership styles that truly support teamwork. Third, there might be a lack of company-specific success factors to support agile methods. In its current state, the theory mainly suggests that agile methods are useful, but there is limited support for how to fully implement them, i.e., how to be agile and how to manage resistance to change in project work. Only the latter perspective is addressed by, e.g., psychology. However, in future research, we suggest the engineering design field to contribute with a cross-disciplinary perspective on these issues. This study provides one such contribution to engineering design, adding a socio-technical point of view, which provides insights into how project leaders interpret their challenges when managing established development procedures that are simultaneously in need of a change of methods. Qualitative data make it possible to understand the reasoning in a situation, which is important for uncovering why certain actions are taken. Naturally, such a study is prevented from drawing generalizations on project leadership in all situations. Thus, another suggestion for future research is to measure the perceived degree of different challenges—for example, which characteristics of being agile are harder to implement, and whether there are any that can be more easily implemented.

Finally, some advice grounded in the informants’ experiences can be provided to support practitioners, e.g., obtain inspiration from theory and research, implement single methods stepwise, and adapt new methods to the company’s jargon by renaming them. However, this might only be successful if it is understood that there is a difference between “doing agile” and “being agile”, as suggested by Horlach and Drechsler [59].