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

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.3 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; Cooper & Sommer, 2018; Sommer et al., 2015).

Karlström 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 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.

Žužek, Kušar, 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öm 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 (Cooper & Sommer, 2018; Salvato & Laplume, 2020; Sommer et al., 2015). Silvério, 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:

1. Improvement of time-to-market (Cooper, 2016; Cooper & Sommer, 2018; Edwards et al., 2019; Salvato & Laplume, 2020);

2. Increase in the team’s productivity (Brock et al., 2020; Cooper, 2016; Cooper & Sommer, 2018; Salvato & Laplume, 2020; Sommer et al., 2015);

3. Quicker response to market changes (Brock et al., 2020; Cooper, 2016; Cooper & Sommer, 2018; Salvato & Laplume, 2020; Sommer et al., 2015);

4. Higher motivation of the team (Cooper, 2016; Cooper & Sommer, 2018; Edwards et al., 2019; Salvato & Laplume, 2020; Sommer et al., 2015);

5. Better internal communication (Cooper, 2016; Edwards et al., 2019; Salvato & Laplume, 2020; Sommer et al., 2015);

6. Better capture of customer feedback (Cooper, 2016; Edwards et al., 2019; Salvato & Laplume, 2020);

7. Better synchronization between projects (Edwards et al., 2019; Salvato & Laplume, 2020);

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);

3. Lack of Agile culture in the organization/resistance (Cooper & Sommer, 2018; Salvato & Laplume, 2020; Sommer et al., 2015);

4. Method for evaluation of allocated resources (Sommer et al., 2015);

5. Difficult to keep the team physically close together (Edwards et al., 2019);

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 (Brock et al., 2020; 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 (Cooper & Sommer, 2018);

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);

2. Functions of facilitators in spreading the Agile mindset within the company to make implementation easier (Cooper & Sommer, 2018; Salvato & Laplume, 2020);

3. Variations in the sprint length for adequacy of the delivery of a physical product (Edwards et al., 2019).

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.

3.1 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.

3.2 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:

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.

3.3 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 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.

4.1 Results of the financing company

4.2 Results of the telecommunication company

4.3 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.

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; Cooper & Sommer, 2018; 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 Cooper and Sommer (2018) 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 (Cockburn & Highsmith, 2001; 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 (Brock et al., 2020; Edwards et al., 2019; Salvato & Laplume, 2020).

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 (Brock et al., 2020; Cooper, 2016; Cooper & Sommer, 2018; 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.