Emerging field or passing fashion? A case study of Agile-Stage-Gate model in innovation processes

Purpose – Agile methods are increasingly being applied in the contexts of innovation beyond traditional information technology (IT) and physical product development projects, such as when process improvements are being implemented. Nevertheless, this phenomenon is still recent and little addressed in the literature, with few descriptions of empirical cases. This study aims to address this gap. Design/methodology/approach – This multiple case study aims to present and discuss the application of Agile practices embedded in large companies ’ innovation value chains, focusing on improvements of business processes. The following research question is pursued: How are large companies applying elements of Agile methods to their innovation processes when implementing incremental improvements in their operational processes? Based on the idea that the Agile-Stage-Gate model is an alternative to this challenge, this study investigates the application of this hybrid model in two large Brazilian companies by presenting their idiosyncrasies, lessons learned, adaptations, challenges and benefits. Findings – Overall, it was observed that the experience with the application of the Agile-Stage-Gate model is positive for these companies, with better customer engagement, easier project control and increased productivity of the project team. Originality/value – ForthoseaimingtoimplementtheAgile-Stage-Gatemodel,thispaperidentifiesthemain adaptationsmadeinordertocombinethepuristapproachesandcriticalsuccessfactorsforitsimplementation.


Introduction
Based on the idea that the application of the so-called Agile-Stage-Gate hybrid model has been an increasing alternative used by companies in their innovation processes (Cooper, 2021), we used this approach as a basis for discussing how to apply Agile practices in the specific context of the development of business process innovations. The Agile-Stage-Gate model is a hybrid one for the product development process combining values and tools of the Agile project management approach with the traditional Stage-Gate (SG) innovation process (Cooper, 2016). Because both models work with seemingly contradictory assumptions and conceptions, it has been agreed to consider the Agile-Stage-Gate model as a hybrid one.
The objective of the Agile-Stage-Gate model is to contribute to improving the performance of the product development processes. The justification for better performance is precisely in the combination of flexibility, speed and productivity, all attributes often associated with the Agile approach, with focus, structure and control, which are characteristics of the Stage-Gate model (Cooper, 2016;Sommer, Hedegaard, Dukovskapopovska, & Steger-Jensen, 2015).
The discussion on Agile methods had its origin in the software industry (Cooper, 2016). Several specialists, each one with a specific trajectory in software development models (e.g. Scrum, Extreme Programming), gathered themselves and condensed the common values and principles of their methodologies (Dyba & Dingsøyr, 2008). The result of these interactions is expressed in the Manifesto for Agile Software Development, a document comprising a mindset with values and principles of Agile project management (Beck et al., 2001). Serrador and Pinto (2015) identified the existence of a positive relationship between the application of these approaches and a project's successful outcome. Complementarily, Bianchi, Marzi, and Guerini (2018) investigated the combination of Agile and traditional practices in software development projects and concluded that, specifically for the software industry, the pure Agile approach is always more effective than the traditional (e.g. Stage-Gate) and hybrid (e.g. Agile-Stage-Gate) ones.
In the wake of the successful implementation of these methods in the software industry, the traditional manufacturing industries have also started experiments by incorporating these principles and applying Agile practices to their product development processes (Conforto, Salum, Amaral, Silva, & Almeida, 2014;Sommer, Dukovska-popovska, & Stegerjensen, 2014). Large European IT companies which produce and trade hardware and software products started the hybridization of the methods by applying Agile practices to their traditional Stage-Gate processes. It was found that the hybrid model could offer good results, such as improvement of internal communication, more efficient planning and better customer feedback (Karlstr€ om & Runeson, 2005). Sommer et al. (2014) observed an increased performance of R&D processes in German manufacturing companies after they applied such a hybrid combination. The authors highlighted the following benefits from applying this method: gain of flexibility in the process, more efficient communication among the teams, a gain of productivity in the process, including during task prioritization and improvement in the team's motivation. Cooper (2021) also highlighted the gain of speed in the execution of innovation management processes with the application of the Agile-Stage-Gate model.
In this way, several authors sought to study practical cases in which the Agile-Stage-Gate model was applied beyond the development of software. In fact, studies on large industries with more than 1,000 employees (Brock, den Ouden, Langerak, & Podoynitsyna, 2020;Salvato & Laplume, 2020;Sommer et al., 2015) as well as on small ones with up to 100 employees and medium ones with up to 1,000 employees (Conforto & Amaral, 2016;Edwards, Cooper, Vedsmand, & Nardelli, 2019;Hirisatja, Surachaikulwattana, & Lohwongwatana, 2021) have been performed to assess the Agile-Stage-Gate model in the context of physical product development. Despite the increasing number of studies investigating the application of Agile methods to physical product development processes, this phenomenon continues being predominantly addressed in the scope of software development projects (Conforto et al., 2014;Ovesen, 2012;Serrador & Pinto, 2015). This is justified primarily due to the fact that physical products are difficult to be prototyped, tested and rapidly adjusted as they often depend on the structural adequacy of production lines and machinery used throughout the project management, which restricts the range of the studies with this focus (Cooper, 2016). As stated by , the hybrid model for physical product manufacturers is still a novelty and companies are learning how to use it in practice. According to the authors' best knowledge, however, no study on the application of the Agile-Stage-Gate model to improve business processes, here understood as a chain of coordinated activities to produce a product or a final service (Zarifian, 1994 as cited in Salerno, 1999), was found in the literature.

REGE
As a result, the benefits of applying the Agile-Stage-Gate model to innovation development not related to IT are backed in a few cases reported in the literature (Granato, Fischer, & van Trijp, 2022) and always from the perspective of producing final physical products rather than implementing business process improvements. In view of this, more evidence are necessary to evaluate the characteristics of the hybrid model, its benefits and its drawbacks, especially in the context of the implementation of business process improvements.
Therefore, the present study raises the following research question: how are large companies applying the elements of Agile methods to their development of business process improvements? One seeks to investigate which advantages and disadvantages are perceived with the application of the Agile-Stage-Gate model and which adaptations were made in order to conciliate the contradictions inherent to the pure models of project management.
By means of a study of multiple cases, this work sheds light on the application of the Agile-Stage-Gate model in large-sized companies which generate and implement business process improvements to enhance its operational efficiency. We expect to contribute to improving the understanding and spread of the knowledge acquired with empirical experiences in adopting hybrid processes of innovation development, thus collaborating with meeting the still open gap in the emerging literature on the advantages and disadvantages of using Agile methods in the context of innovation projects development not related to software development, as well as with improving the current application of Agile-Stage-Gate model in companies by contributing to managerial practice.

Theoretical background 2.1 Stage-Gate model
The Stage-Gate model is similar to the classical innovation management models reported in the literature (see Clark & Wheelwright, 1992;Goffin & Mitchell, 2005;Hansen & Birkinshaw, 2007) and covers a process of product development. This model is notoriously one of the most applied to product development processes by companies. This development emerges from a sequence of activities (stages) preceded by a decision point (gate), which defines whether an idea/project follows in the wake of the development, is cancelled or frozen (Cooper, 1994). This is a model which organizes the collection of information about a given project and systematically seeks validations as a way to reduce the risks as the product development project progresses. Figure 1 shows an illustrative view of the Stage-Gate process.
From the point of view of the organizational processes, the Stage-Gate model presupposes the existence of scale and standardization throughout the development of innovation ideas and projects. Therefore, these processes are more oriented toward the development of incremental innovations as this type of innovation requires a reduction of costs or improvement of the characteristics of the existing products and services.
In this sense, this model is more applicable in the context of little or no uncertainty, in which it is possible to obtain quantifiable knowledge on a possible future incident impacting the development of an idea or project, thus being more aligned with the notion of risk management rather than of uncertainty management (Knight, 2014). In effect, these models do not help define an approach to be applied in the context of more radical innovation (Silva, Bagno, & Salerno, 2014), since different situations can impose a break in the pre-defined sequence of activities due, essentially, to their high level of uncertainties.
Similarly, Salerno, Gomes, Silva, Bagno, and Freitas (2015) criticized the One-Size-Fits-All approach of these innovation models. The authors define eight different types of variations in the innovation process depending on the contingencies of each project. Of these eight models, three have interruptions in the activity flow and a process break resulting from the emergence of market or technology uncertainties, which demand a different management approach and cannot be addressed only in the procedural framework.
Despite these limitations, generic models of innovation processes in general and the Stage-Gate model, in particular, continue being widely cited in the literature and used in the industry for the management of incremental innovation projects. Therefore, new variations of this model, such as adaptation and incorporation of Agile methodologies, are a relevant object of study for discussion on the best ways of managing product development.
2.2 Agile methodologies and scrum 2.2.1 Agile methodologies. There are several alternative methodologies for code development and project management in the software industry questioning the efficacy of the traditional project management methods in generating value for customers. The high cost of controlling changes throughout the project development has been the issue addressed by these methodologies .
Agile methodologies are differentiated from the traditional project management approaches, such as cascade management, in that they emphasize characteristics like continuous design, flexible scope, freezing of design specifications as late as possible, openness to uncertainties, interaction with customers and a different team organization. In addition, Agile methodologies are interactive and incremental as they seek to avoid standard approaches emphasizing anticipated design, freezing of specifications, fixed project scope and low interaction with the customer (Serrador & Pinto, 2015). Boehm and Turner (2003) highlighted and contrasted the most specific aspects of the Agile and classical/plan-oriented methodologies, as can be seen in Table 1.
The objective of this comparison is to show that there are preconditions in a project context indicating which management approach can be the most adequate. For example, if the project context is dynamic (i.e. many needs for changes), having less people in the team and an environment in which the culture of freedom and informality is valued, then the project management method is likely to be a more effective option with the Agile approach than with the traditional one. According to the authors who compared these approaches, a previous evaluation of the project context and its characteristics would be, therefore, a useful exercise for the selection of the most adequate approach.
A seminal reference for Agile methods is the Manifesto for Agile Software Development, which is a document proposing common values between different methodologies, thus being considered a hallmark of the diffusion of these methods (Beck et al., 2001). According to its authors, the following foundations are valued: (1) Individuals and interactions over processes and tools; (2) Working software over comprehensive documentation; (3) Customer collaboration over contract negotiation; (4) Responding to changes over following a plan.

REGE
To some extent, this set of values determines a relationship of priority between them as, for example, interactions with individuals facilitate the sharing of information and rapid response to changes when necessary. In the same way, it is possible to infer that working software increments allow to measure production speed and accelerate feedback about it. Collaboration with the customer encompasses the idea that all share the same final objective. In turn, the close participation of the customer makes responses to changes easier and speeds up the feedback about the work done. In this sense, it is important to accept that changes will occur, meaning that efforts with planning should be calibrated for a shorter horizon in order to avoid spending time planning deliveries which may become eventually obsolete.
Agile methodologies, however, are subject to several criticisms. Among them, one can cite: Agile development brings nothing significantly new as it had already been practised in the software industry in the 1960s (Merisalo-Rantanen et al., 2005 as cited in Dyba & Dingsøyr, 2008); lack of focus on architecture planning leads to non-optimized design decisions (Stephens & Rosenberg, 2003 as cited in Dyba & Dingsøyr, 2008); there is scarce scientific support for the assertions by the Agile community (Mcbreen, 2003 as cited in Dyba & Dingsøyr, 2008); and Agile methods work in the contexts of small project teams, whereas in the contexts of larger projects, other approaches are more appropriate (Cohen et al., 2004 as cited in Dyba & Dingsøyr, 2008).
Nevertheless, perhaps the main criticism of the Agile methods is that the term "Agile" has been often used for exclusively marketing purposes and in a prescriptive way rather than for enabling the implementation of a really flexible and adaptive approach according to the context to which they are applied (Fernandez & Fernandez, 2008).
Even recognizing that Agile methods are not applicable to all types of projects, some authors admit that such practices are valued for managing projects characterized by high Agile-Stage-Gate in business process innovation complexity, high volatility or unclear objectives and solutions (Fernandez & Fernandez, 2008). Consequently, these conditions for contexts of software development projects allow authors like Bianchi et al. (2018) to conclude that a pure Agile approach is always more effective for software companies than plan-oriented (Stage-Gate) or even hybrid (Agile-Stage-Gate) ones.
One can observe, therefore, vast evidence of the successful application of Agile methods to project management in the software industry. However, in addition to this, there are only a few studies exploring the use of Agile project methods by industries not related to IT (Conforto et al., 2014;. 2.2.2 Scrum. Scrum, on the other hand, is an Agile methodology with a focus on project management, especially those of difficult future planning. It is a framework aimed to help people cope with complex project problems by means of iterative and incremental approaches in order to optimize predictability and risk control. Scrum has a set of practices which make all the project's aspects visible to the team, thus allowing all its members to know how the project is evolving and, if necessary, to make corrections (Schwaber, 2004;Schwaber & Sutherland, 2017).
The heart of Scrum relies on the concept of sprint, that is, a fixed period of 3-4 weeks for the creation of an increment of a functional product. After a sprint is finished, a new one is initiated iteratively (Schwaber & Sutherland, 2017). In addition, Scrum consists of events, roles and artifacts. According to Schwaber and Sutherland (2017), the events are the following: (1) Sprint Planning; (2) Daily Scrum; (3) Sprint Review; (4) Sprint Retrospective The roles of Scrum are the following: (1) Product Owner (PO); (2) Scrum Master (SM); (3) Development Team (Dev Team).

Hybrid Agile-Stage-Gate model
Lastly, in the hybrid Agile-Stage-Gate model, the elements of the Stage-Gate approach are associated with the principles of Agile methodology in order to combine the benefits of flexibility and adaptation toward changes, associated with the use of Agile methodologies, and the standard, structured and scalable process of Stage-Gate-related innovation development (Cooper, 2016;Sommer et al., 2015).
Karlstr€ om and Runeson (2005), seeking to understand how large IT companies could incorporate Agile software development practices in their already established Stage-Gate processes, achieved an important insight by conducting a case study of three IT companies. Agile methods contribute to the Stage-Gate model by proving more granular planning and REGE control of daily activity. In other words, both methodologies are combined into different levels of control, that is, at the aggregate/macro level one uses the Stage-Gate model and at the granular/micro level one uses Agile practices to replace technical models of project processes. Sommer et al. (2015) investigated how manufacturing companies use this hybrid model and they developed a generic process framework representing graphically the combination of these methodologies. Figure 2 illustrates the generic phases of the hybrid model.
The Agile-Stage-Gate model embeds the Agile practices in its Stage-Gate macro phases for micro-planning by replacing the traditional tools and approaches of project management such as Gantt charts, critical path analysis, among others. And the Stage-Gate approach, at the macro level, provides means to coordinate several teams with different functions with the company's senior management (Bianchi et al., 2018;Cooper, 2016;Edwards et al., 2019).
There are studies conceptualizing the Agile-Stage-Gate model differently. Granato et al. (2022) present a variation in the model by defining a method for the systematic identification of conceptual divergences between the product development technical staff and potential customers. This method, which combines Stage-Gate techniques and Agile iterative approaches, contributes to identify and treat such divergences before the final phase of the innovation production.
Zu zek, Ku sar, Rihar, and Berlec (2020) added the theme of concurrent engineering literature to the discussion on Agile-Stage-Gate. Instead of working in sequential steps at the macro management level (Stage-Gate), one works with a degree of superposition of steps.
However, for the purposes of the present analysis, we worked on the general idea of the Agile-Stage-Gate model presented by Karlstr€ om and Runeson (2005), which is graphically represented in the study by Sommer et al. (2015), as shown in Figure 2.
Still, with regard to the Agile-Stage-Gate model for contexts not related to software development, there are authors addressing the hybrid model from the perspective of its implementation. Zasa, Patrucco, and Pellizzoni (2020), interviewing Agile coaches with experience in implementing Agile methods in traditional companies, and Albuquerque, Torres, and Berssaneti (2020), studying Agile practices in the construction industry, observed that there is an important cultural factor which must be overcome in order to implement a hybrid model, namely, lack of knowledge and leadership resistance to the Agile approach. The same difficulty is found in case studies on the Agile-Stage-Gate model Salvato & Laplume, 2020;Sommer et al., 2015). Silv erio, Trabasso, and Pereira Pessôa (2020) also highlight that leadership is important for the implementation of lean practices in productive processes.
Lastly, there are other studies in the literature examining the application of Agile-Stage-Gate practices for innovations not related to software. Case studies were performed to investigate whether and how the application of this hybrid model brings benefits to companies which couple Agile methods to their existing Stage-Gate processes. Overall, these studies evaluated positively the application of the model, showing that the main strengths identified were the following: (8) Higher levels of innovation (Salvato & Laplume, 2020).
As to the main challenges, the following were identified: (1) Difficulty to allocate fully dedicated resources (Cooper, 2016;Edwards et al., 2019;Sommer et al., 2015); (2) Costs with fully dedicated resources/structure and resources for synchronization of projects (Salvato & Laplume, 2020); (6) Evolution of the product design with flexible backlog (time, in the process, for freezing the design specifications) because adjustments of specifications are more complex for physical products than for software, as the latter requires re-writing codes only Edwards et al., 2019;Salvato & Laplume, 2020); (7) Materiality of the product in the sprint, since physical products are not easily dismembered into independent parts and their production is more complex (requiring materials and manufacturing infra-structure) than the development of software ; (8) Keeping the frequency of Daily Scrum meetings (Cooper, 2016;Edwards et al., 2019); (9) Redundancy of synchronization tools and reports of projects (no Agile-Stage-Gate is applied, but Agile methods are added to Stage-Gate) (Salvato & Laplume, 2020).
These difficulties require adaptations to some aspects of the Agile methodologies, such as: (1) Adjustments to agreements on results in the sprint. For physical products, it is more complex (compared to software) to prepare their delivery at the end of the sprint, meaning that partial deliveries should be agreed based on plans or concepts of prototypes (Cooper, 2016;Edwards et al., 2019);

REGE
(2) Functions of facilitators in spreading the Agile mindset within the company to make implementation easier Salvato & Laplume, 2020); (3) Variations in the sprint length for adequacy of the delivery of a physical product .
It is worth mentioning that, supposedly, it is possible to apply Agile practices to all steps of the Stage-Gate process, according to the framework shown in Figure 2. According to the case studies evaluating how manufacturing companies apply the Agile-Stage-Gate approach, totalizing 23 cases, the majority used Agile methods in all Stage-Gate steps. Table 2 lists the relation of cases by Agile application to the steps of the Stage-Gate process, as found in the literature.

Definition of the research method
To observe empirically the relationship between the above-mentioned concepts, we adopted a qualitative approach based on a multiple-case study. Voss, Tsikriktsis, and Frohlich (2002) state that a case study, as a research method, should be used when a phenomenon needs to be studied in its actual environment so that all the complexities involved can be clearly understood, mainly in the context of operation management. McCutcheon and Meredith (1993) show that a case study considers observation, deep examination and evaluation of one or more external objects, with the researcher having little control of the events surrounding them. However, its application to operation management presents restrictions because the lack of control of variables can limit the observation of the results. In this sense, because the case study method follows a bottom-up approach for building knowledge from real and particular situations, there is the risk of producing narrow or very little generalizable theories (Eisenhardt, 1989).
Taking into consideration that the application of hybrid models, which combine the principles of the Stage-Gate approach with those of Agile methodologies, is still little widespread in the real environment where it is practised, the case study is shown to be adequate as it allows deep analysis of the contexts where it is possible to observe its use as well as of the theoretical implications from the selected cases.

Presentation of cases
The teams (squads) working with some Agile method, as is the case of Scrum, were defined as analysis units. In addition, some criteria were used for selecting the cases, namely: Agile-Stage-Gate in business process innovation (1) For the squad to work, it has to be inserted in a Stage-Gate context for managing improvements/innovations in the company; and (2) The scope of the squad's work should be aimed at implementing business process innovations which are not related exclusively to software development.
As the phenomenon investigated is little widespread, according to the author's knowledge, the selection of companies followed an information-oriented approach. That is, the companies were selected based on the expected information provided by them (Flyvbjerg, 2006). In this way, from the authors' previous experience, two companies well-known to meet the selection criteria were added: a financing multinational company and a telecommunication multinational company. Table 3 summarizes the companies' characteristics and presents a brief context on how the hybrid model is used in each one for implementing innovation processes.

Data analysis and collection
The main data used in the present study were collected by semi-structured interviews with professionals directly involved in the Agile-Stage-Gate process. There were two moments of  Table 3.
Characteristics of the companies selected for study REGE interaction with each interviewee. The first interaction occurred during an interview aimed at better knowing in detail how the Scrum method was applied to projects for the improvement of business processes. These interviews lasted 2-3 h, on average. Next, a summary of the content was emailed to the interviewees so that they could validate the information given. The interviews were recorded if the interviewee allowed. The interview was divided into two phases. Initially, data on the interviewee's professional profile (i.e. function, responsibilities, among others), context and motivators for using Scrum to improve projects for processes/products and squad on which the interviewee acted were collected (i.e. name, scope, duration, among others).
The second phase was guided by a script of questions divided into three scopes. Initially, it was sought to understand the steps of the Stage-Gate process to identify, select, develop and implement improvements. Next, the particularities of the Scrum method applied were investigated, including similarities and adaptations in relation to the Scrum described in the literature and steps in which it occurred during the Stage-Gate process on a macro level. Lastly, questions were asked in order to capture the interviewee's critical view on the use of Scrum and hybrid Agile-Stage-Gate methods.
The full script of questions can be obtained from Supplementary Material 1, whereas the interviewee's profile and general characteristics of the squads can be found in Supplementary Material 2.
After conducting the interviews, the content of the records was transcribed, tabulated and codified (Nowell, Norris, White, & Moules, 2017). In Supplementary Material 3, one can find a non-exhaustive example of how the data collected were codified. The scope of the answers given by the interviewees and the themes present in the interview script are in the first level of codification, whereas the answers given by each interviewee and the application of codification are in the other levels.
After the codification exercise, the codified content of the interviews was critically read for identification of repetitions, convergence and divergence between the cases before being compared to the concepts addressed in the literature on Scrum and Agile-Stage-Gate.

Results and discussion
4.1 Results of the financing company 4.1.1 Stage-Gate characteristics. In the financing company, there is no formal improvement implementation process in the conventional Stage-Gate format. Notwithstanding, there is one for generating, selecting, developing and implementing incremental improvements. This process exists despite not being necessarily formalized and whose practices vary depending on the internal customer's demands.
The innovation macro-process for business process improvement has four phases as follows: generation and selection of ideas, scope refinement, development and tests and implementation.

(1) Generation and Selection of Ideas
The annual strategic planning by the executive board sets objectives and broad goals for each surperintendencythe internal customer for the Agile-Stage-Gate Squads. The superintendents, in turn, refine their objectives and assign quantitative goals to them (Objectives and Key Results -OKRs). The superintendents' evaluation of their OKRs determines the priority order for the annual objectives, which then become an ordered list of projects to be carried out.
Moreover, there is an additional source of ideas for business process innovation. The superintendency responsible for customer experience has assessment tools (i.e. Net Promoter Score) which constantly measure the user's experience. Negative variations in these indicators generate improvement proposals.

Agile-Stage-Gate in business process innovation
The selection of these improvements and their planning also takes place within the superintendency responsible for customer experience, in which an evaluation is performed based on an effort-benefit chart.
(2) Scope Refinement With the list of prioritized projects in hand, the superintendents articulate with the internal project office the formation of the squad by passing an initial version of the work scope to be followed in the year.
The formed squad, then, performs a series of activities to refine the scope of the first sprint before generating the backlog. Among these activities are the following: interviews, workshops and studies which do not follow the Scrum method. The members of the squad who perform this refinement are the majority of the project office.

(3) Development and Tests
Development occurs by using the Scrum method, in which iteration is applied with small cycles of information gathering, specifications and developments. Tests are also performed under the Scrum method.

(4) Implementation
Implementations vary with the type of delivery, but they are performed under the Scrum method. There are cases in which sprints are used to carry out training for internal customers, even including temporary monitoring of the operation under the new improved processes. There are also cases in which implementation is limited to presenting and delivering documents.

Agile characteristics. About the stages, it is observed that the agile practices performed in this company under the Scrum method occur in the phases of development/tests and implementation.
With regard to the sprints, they last from 2 to 4 weeks depending on the squad. The number of weeks is defined at the beginning of each sprint and can be adjusted, such as the addition of further weeks when one realizes that the number of weeks planned will not be enough for the due delivery.
Concerning the ceremonies, all squads perform planning, daily and review. Some squads sometimes do not perform retrospectives. As for the artifacts, the squads manage the backlog by using agile project management software as well as a burndown chart. Some squads, complementarily, rely on traditional tools for project management (e.g. Gantt chart) as a means to plan and control activities on the micro level. However, this application occurs in the final sprints, that is, when one has less complexity and more visibility of the expected activities. There are squads using the Kanban board in physical and digital forms, or even both, simultaneously.
Regarding the team, no squad has more than nine members. Overall, all have a product owner (PO) from the internal customer area and a SM from the project office, but a few have a fully dedicated PO. The Dev Team consists of one solution architect (with an IT profile), who accounts for the activities of automation programming, and process engineers and process analysts. These professionals belong to the project office. Still, the Dev Team is completed by internal customer analysts as well as by analysts from other areas (e.g. legal, sales or product). Most of the squads have full-time teams despite the fact that a few have them physically close.
Documentation exists when the deliverable refers to the process of re-design. When automation functionally is involved in the delivery, documentation is scarce.
4.1.3 Interviewee's critical view of the hybrid model. Concerning the advantages, the most relevant ones refer to Scrum, namely: (1) engagement of the internal customer with the project, since he or she is physically close; (2) visual management (Kanban board), which REGE facilitates visualizing the progression of the activities; and (3) perception of having more recurrent deliveries. The development delivery time was not reduced, but the practice to create recurring deliveries (even intermediary ones) at a shorter time generates a favourable perception by the internal customer area.
As to the disadvantages of Scrum, on the other hand, it is worth highlighting the following: (1) difficulty regarding the squad's dependence on other internal areas (e.g. IT, sales and channels) which do not have dedicated resources. Conflicts and potential delays occur when the squad depends on others out of it; (2) lack of documentation for IT deliveries; and (3) feeling of concern among the Dev team members who do not belong to the project office regarding the assessment of their performance. In general, these people like being involved in the squad dynamics, but whenever the squad enters the final phase they become worried for fear of having their performance affected as they spend a relatively long time far from the direct supervision of their original managers in the organization's structure.
Concerning the Stage-Gate itself, the following was highlighted: the steps of generating and selecting improvement projects could be refined in terms of strategic alignment. There is a feeling that the list of projects generated from the internal customers would not be optimized in terms of value creation, and that the squad's scope would be aimed at the PO's personal corporate objectives rather than covering broader initiatives of higher added value for the internal customer area and the organization as a whole.
As for whether the organization could use the pure Agile method only, both interviewees did not believe so. The organization is not prepared to work with the Agile model because it is very hierarchical, which makes the decision-making process slower. Notwithstanding, it was emphasized that there are opportunities to improve the Stage-Gate steps.
As for the adaptations made in the model, the following are highlighted: (1) members of ad hoc teams from other areas of the bank are temporarily incorporated, but fully dedicated, to the Dev Team for some sprints (e.g. legal and business areas giving resources for temporary participation in the squad). Another adaptation is (2) articulation and validation of deliveries to internal customers' middle management by performing two sprint review ceremonies. In practice, one with internal customer middle management and the other with the senior management.
The dynamics of Stage-Gate and of the eight squads vary a lot and its success is strongly dependent on the influence of the internal customer on his or her superiors and on his/her engagement with the squad. When the internal customer has influence and is engaged, the squad has a fully dedicated team as a result, meaning that the Dev Team can stay physically close, conduct projects with higher added value, make Scrum ceremonies with more rigour and have fewer conflicts in the relations of dependence on other areas of the company. If there is no engagement and influence, the perception is that the squad performance decreases considerably regarding these requirements.

Results of the telecommunication company 4.2.1 Stage-Gate characteristics.
In the telecommunication company, there is a standardized and formal process for generating, selecting, developing and implementing HR business process improvements. This process and other information associated with its management (e.g. vision, roles and responsibilities) are documented in an internal guide, which serves to explain and orientate the functioning model of the squads for incremental innovations in HR. The innovation macro-process for business process improvement has the following four steps: generation and selection of ideas, scope refinement, development and tests and implementation.

(1) Generation and Selection of Ideas
The annual strategic planning by the vice-presidency sets objectives and key results (OKRs). These objectives are unfolded into purposes of improvement projects, which then become Agile-Stage-Gate in business process innovation squads. Therefore, the decision of selecting priority projects is taken at the executive board level.
An executive forum (Agile forum) with the participation of the HR vice-president, directors and managers is held every three months. In this forum, the results of the active squads are presented and OKRs re-configured. This forum redefines the future scopes to be worked on in the squads, as well as who POs and SMs will be in each squad.
(2) Scope Refinement Once the themes as well as POs and SMs of each squad are defined, they initiate an investigation phase (inception) in the internal customer departments. Information is raised, workshops performed and people interviewed to obtain more details of the scope and backlog defined for each theme worked on by the squad. These activities do not follow the Scrum method.
Once the backlog is defined, the PO and SM negotiate with HR managers and internal customer areas the resources (personnel) needed to form the squad.

(3) Development and Tests
With the squad formed, both development and tests are carried out under the Scrum methodology.
(4) Implementation Implementations vary with the type of delivery, but they are performed under the Scrum method. For simple deliveries, review ceremonies are enough, whereas, for deliveries with significant changes in processes, training is planned and performed often with external support from Agile coaches. This training is given to the internal customer area whose processes are being improved as well as to HR business partners, representatives responsible for maintaining the improved process in the internal customer areas. Once the squad is terminated, the resources given are returned to their original functional areas.
4.2.2 Agile characteristics. The application of Agile practices, represented in this company by the Scrum method, occurs in the stages of development and implementation of the incremental innovation process.
The sprints vary from 3 to 4 weeks, being subject to changes (i.e. addition of further weeks) if there is a delay in the delivery.
As for the ceremonies, the four ones prescribed in the Scrum method are applied. Artifacts, backlog and burndown are recorded, controlled and shared through Agile software. Kanban board is physical and occupies a significant part of the Squad room's walls. No traditional project management practices or tools are used.
All the teams have up to nine members, with the majority of the resources being provided by the HR sub-areas and others being hired or re-allocated from functional areas external to the HR vice-presidency.
There are squads with a scope of process improvements only, with no IT technical profile. The Dev Team's members are HR analysts specialized in performing some functional processes to be improved. Each squad has its own room, where they work together. Two squads have a fully dedicated team, whereas two others work three days a week for the squad and two days for their original functional areas.
In addition to Dev Team, PO and SM, the squads also count on an executive sponsor and a supporting manager specialist in the process being re-designed, both on a consultant basis. These roles are aimed at supporting the hybrid model by minimizing resistance and acting on the communication between the squad and the top leadership of the company. Lastly, there still exists a supporting structure of Agile coaches external to the squads who give support by REGE providing methodologies for ceremonies conduction, organization of external visits to the squads and, essentially, organization of weekly meetings among squad leaders and internal customer area managers for progress reporting, projects synchronization and expectations alignment.
As to documentation, improved process guides are presented, but without detailing IT aspects of the delivery.
4.2.3 Interviewee's critical view of the hybrid model. The telecommunication company's model is not only new, but also was born without a former reference model. A clear feeling of overall motivation regarding the new model in the HR area was observed during the data collection, both in the team and frequent visitors from other areas interested in knowing the hybrid model. Nevertheless, due to the recent history and lack of references for comparison, an assessment of the positive/negative issues was not considered viable in face of the previous experiences. Despite this, an evolution of the model since its establishment was reported, in addition to challenges inherent to the process, both interrelated.
Evolution and challenges refer to the form of obtaining resources for the squad. In the beginning, the personnel allocated to the squad were defined by the executive board in the macro phase of the generation and selection of ideas. The executive directors, when defining the themes for the squads, also already determined the name of the members without consulting managers and coordinators of the areas from which the resources were being allocated. This ended up creating conflicts with low-and medium-level managers, who had their resources suppressed due to the re-allocation of members from their original positions to work in the squads.
In view of this impasse, the executive directors now determine only PO and SM under the current model. Therefore, PO and SM are the ones meeting with the internal customer's manager and negotiating the re-allocation of members of the team to work in the squad. The challenge is to engage this manager to allow the re-allocation of members, but it was highlighted that the decrease in conflicts regarding the prior model allows more harmonious management dynamics, thus generating more benefits for all parties involved.

Discussion
Both companies are applying Agile methods (Scrum) in association with a Stage-Gate innovation process, although it may not be fully formalized or standardized yet. Concerning the Stage-Gate level, one can observe that, in both cases, there is a protagonism of the top leadership in the initial stages and gates of the process. The top leadership is highly involved in the prioritization of projects and negotiation of resources for squad formation. At the Scrum level, both companies apply the four ceremonies (i.e. sprint planning, daily scrum, sprint review and sprint retrospective), use the three artifacts (i.e. product backlog, Kanban board and burndown chart), in addition to having three roles (i.e. product owner, scrum master and dev team), very consistent to what is recommended in the Scrum literature.
Nevertheless, differently from the generic Agile-Stage-Gate model by Sommer et al. (2015) and from the majority of the cases studied in which Scrum is applied to all stages of the innovation process, in the companies here analyzed the Scrum model was applied to the final stages only (i.e. development/tests and implementation). Activities related to the generation and validation of the hypotheses of ideas, including data collection to enrich and refine the ideas, data collection to develop a viability analysis of the ideas and even prototyping of ideas, which could be performed by applying the Agile iterative model, do not use the Scrum principles. These are precisely the front-end steps of innovation presenting more uncertainties, which could benefit from the application of the iterative, incremental and adaptable method typical of the Agile approach.
Agile-Stage-Gate in business process innovation A possible explanation of such a finding is the size and high hierarchy of the companies analyzed, according to data collected from the financing company, for instance. Cultural aspects can also have some degree of influence on this aspect since the resistance to Agile practices is frequently cited as one of the main challenges to their implementation (Albuquerque et al., 2020;Salvato & Laplume, 2020;Sommer et al., 2015;Zasa et al., 2020).
In addition, the Scrum method was adapted in these companies to better conform to the traditional context of project management, which historically prevailed in the organizations. Among these adaptations of the original model proposed by Schwaber (2004), one can observe the following: (1) Adequacy of the amount of weeks in the sprint due to the possible delays. The original model recommends a fixed number of weeks for each sprint to exclude the risk of delay (Schwaber, 2004). This adaptation was found in cases of Agile-Stage-Gate studied by Edwards et al. (2019) (2) The creation of the squad sponsor role (formal role in the telecommunication company and informal one in the financing company) at the executive level, facilitating the negotiation of the squad for external resources acquisition. The new role is aimed to reduce resistance and foster communication between the squad and top management. The original Scum model does not predict such a role (Schwaber, 2004), but one can find references to these facilitators in the cases studied by  and Salvato and Laplume (2020) (3) The use of traditional methods (e.g. Gantt chart) to help planning and control activities. The original model does not recommend the sequential approach of comprehensive planning followed by execution (Schwaber, 2004;Schwaber & Sutherland, 2017) (4) Squads with partially dedicated and not physically close teams, adjusting themselves to business contingencies. The original model recommends fully dedicated and physically close teams in order to facilitate the conveying of information and adaptation to changes Schwaber, 2004), but one can observe that full dedication and physical proximity are two adherence challenges to the Scrum model which the Agile-Stage-Gate for physical products cases presents (Cooper, 2016;Edwards et al., 2019;Sommer et al., 2015) (5) The flexibility to enrich the composition of the squad with ad hoc teams participating with full dedication, but for some sprints only and (6) Two versions of the sprint review were executed. The first was the review to middle management of internal customer areas, for alignment and validation of deliveries; the second was the final/official review to internal customer's senior management. This made the approval process more complex but lowered the risk of falling short of internal clients' expectations.
The literature on Agile-Stage-Gate for physical products points to the great difficulty not found in the cases studied: the issue of the product materiality. Differently from software, physical products have physical components which need to be purchased and/or produced and assembled; it is difficult to divide a physical product into incremental, independent and functional parts as one divides the lines of codes from software. Therefore, the delivery of an increment of the functional product after a sprint becomes much more sophisticated when intangible products are not involved. In this sense, the companies implementing the Agile-Stage-Gate model for physical product innovation had to adapt to it by working on incremental deliveries with prototypes, concepts and presentations Edwards et al., 2019;Salvato & Laplume, 2020).

REGE
As for business process improvements, however, the final deliveries are represented by procedures guidelines, training, presentations, dashboards, etc. These are artifacts which do not depend on physical components and can be sub-divided into independent and functional parts, as it occurs in cases of software development, the reason why the issue of incremental product materiality has not been highlighted in the cases studied.
Nevertheless, other attention points were mapped in the cases studied. Delivery delays potentially increase when the squad has a knowledge dependence on external resources. One can also highlight the issue of squad motivation and resource assessment since these resources are allocated from other functional areas to work for the squad under a temporary regimen. These resources play their roles for a period of time away from the direct orientation of the evaluating manager, which may create conflicts and tension regarding performance assessments compared to those colleagues who stayed in their original area.
Also, there is a criticism of the prioritization of projects defined by the top management as an initial orientation to the product backlog, which states that criteria for selecting projects would not be optimized. This supposed sub-selection of projects may be a by-product of the way the Agile-Stage-Gate model was implemented, in which more flexible, decentralized and participative Agile practices are not used in the initial steps of the innovation chain. These aspects, despite being contextual, can be didactic for managers who are investigating the viability of implementing hybrid models for business process innovation.
Even so, it is worth emphasizing that the hybrid model is well accepted by the companies analyzed. There is a perception regarding an intrinsic value to the Agile method in terms of aggregating productivity to the improvement development processes Cooper, 2016;Salvato & Laplume, 2020;Sommer et al., 2015), better engaging with customers (Cooper, 2016;Edwards et al., 2019;Salvato & Laplume, 2020), facilitating project management with visual tools (Cooper, 2016;Edwards et al., 2019;Salvato & Laplume, 2020;Sommer et al., 2015) and creating a positive environment resulting from frequent deliveries with this model. These findings also diverge from a recurrent criticism, consolidated in the study by Fernandez and Fernandez (2008), which indicates that Agile methods have been poorly supported and being seen as project management panaceas or without value.

Conclusions
Agile methods are increasingly being applied to contexts not restricted to IT projects. Nevertheless, this phenomenon is still recent and there are a few empirical cases in the literature showing particularities of the application of the Agile-Stage-Gate hybrid model to the development of physical products Granato et al., 2022), and, according to the authors' best knowledge, no case presented and discussed on this application to business process improvements.
Therefore, the present study sought to understand how large companies are applying elements of the Agile method to their business process improvement methods, including which adaptations were made to conciliate the contradictions of both pure models and which advantages and disadvantages are perceived in this hybrid model.
In view of the cases analyzed, it was possible to understand that the application of the Agile-Stage-Gate method to business process improvements has a strong protagonism of the company's top leadership in the initial stages of the innovation process, as there is centralization of the actions and no use of Agile practices, and the use of Scrum in the final stages, of development, tests and implementation. This evidence contrasts with those found by the majority of the case studies on the application of the Agile-Stage-Gate method to physical products, that is, the use of Scrum as a micro-planning tool for all stages of the innovation process.

Agile-Stage-Gate in business process innovation
The cases studies here also showed a series of adaptations to the classical Scrum model, which were made to adjust it to the context and necessities of the company and its innovation management processes as follows: flexibility in the number of weeks in a sprint, creation of new roles, sponsors and supporters of the squad, adequacy of dedications and localizations of the teams depending on the contingencies, application of classical project management practices associated with Scrum artifacts (i.e. use of Gantt chart), incorporation of fully dedicated ad hoc resources in the squad and limited to some sprints and conduction of two review meetings for testing the presentation of solutions before the final review. Most of these adaptations were also found in the literature on the application of the Agile-Stage-Gate method to physical product innovations.
Therefore, from the theoretical point of view, this study contributes to a better understanding of how Agile practices can be incorporated into contexts beyond the IT initiative or physical product development projects, thus supporting the systematization of a discussion which has already been faced by organizations. In this sense, our study reinforces the idea that some adaptive practices of Scrum are highlighted and, to some extent, are repeated in different contexts of the Agile-Stage-Gate application. These practices can guide managers to better adjust their implementation projects of hybrid models in their companies.
Concerning the advantages and disadvantages of the model, it was possible to observe benefits predicted in the literature on Agile-Stage-Gate application, such as better productivity, engagement of the customer and internal communication, in the companies analyzed. Challenges, such as the acquisition of resources, their performance assessment and full allocation to the squad were also found in the literature, indicating that some Agile premisses are difficult to be addressed in the Agile-Stage-Gate implementation context.
In this sense, some success factors were found and deserve the attention of managers interested in planning and implementing the Agile-Stage-Gate method in their companies, such as the importance of the Sponsor's role in ensuring "traction" to the squad's work. This makes it easy for the team to have more access to external resources or more quickly, besides reducing the resistance to the Agile mind-set within the company. Associated with this, there is the importance of promoting engagement of internal customer areas with which one negotiates the transfer of resources to the squad; and not underestimating the production of documentation on IT aspects of process improvements deliveries, which tend to be overlooked and poorly elaborated in this type of model.
Despite these challenges, the overall evaluation is that the hybrid model brings advantages to the traditional innovation development processes in the companies analyzed. This model allowed a greater involvement of the project team with the internal customer through facilitated management by visual tools and permanent sensation of productivity, thus demonstrating to be a promising field for further complementary investigations.
Lastly, by recognizing that the experiences from the application of the Agile-Stage-Gate model for innovation processes are still recent and little widespread in organizations, it is recommended that future case studies should diversify the size and localization of the companies being investigated. In addition, using more information sources to complement the interviews and incorporating a longitudinal study of these experiences so that the aspects suggested in the study can be examined in other contexts and more deeply addressed are also recommended. Agile-Stage-Gate in business process innovation