Next Article in Journal
A Method for Computing Conceptual Distances between Medical Recommendations: Experiments in Modeling Medical Disagreement
Next Article in Special Issue
Analysis of Vertical Stiffness Characteristics Based on Spoke Shape of Non-Pneumatic Tire
Previous Article in Journal
A Regularized Mixture of Linear Experts for Quality Prediction in Multimode and Multiphase Industrial Processes
Previous Article in Special Issue
A Theoretical Model with Which to Safely Optimize the Configuration of Hydraulic Suspension of Modular Trailers in Special Road Transport
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:

Realization of Agile Methods in Established Processes: Challenges and Barriers

Digital Services and Systems, Luleå University of Technology, SE-97187 Luleå, Sweden
Department of Industrial Engineering, UiT The Arctic University of Norway, NO-8514 Narvik, Norway
Department of Mechanical Engineering, Blekinge Institute of Technology, SE-37179 Karlskrona, Sweden
Author to whom correspondence should be addressed.
Appl. Sci. 2021, 11(5), 2043;
Submission received: 22 January 2021 / Revised: 21 February 2021 / Accepted: 22 February 2021 / Published: 25 February 2021
(This article belongs to the Special Issue New Trends in Design Engineering)


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.
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” ( 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…” ( In fact, this means exercising subtle control and self-organization [1]. Other informants describe the implementation efforts as a “sort of internal agile work” (, since the methods are not used “by-the-book” ( 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...” (
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.” ( 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!” (
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” ( Instead, skills in leading self-organizing project teams were explained as “keeping an eye on the process” (, 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” (
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!” ( 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” ( 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” (
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” ( 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” (
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!” ( 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.” ( 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].

Author Contributions

Conceptualization, J.L. and Å.E.; Investigation, J.L., Å.E. and A.L.; Project administration, Å.E. and A.L.; Resources, J.L., Å.E. and A.L.; Writing—original draft J.L., Å.E. and A.L. All authors have read and agreed to the published version of the manuscript.


This research was funded by The Kamprad Family Foundation for Entrepreneurship, Research & Charity at Luleå University of Technology, and The Knowledge Foundation in Sweden Through the Model-Driven Development and Decision Support+ (MD3S+) research profile at Blekinge Institute of Technology.

Informed Consent Statement

Informed consent was obtained from all subjects involved in the study.

Data Availability Statement

Anonymized data is available in print outs upon request to the corresponding author.

Conflicts of Interest

The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.


  1. Takeuchi, H.; Nonaka, I. The new product development game. Harv. Bus. Rev. 1986, 64, 137–146. [Google Scholar]
  2. Smith, R.C.; Iversen, O.S. Participatory design for sustainable social change. Des. Stud. 2018, 59, 9–36. [Google Scholar] [CrossRef]
  3. Camarinha-Matos, L.M.; Fornasiero, R.; Ramezani, J.; Ferrada, F. Collaborative Networks: A Pillar of Digital Transformation. Appl. Sci. 2019, 9, 5431. [Google Scholar] [CrossRef] [Green Version]
  4. OECD. Data-Driven Innovation: Big Data for Growth and Well-Being; OECD Publishing: Paris, France, 2015; Available online: (accessed on 4 February 2021).
  5. Bucciarelli, L.L. Reflective practice in engineering design. Des. Stud. 1984, 5, 185–190. [Google Scholar] [CrossRef]
  6. Cross, N. Expertise in design: An overview. Des. Stud. 2004, 25, 427–441. [Google Scholar] [CrossRef] [Green Version]
  7. Smart Services Welt. Smart Service Welt—Recommendations for the Strategic Initiative Web-based Services for Businesses, Final Report; acatech: Berlin, Germany, 2015; Available online: (accessed on 4 February 2021).
  8. Tukker, A.; Tischner, U. Note from the Field: Product-Services as a Research Field: Past, Present and Future. Reflections from a Decade of Research. J. Clean. Prod. 2006, 14, 1552–1556. [Google Scholar] [CrossRef]
  9. Goedkoop, M.; van Halen, C.J.G.; Te Riele, H.R.M.; Rommens, P.J.M. Product Service Systems, Ecological and Economic Basics, the Dutch ministries of Environment (VROM) and Economic Affairs (EZ). Retrieved Sep. 1999, 30, 2014. [Google Scholar]
  10. Manzini, E.; Vezzoli, C. Product-Service Systems and Sustainability: Opportunities for Sustainable Solutions, Report UNEP; UNEP-United Nations Environment Programme: Nairobi, Kenya, 2001. [Google Scholar]
  11. Vargo, S.L.; Lusch, R.F. Evolving to a new dominant logic for marketing. J. Mark. 2004, 68, 1–17. [Google Scholar] [CrossRef] [Green Version]
  12. Raddats, C.; Kowalkowski, C. A reconceptualization of manufacturers’ service strategies. J. Bus. Bus. Mark. 2014, 21, 19–34. [Google Scholar] [CrossRef] [Green Version]
  13. Akasaka, F.; Chiba, R.; Shimomura, Y. An engineering method for supporting customer-oriented service improvement. In Proceedings of the 3rd CIRP International Conference on IPS2, Braunschweig, Germany, 5–6 May 2011. [Google Scholar] [CrossRef]
  14. Frishammar, J.; Dasselaar, M.; Parida, V. When product meets service: Digitalizing industrial innovation. Ericsson Bus. Rev. 2015, 2. Available online: (accessed on 4 February 2021).
  15. Rittel, H.; Webber, M. Dilemmas in General Theory of Planning. Policy Sci. 1973, 4, 155–169. [Google Scholar] [CrossRef]
  16. Akyazi, T.; Alvarez, I.; Alberdi, E.; Oyarbide-Zubillaga, A.; Goti, A.; Bayon, F. Skills Needs of the Civil Engineering Sector in the European Union Countries: Current Situation and Future Trends. Appl. Sci. 2020, 10, 7226. [Google Scholar] [CrossRef]
  17. Jiménez, V.; Afonso, P.; Fernandes, G. Using Agile Project Management in the Design and Implementation of Activity-Based Costing Systems. Sustainability 2020, 12, 10352. [Google Scholar] [CrossRef]
  18. Ciric, D.; Lalic, B.; Gracanin, D.; Tasic, N.; Delic, M.; Medic, N. Agile vs. Traditional Approach in Project Management: Strategies, Challenges and Reasons to Introduce Agile. Procedia Manuf. 2019, 39, 1407–1414. [Google Scholar] [CrossRef]
  19. Cohn, M. Succeeding with Agile: Software Development Using Scrum; Edwards Brothers in Ann Abor: Ann Arbor, MI, USA, 2013. [Google Scholar]
  20. Leifer, L.J.; Steinert, M. Dancing with ambiguity: Causality behaviour, design thinking, and triple-loop-learning. Inf. Knowl. Syst. Manag. 2011, 10, 151–173. [Google Scholar] [CrossRef] [Green Version]
  21. Stewart, S.; Giambalvo, J.; Vance, J.; Faludi, J.; Hoffenson, S. A Product Development Approach Advisor for Navigating Common Design Methods, Processes, and Environments. Designs 2020, 4, 4. [Google Scholar] [CrossRef] [Green Version]
  22. Lugnet, J.; Ericson, Å.; Larsson, T. Design of Product–Service Systems: Toward an Updated Discourse. Systems 2020, 8, 45. [Google Scholar] [CrossRef]
  23. Sy, D. Adapting usability investigations for agile user-centered design. J. Usabil. Stud. 2007, 2, 112–132. [Google Scholar]
  24. Ferreira, J.; Sharp, H.; Robinson, H. Agile Development and User Experience Design Integration as an on-going Achievement in Practice. In Proceedings of the Agile Conference, Dallas, TX, USA, 13 August 2012. [Google Scholar]
  25. Brown, T. Design Thinking. Harv. Bus. Rev. 2008, 86, 84–92. [Google Scholar] [PubMed]
  26. Kelley, T. The Art of Innovation. Lessons in Creativity from IDEO, America’s Leading Design Firm; Currency and Doubleday: New York, NY, USA, 2001. [Google Scholar]
  27. Dorst, K. The core of ’design thinking’ and its application. Des. Stud. 2011, 32, 521–532. [Google Scholar] [CrossRef]
  28. Miles, M.B.; Huberman, A.M. Qualitative Data Analysis: An Expanded Sourcebook; Sage Publications: Thousand Oaks, CA, USA, 1994. [Google Scholar]
  29. Yin, R.K. Case Study Research: Design and Methods, 5th ed.; Sage Publications Ltd.: London, UK, 2014. [Google Scholar]
  30. Rooke, D.; Torbert, W.R. Seven Transformations of Leadership. Harv. Bus. Rev. 2005, 41, 41–57. [Google Scholar]
  31. Larsson, A. Banking on social capital: Towards social connectedness in distributed engineering design teams. Des. Stud. 2007, 28, 605–622. [Google Scholar] [CrossRef] [Green Version]
  32. Courtney, H.; Kirkland, J.; Viguerie, P. Strategy under uncertainty. Harv. Bus. Rev. 1997, 75, 67–79. [Google Scholar]
  33. Mason, J. Qualitative Researching, 2nd ed.; Sage publications Ltd.: London, UK, 2002. [Google Scholar]
  34. Fontana, A.; Frey, J. The interview: From structured questions to negotiated text. In Handbook of Qualitative Research, 2nd ed.; Denzin, N., Lincoln, Y., Eds.; Sage: Thousand Oaks, CA, USA, 2000; pp. 645–672. [Google Scholar]
  35. Kvale, S. Interviews: An Introduction to Qualitative Research Interviewing; Sage: Thousand Oaks, CA, USA, 1996. [Google Scholar]
  36. Patton, M.Q. Qualitative Research & Evaluation Methods; Sage Publications: Thousand Oaks, CA, USA, 2002. [Google Scholar]
  37. Janesick, V.J. The choreography of qualitative research design: Minutes, improvisations, and crystallization. In Handbook of Qualitative Research, 2nd ed.; Denzin, N., Lincoln, Y., Eds.; Sage: Thousand Oaks, CA, USA, 2000; pp. 379–399. [Google Scholar]
  38. Silverman, D. Doing Qualitative Research, 4th ed.; Sage Publications Ltd.: London, UK, 2013. [Google Scholar]
  39. Dorta, T.; Kinayoglu, G.; Boudhraâ, S. A new representational ecosystem for design teaching in the studio. Des. Stud. 2016, 47, 164–186. [Google Scholar] [CrossRef]
  40. Cockburn, A. Agile Software Development: The Cooperative Game; Addison-Wesley: Boston, MA, USA, 2007. [Google Scholar]
  41. Womack, J.P.; Jones, D.T. Lean Thinking—Banish Waste and Create Wealth in Your Corporation. J. Oper. Res. Soc. 2003, 48, 1148. [Google Scholar] [CrossRef]
  42. Achanga, P.; Shehab, E.; Roy, R.; Nelder, G. Critical success factors for lean implementation within SMEs. J. Manuf. Technol. Manag. 2006, 17, 460–471. [Google Scholar] [CrossRef]
  43. Harrison, A. Making and Thinking: A study of intelligent activities. In The Massachusetts Institute of Technology; Rowe, P.G., Ed.; Harvester Press: Hassocks, UK, 1978. [Google Scholar]
  44. McKim, R.H. Experiences in Visual Thinking; Brooks/Cole Publishing Company: Monterey, CA, USA, 1972. [Google Scholar]
  45. Patnaik, D.; Becker, R. Needfinding: The why and how of uncovering people’s needs. Des. Manag. J. 1999, 10, 37–43. [Google Scholar] [CrossRef]
  46. Ramesh, G.; Devadasan, S.R. Literature review on the agile manufacturing criteria. J. Manuf. Technol. Manag. 2007, 18, 182–201. [Google Scholar] [CrossRef]
  47. Highsmith, J. What is Agile Software Development? Crosstalk: J. Def. Softw. Eng. 2002, 15, 4–9. [Google Scholar]
  48. Schwaber, K.; Sutherland, J. The Scrum Guide; The Definitive Guide to Scrum: The Rules of the Game. 2020. Available online: (accessed on 4 February 2021).
  49. Lee, J.W.; Daly, S.R.; Huang-Saad, A.; Rodriguez, G.; Seifert, C.M. Cognitive strategies in solution mapping: How engineering designers identify problems for technological solutions. Des. Stud. 2020, 71, 100967. [Google Scholar] [CrossRef]
  50. Leite, M.; Braz, V. Agile manufacturing practices for new product development: Industrial case studies. J. Manuf. Technol. Manag. 2016, 27, 560–576. [Google Scholar] [CrossRef]
  51. Brown, T. Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation; HarperCollins Publishers Inc.: New York, NY, USA, 2011. [Google Scholar]
  52. Dong, A.; Garbulo, M.; Lovallo, D. Generative sensing: A design perspective on the microfoundations of sensing capabilities. Calif. Manag. Rev. 2016, 58, 97–117. [Google Scholar] [CrossRef]
  53. Fernald, L.W., Jr.; Solomon, G.T.; Tarabishy, A. A new paradigm: Entrepreneurial leadership. South. Bus. Rev. 2005, 30, 1–10. [Google Scholar]
  54. Sull, D.N.; Spinosa, C. Promise-based management: The essence of execution. Harv. Bus. Rev. 2007, 85, 79–86. [Google Scholar]
  55. Kaner, S.; Lind, L.; Toldi, C.; Fisk, S.; Berger, D. Facilitator’s Guide to Participatory Decision-Making, 3rd ed.; Jossey-Bass: San Francisco, CA, USA, 2014. [Google Scholar]
  56. Winograd, T. Design education for business and engineering management students: A new approach. Interactions 2008, 15, 44–45. [Google Scholar] [CrossRef] [Green Version]
  57. Lichtenstein, B.M.B.; Mendenhall, M. Non-linearity and response-ability: Emergent order in 21st-century careers. Hum. Relat. 2002, 55, 5–32. [Google Scholar] [CrossRef]
  58. World Economic Forum. The Future of Jobs: Employment, Skills and Workforce Strategy for the Fourth Industrial Revolution. In Global Challenge Insight Report; World Economic Forum: Geneva, Switzerland, 2016; Available online: (accessed on 4 February 2021).
  59. Horlach, B.; Drechsler, A. It’s Not Easy Being Agile: Unpacking Paradoxes in Agile Environments. In Agile Processes in Software Engineering and Extreme Programming—Workshops. XP 2020. Lecture Notes in Business Information Processing; Paasivaara, M., Kruchten, P., Eds.; Springer: Cham, Switzerland, 2020; pp. 182–189. [Google Scholar] [CrossRef]
Table 1. Overview of the businesses and positions of the informants.
Table 1. Overview of the businesses and positions of the informants.
IdType of BusinessExpertise Area
1Software developmentAgile expert
3Manufacturing industryInnovation designer
4Construction industryEngineering services
5Management consultancyCEO and founder
6Industrial electronicsR&D manager
7Manufacturing industryIT development
8Industrial electronicsHuman resources
9Management consultancyVisionary designer
10Mechanical engineeringCEO
11Technical innovationProcess developer
12IT consultancyBusiness developer
13Process industryApplication developer
14Production industryGlobal developer
15Manufacturing industryProduct unit manager
16Medical technologyR&D manager
17Incubator and science parkBusiness model developer
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

Lugnet, J.; Ericson, Å.; Larsson, A. Realization of Agile Methods in Established Processes: Challenges and Barriers. Appl. Sci. 2021, 11, 2043.

AMA Style

Lugnet J, Ericson Å, Larsson A. Realization of Agile Methods in Established Processes: Challenges and Barriers. Applied Sciences. 2021; 11(5):2043.

Chicago/Turabian Style

Lugnet, Johan, Åsa Ericson, and Andreas Larsson. 2021. "Realization of Agile Methods in Established Processes: Challenges and Barriers" Applied Sciences 11, no. 5: 2043.

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop