1 Introduction

Globalisation and digitisation have triggered disruptive changes in many industries, often related to innovative technologies such as Artificial Intelligence, Machine Learning, Blockchain Technologies, Internet of Things (IoT) as well as advances in High Performance Computing. Shorter product life cycles, fragmentation of value chains and new organisational models such as value creation networks, platform solutions and cluster organisations have emerged. For many companies across a range of industries, it is essential to digitally transform supply chains and distribution channels on the basis of Big Data and advanced analytics in order to successfully deal with accelerated change. Digitisation forces companies to establish flexible operating models so that they can quickly adapt their business strategy in a volatile economic environment (e.g. Gupta 2018; Kotter 2014; Ravichandran 2018; Weill and Woerner 2018).

These trends also affect the strategic role and organisational set-up of IT as a corporate function that goes far beyond the traditional responsibilities of building, running and maintaining IT systems. Information technologies enable organisations to sustain and generate competitive advantages by fostering cost efficiency and quality of products and services or even by disrupting the marketplace with innovations. Therefore, IT is evolving from a supporting function into a cross-functional organisational capability that becomes pivotal for product and process innovations in many industries and thus an integral part of a digital business strategy (Alt et al. 2020; Bharadwaj et al. 2013; Châlons and Dufft 2017; Denning 2017; Haffke et al. 2017; Ross et al. 2017; Westerman et al. 2014).

Business needs often depend on achieving a faster time-to-market, which in turn requires customer-centric and iterative development processes. In that sense, agility can be regarded as a dynamic capability of organisations to rapidly adapt to new market developments, speed up processes and actively shape their own competitive position by enhancing innovation performance and flexibly allocating corporate resources (e.g. Birkinshaw 2018; Mikalef and Pateli 2017; Overby et al. 2006; Shams et al. 2021).

The increased pressure to digitise businesses brings a need for new organisational frameworks and effective tools to manage IT projects that often play a critical role in all parts of the value chain. Agile methods were originally developed to improve the management of small to medium-sized software development projects (e.g. Schwaber and Beedle 2002; Sommerville 2015; Sutherland and Schwaber 1995) as IT projects carried out using the waterfall method very often took longer, were more costly and less innovative than expected. In the meantime, the scope of agile methods has been extended so that they are increasingly applied to large-scale IT-related projects (e.g. Conboy et al. 2019; Larman and Vodde 2016; Rigby et al. 2016, 2018; Sommerville 2015) as well as to organisational transformation projects on a business- or even company-wide level (e.g. Abrar et al. 2019; Denning 2018; Doz and Kosonen 2010; Kettunen and Laanti 2008; Tallon et al. 2019; Teece et al. 2016).

Notwithstanding the different features of the respective method, agility rests upon the principle of dividing the overall project into small increments that are refined in an iterative process (sprints) to ensure continuous improvement and changing requirements during the project. Agile teams work in a self-organised manner, ensuring the best possible outcome through frequent testing, including regular feedback from users or customers. Such an agile setting is supposed to minimise up-front investments and accelerate project execution while at the same time reducing costs and improving quality (e.g. Sommerville 2015; Schwaber 2004; Sutherland 2015). Despite the increasing popularity of agile methods, traditional approaches to software engineering such as waterfall models and their variations still play a role (Kassab et al. 2018; Palmquist et al. 2013; Poth et al. 2019; Thensing et al. 2021).

Advocates of agile methods are convinced that even a large number of interacting agile teams operating in parallel across the firm will lead to more innovation, higher productivity and a faster go-to-market (e.g. Jorgensen 2019; Larman and Vodde 2016; Rigby et al. 2018). On the other hand, there is evidence that the scalability of agile methods remains a challenge in many organisations (Denning 2016, 2018; Dikert et al. 2016; Dingsøyr and Moe 2014; Dingsøyr et al. 2019). Therefore, it seems crucial to choose the right design option in order to successfully implement agility in the organisation (e.g. Jöhnk et al. 2017; Qumer and Henderson-Sellers 2008).

It is striking that so far there is still limited empirical evidence on the actual performance of agile methods in practice. The few empirical studies on agile software development pursue a cross-industry approach and hence do not address sector-specific issues that may well affect the application of agile methods, e.g. due to different regulatory environments. This could particularly apply to the international banking sector in general, and the German banking sector specifically, as the German financial supervisory authority BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) issued minimum requirements for IT systems in banks (“Bankaufsichtliche Anforderungen an die IT” (BAIT)) in 2017 (amended in August 2021). Monitoring the fulfilment of these requirements is part of the supervisory and evaluation process performed by the respective authorities. The requirements cover a wide range of topics, e.g. strategy, governance and operations of IT systems, IT security, data protection and risk management.

To the best of our knowledge, there is so far no scientific empirical analysis of the usage of agile methods in the German banking sector. There are a few reasons why we chose the German banking industry as the field of our research. Firstly, the business models in this industry are especially subject to digitisation of core processes, as financial products are virtual by nature. Hence, managing heavy investments in IT and reducing running costs are vital tasks for banks when it comes to defending their competitive position and sustaining it in the future. A redesign of the value chain including large outsourcing projects, cloud solutions and cooperations with technology partners (including fintechs) requires efficient and effective management of IT projects.

Secondly, new incumbents such as fintechs are entering the market as competitors, suppliers or cooperation partners of banks, and these newcomers are not held back by the high costs of operating inflexible and sometimes incompatible legacy IT systems. Furthermore, fintechs are usually subject to a different regulatory framework as many of them do not need a (full) banking licence for their services or if they do, they often cooperate with or own a very small banking operation. Therefore, the question arises as to whether these different conditions affect the approach of banks and fintechs towards the use of agile methods.

1.1 Research questions

The following paper analyses, for the German banking sector, whether and to what extent agile methods are being applied in IT projects, which tools are being used and what kind of expectations regarding cost savings, quality improvement, accelerated project execution or enhanced innovation performance have been linked to the application of agile methods and to what extent these expectations have been met. Furthermore, the paper investigates what kind of impediments in implementing agile practices can be observed and whether significant differences exist in this regard between established banks and young financial technology companies (fintechs).

1.2 Related work

Agile methods have increasingly received attention both in academic research and in management practice. However, the existing empirical research is mainly based on experiences of specific companies documented in a limited number of case studies. They primarily focus on the potential benefits and challenges compared to waterfall methods and critical factors for successfully introducing and adopting agile methods (e.g. Aldamash et al. 2017; Chow and Cao 2008; Denning 2016; Dybå and Dingsøyr 2008; Misra et al. 2009; Serrador and Pinto 2015). Other research studies deal with the challenges of applying agile methods in large-scale transformation projects or even introducing an agile mindset on an enterprise level (e.g. Abrar et al 2019; Conboy et al. 2019; Dikert et al. 2016; Dingsøyr and Moe 2014; Gerster et al. 2020; Kalenda 2018; Mahanti 2006).

Furthermore, the existing literature predominantly takes a software engineering perspective, e.g. by mainly asking operational IT experts when analysing and testing the specific features of single agile methods (such as Scrum or XP), comparing them to waterfall methods and drawing lessons learned for introducing and adopting agile frameworks including the choice of design options and engineering practices (Inayat et al. 2015; Jöhnk et al. 2017; Kassab et al. 2018). Other fields of research relate to behavioural aspects of agile teams such as the impact of individual backgrounds, beliefs and values on the effectiveness of agile teams (e.g. Kakar 2017; Senapathi and Srinivasan 2013). Apart from these scientific studies, the “Annual State of Agile Report” conducts a survey among practitioners to provide insights into the application of agile methods, e.g. the dissemination of agile methods, recent trends and engineering practices employed (digital.ai 2021).

There are some research papers dealing with specific aspects of applying agile methods in the banking sector, such as the impact of agile methods on IT governance (Sulejman et al. 2018). Other contributions present case studies on the digital transformation of a particular bank (e.g. Birkinshaw 2018; Christou et al. 2010; Roses et al. 2016; Scott et al. 2021). As the existing research does not pursue a sector-specific perspective, our study of the German banking sector complements the existing empirical research on agile methods in IT projects. We start by briefly introducing the most important methods in software development, from traditional waterfall models to agile methods and hybrid frameworks, to prepare for the methodological approach and the data analysis of this paper.

2 Software development life cycle (SDLC)—models and methodologies

The Software Development Life Cycle is a framework defining tasks to be performed at each step within the software development process (e.g. Sommerville 2015). Traditionally, large software development projects were managed with the waterfall method by breaking the project scope into different work streams that in turn were structured as sequences of actions. Each phase depends on the deliverables of the previous one, based on a detailed specification of tasks, time schedules, budgets and performance indicators (e.g. Bell and Thayer 1976; Benington 1983; Royce 1970; Sommerville 2015). The waterfall method is characterised by a hierarchical approach with the resulting project management processes largely flowing in one direction, i.e. from the overall project targets at the top in a cascade of activities down to the most incremental project steps, with each step being defined by a starting point, an end point and a precise output.

The advantages of the waterfall approach stem from a logical, well-structured project plan with clearly assigned responsibilities, defined deliverables, milestones and resources (Balaji and Murugaiyan 2012; Sage and Palmer 1990; Sommerville 2015). On the other hand, the waterfall approach is characterised by a low level of flexibility, as the linear progression of stages impedes early detection of mistakes, bottlenecks or changing requirements of users, since first product releases are generated late in the development process (e.g. McConnell 2004; Sommerville 2015).

In order to overcome some of these weaknesses, modified waterfalls have been developed to allow for overlapping phases (Degrace and Stahl 1990) or to introduce iterative components such as feedback loops (Boehm 1988; McConnell 1996). Other advancements of the waterfall model lead to the V-model (Boehm 1979, 1981), which amends the sequential activities in a software development process with corresponding testing activities. A strong focus of the V-model is on quality assurance and improvement.

2.1 Iterative and incremental models

The basic idea behind this group of methods is to develop a system through repeated cycles (iterative way of working) and in smaller portions (incremental development), allowing software engineers to learn from experiences and feedback gained from earlier versions of the system. At each iteration, design modifications may take place and new functional capabilities may be added (Basili und Turner 1975; Cockburn 2008; Larman and Basili 2003). An important example within this group of software development methods is the spiral model (Boehm 1988, 2000) that considers the overall project as a spiral series of development cycles consisting of target setting, evaluation of alternatives, risk analysis, development, testing and reviewing. The concept of Rapid Application Development (RAD) builds on the spiral model and emphasises the importance of prototyping for the overall project success (e.g. Beynon-Davies and Holmes 1998; Kerr and Hunter 1993; Martin 1991; McConnell 1996).

2.2 Agile methods in general

Compared to traditional software engineering, agile software development mainly targets complex systems with dynamic, non-deterministic and non-linear characteristics. Often, at the outset of such projects, neither precise user expectations nor detailed information about technological challenges or elaborated business cases are available. Therefore, agile methods avoid detailed up-front specifications and pursue adaptive, iterative and evolutionary development processes (e.g. Martin 2013; Schwaber and Sutherland 2020).

Notwithstanding the specific design of the manifold agile methods that have been developed in the meantime, the basic principles of agile software development have been summarised in a memorandum signed by experienced software developers (Manifesto for Agile Software Development 2001). Important principles include a customer-centric approach to software development based on close interaction between business representatives and developers. A first prototype of the software should be delivered early in the process, followed by frequent deliveries of improved prototypes based on regular testing and user feedback. Each iteration covers planning, analysis, design, coding, testing, and user acceptance. This minimises overall risk and allows the product design to be adapted to changes very quickly. Multiple iterations might be required to release a new product version or features. Hence, especially in complex software development projects, optimal solutions emerge from self-organising, possibly cross-functional teams that regularly reflect progress, identify obstacles and risks and adapt accordingly in a process of continuous learning from each other. Furthermore, co-working is supported by co-location to foster face-to-face communication and facilitate instant feedback. Overall, agile methods are considered to speed up the project, support quality assurance and also reduce development costs (e.g. Flewelling 2018; Sommerville 2015; Sutherland 2015; Dybå and Dingsøyr 2008; Forsberg and Mooz 1999).

Although there is a common set of principles characterising agile methods, in recent years many different agile methods have been developed, accentuating different aspects of agility. To prepare the empirical analysis of agile methods in the German Banking sector, we briefly describe the agile method Scrum, which is so far the most popular agile approach in practice (digital.ai 2021). We also provide a short summary of other important agile frameworks.

2.3 Scrum

The Scrum methodology was originally developed for product development processes in the manufacturing industries (Takeuchi and Nonaka 1986). The transfer to software development processes goes back to the 1990s (e.g. Sommerville 2015; Hossain et al. 2009; Schwaber 1997). Since then several methodological refinements and amendments have further advanced the Scrum approach (e.g. Schwaber and Sutherland 2020; Beedle et al. 2010; Schwaber 2004; Schwaber and Beedle 2002). The fundamental action unit of Scrum is a small team of up to ten members consisting of a product owner, a scrum master and developers. The team is self-managing, often cross-functional and focuses together on the product delivery. The scrum set-up fosters mutual accountability, participation and self-organisation (e.g. Schwaber and Sutherland 2020).

The product owner is responsible for defining the product in customer-centric terms and for negotiating priorities, scope, funding, and schedule with stakeholders. Therefore, a key role of the product owner is to create, order and clearly communicate product backlog items to the developers and ensure that product requirements are transparent, visible and understood by the development team (Sverrisdottir et al. 2014). Developers are core members of the scrum team who are responsible for building the product increments in the respective iteration towards the final product. Depending on the type of product, development teams usually include members with different fields of IT-related expertise such as system architects, designers, data specialists, programmers or testing specialists. Representatives of non-IT functions such as HR, Finance, Marketing or Legal may also belong to the team (Dikert et al. 2016; Dybå and Dingsøyr 2008). The development team works in a self-organising manner on the product backlog by planning the next sprint, creating the sprint backlog or adapting activities when needed. Direct interaction with customers or stakeholders is recommended to allow for regular feedback and to improve the understanding of customer needs (Schwaber 2004; Schwaber and Beedle 2002).

The scrum process is facilitated by a scrum master, who is responsible for implementing the scrum process in accordance with the basic principles documented in the scrum guide (Schwaber and Sutherland 2020). In that role, the scrum master supports the product owner, the developers and even the entire organisation in which the scrum process is being executed. In particular, the scrum master coaches team members in the basic working principles of scrum (e.g. self-management, customer-orientation, cross-functionality) and helps to overcome internal or external impediments to deliver valuable product increments or other deliverables. The scrum master facilitates key sessions and encourages the team to continuously improve. However, in contrast to a project manager, the scrum master has no people management responsibility.

A sprint is the basic iteration unit of development in Scrum which is characterised by a pre-agreed length of about one to four weeks (Fig. 1). Each sprint starts with a sprint planning that establishes a sprint goal and the required product backlog items are translated into a sprint backlog covering the activities needed to achieve the sprint goal. A daily meeting of the development team (the “daily scrum”) is important to monitor progress, identify possible impediments to achieving the sprint goal and adjust the sprint backlog accordingly. At the end of each sprint the scrum team presents the deliverables of the sprint, i.e. the product increment, to stakeholders in order to inspect progress towards the sprint goal (sprint review). In addition, lessons learned are identified to improve the forthcoming sprints (sprint retrospective) and potentially refine the product backlog. However, it should be noted that, despite the common framework and tools, scrum projects are usually tailored to the specific situation of the company as multiple design options are available (Diebold et al. 2015; Jöhnk et al. 2017).

Fig. 1
figure 1

Overview of the scrum process

Full size image

Other agile software development frameworks are Extreme Programming (XP) (Ambler 2002; Beck and Andres 2004; Beck and Fowler 2000; Lindstrom et al. 2004), the Unified Software Development Process (Jacobson et al. 2000), which was originally developed by Rational/IBM (Gornik 2001; Kroll and Kruchten 2003; Kruchten 1998), and Kanban (Brechner 2015; Ohno 1988). Besides these, there are development frameworks that stress specific aspects of the agile software development process such as Test-Driven Development (TDD) (Beck 2002), Behaviour-Driven Development (BDD) (Kortum et al. 2019; North 2006) or Adaptive Software Development (Highsmith 2000; Highsmith and Cockburn 2001).

2.4 Agile at scale

While originally agile methods were used in smaller projects with co-located teams, over the past decade the scalability of these frameworks became an important topic both for practitioners and for researchers. The term “large-scale agile development” is used to describe multi-team development efforts that make use of agile principles and involve a large number of actors and interfaces with existing systems (Dingsøyr and Moe 2014). This includes extending the application of agile methods to other corporate processes such as innovation or product development (Kettunen 2007).

Hence, frameworks emerged dealing with the scalability of agile methods, such as LeSS (Large-Scale Scrum) (Larman and Vodde 2016) or the Scaled Agile Framework (SAFe) (Leffingwell 2018, 2011).

SAFe is an extensive agile framework intending to make the whole organisation more agile by addressing different fields, levels and competencies of an enterprise. The framework of SAFe distinguishes between different components constituting an “agile enterprise”, including “Lean Agile Leadership”, “Agile Product Delivery”, “Team and Technical Delivery” or “Organisational Agility”, that need to be addressed in parallel and tailored to the specific business requirements. As SAFe has a much wider scope than improving IT projects or product development processes, SAFe involves the use of different agile methods, such as Scrum or XP, in combination with lean management tools such as Kaizen or Six Sigma (Knaster and Leffingwell 2020).

In contrast to SAFe, the framework LeSS is an expanded version of Scrum in an environment where multiple teams are working together on one product. Hence LeSS is mainly applied in product development projects. Based on the fundamental principles of Scrum, LeSS explicitly addresses interfaces between different work streams and ensures efficient communication and cooperation across teams (Larman and Vodde 2016). Other large-scale agile frameworks include DAD, Nexus and Scrum at Scale (Almeida and Espinheira 2021).

3 Agile methods in the German banking sector—database and research methodology

Due to the lack of empirical evidence of agile methods in the German banking sector, we have conducted a structured survey to find out whether and to what extent German banks use agile methods in IT projects, which tools they prefer and to investigate their expectations, experiences and perceived success factors. Furthermore, we analyse whether or not significant differences on these questions can be observed between established banks and young fintechs that do not have to solve legacy IT issues and can predominantly pursue a greenfield approach. In order to answer these questions, a total of 51 financial institutions headquartered in Germany took part in a structured survey conducted between November 1st 2020 and January 31st 2021. We concentrated on the banking sector and “banking-related” fintechs that act either as competitors of traditional banks or as suppliers or cooperation partners. Therefore, we included fintechs providing services in the fields of financing, investments and transactions (e.g. payments) as well as other banking-related services (e.g. risk management). Fintechs in the insurance sector (InsurTechs) or in other fields such as property technology (PropTechs) or regulatory technology (RegTechs) were excluded from the survey, as they operate in a different regulatory environment.

Table 1 shows that 17 German banks and 34 fintechs participated in the survey. Out of the 51 participants in the survey, all banks have at least some experience with agile methods in IT projects, whereas two out of the 34 fintechs have so far not applied any agile methods, i.e. they apply either waterfall methods or work without a specific development framework as they are still too small. For the purpose of this study we have defined banks with total assets of at least EUR 100 bn as large banks and all other banks as small-to-medium-sized (SME) banks. Banks that serve both corporate and retail clients and offer savings and loans products are defined as universal banks; all others have been categorised as special banks. In terms of market coverage, the banks participating in the survey represent the “three pillars” of the German Banking System (i.e. private banks, state banks (incl. savings banks) and cooperative banks) and cover approx. 90% of the total assets of the German banking sector based on the German banking statistics (Deutsche Bundesbank 2021). Hence the results of the data analysis for the banking sector are statistically robust. For the German fintech sector it is more challenging to select a meaningful sample as there is so far no database of registered fintechs provided by a body such as a financial supervisory authority, a financial data provider or a research institute, which would ensure a high level of data quality in terms of completeness, correctness and validity. The available lists of German fintechs are mainly compiled by startup organisations or consulting firms that differ widely in terms of definitions, categories, numbers and data quality.

Table 1 Database
Full size table

For the purpose of our study we defined fintechs as “young” technology-based financial services firms that have existed for 10 years at most. The fintechs covered in this study were therefore founded on or after November 1st 2010 and are still active in the market as of January 1st 2021. Companies older than 10 years are usually not considered startups any more (Deutscher Startup Monitor 2021). Furthermore, we focused on fintechs that offer “banking” or “banking-related” services, in order to ensure that the selected fintechs operate in a market and regulatory environment similar to the banks participating in this survey. Based on these criteria, we identified and approached 103 “banking-related” fintechs, of which 34 fintechs participated in our survey, which corresponds to a response rate of 33%. Although this is still a limited number, the sample is sufficiently large to fulfil the prerequisites of applying the non-parametric test methods used in this paper while carefully considering the limitations of the analysis when interpreting the results.

In addition, Table 1 displays a classification of the participating fintechs along two dimensions. In terms of their business model, fintechs have been divided into two groups, one of which serves end customers (Business-to-Consumer, B2C) and the other serves business customers (Business-to-Business, B2B). As for their stage of development, all companies founded on November 1st 2015 or after have been defined as “early stage” while all fintechs with a maturity of more than 5 years have been classified as “later stage” fintechs.

We designed a questionnaire with 12 questions in order to analyse fields of application, expectations and experiences with agile methods in general and to find out whether or not statistically significant differences between banks and fintechs can be observed (Table 2). Before we finalised the design of the questionnaire, we discussed draft versions with ten randomly selected survey participants (five banks and five fintechs) to make sure that the questions asked and the corresponding choices presented were clearly formulated and are considered suitable and relevant for the topic.

Table 2 Questionnaire on agile methods in banking
Full size table

It should be noted that during these preliminary discussions it turned out that larger banks, in particular, were not willing to collect the data on a more granular (e.g. divisional or functional) level. This means that our findings are restricted to a corporate level and hence do not allow for a more differentiated perspective on the respective organisations.

We have addressed the questionnaire both to the Head of Corporate Development and the Head of Corporate IT in larger banks, who then decided who should internally take the lead in collecting the required information. This was also to ensure that both business-related and technological aspects are considered when completing the questionnaire. In small-to-medium-sized banks the Chief Operating Officer (COO) most often completed the questionnaire. At fintechs the CEO or the CTO of the company filled in the questionnaire.

We had a preliminary talk about the questionnaire with at least one representative of each participating firm to clarify open issues and to make sure that the questions had been properly understood. After receiving the completed form, in some cases we had another meeting, particularly when the participating company had added qualitative remarks on selected questions that provided additional insights into the company-specific background for the given answers.

A limiting factor of our analysis is the fact that, in large banks with a broad portfolio of business divisions, the usage of agile methods and the agile mindset can be very different across the firm. Therefore, the feedback we received from diversified banks may be characterised as a corporate view taking into account different agile development stages of the various divisions.

The survey consists of three parts. The first part, comprising questions 1–4, intends to establish a picture of the status quo of how agile methods are applied in the German banking and fintech sector. These questions therefore relate to the share of IT projects where agile methods are applied and the preferred agile methods. They also cover the objectives of using agile methods in IT projects as well as the type of projects in terms of size.

The second part of the survey (questions 5–8) deals in particular with the experiences of banks and fintechs with agile methods to date, based on their expectations on cost savings, acceleration of projects, quality improvement and enhanced innovation performance. The final part (questions 9–12) intends to shed some light on possible implementation hurdles, success factors of using agile methods and the future relevance of agile methods inside and outside the IT function. The Chi-Square test for categorical variables and the Mann–Whitney U test as a non-parametric test method for ordinary scaled variables are used to find out whether or not a statistically significant difference between banks and fintechs could be observed. For each of the following Mann–Whitney U tests, the null hypothesis assumes that there is no difference between fintechs and banks based on mean ranks of the respective variable. For each of the following Chi-Square tests, the null hypothesis assumes that no difference between banks and fintechs on the tested categorical variables can be observed.

4 Data analysis and results for the German banking sector

In the following we summarise the main findings from our survey on agile methods in the German banking sector. The analysis provides insights into objectives, preferred tools, expectations and experiences of banks and fintechs. In addition, lessons learned by the participants indicate implementation hurdles and success factors of agile methods in banking.

4.1 Objectives and current usage of agile methods

To get an indication of how broadly agile methods are being applied in IT projects, the participants were asked about the percentage of IT projects in which agile methods are applied, regardless of the project size in terms of volume (Table 3).

Table 3 Share of IT projects where agile methods are applied
Full size table

While 84% of the fintechs apply agile methods in at least 75% of their IT projects, only 47% of the participating banks do so. At the same time, 35% of the banks apply agile methods in less than 50% of their IT projects compared to 0% of the fintechs. Overall, the fintechs apply agile methods more frequently than the banks. This difference is statistically significant on a confidence level of 5%, i.e. the null hypothesis stating that there is no difference between fintechs and banks is rejected. The analysis may also support the hypothesis that startups are more inclined to use innovative organisational methods, as they do not have to cope with legacy technologies and structures that sometimes pose barriers to change.

As illustrated in the first chapter, a number of different agile methods are available in the market that share similar principles. Therefore, we preselected some well-established frameworks and tools (Scrum, SAFe and LeSS) and captured other methods (e.g. XP and Kanban) in a category called “others”. Through the inclusion of SAFe and LeSS we wanted to get some evidence on whether or not scaled agile frameworks already play a role in practice. Table 4 shows that Scrum is by far the most applied agile tool, both in banks (94%) and fintechs (100%). Other tools such as XP or Kanban are used to a much lower degree (banks 35%, fintechs 38%). A different picture emerges regarding the application of advanced methods such as LeSS, which seems to be almost irrelevant to date in the German banking sector, or SAFe, which plays a role in German banks (35%) and a small role (3%) in the fintech segment. Only in the latter case is the null hypothesis, that there is no difference between banks and fintechs, rejected on a 5% confidence level. This is quite plausible, given that the potential benefit of using scaled agile methods is greater in larger organisations such as established banks than in typically much smaller fintechs.

Table 4 Applied agile methods
Full size table

The panelists were asked about the objectives they intend to achieve by applying agile, i.e. more flexible, adaptive and self-organising, methods in IT projects compared to more traditional, precisely structured and centrally steered waterfall methods. The participating institutions could choose between “cost savings”, “accelerated project execution”, “improved quality of project outcome” and “better innovation performance”. Multiple answers were possible. Table 5 summarises the answers and the results of the Chi-Square independence tests with the respective null hypotheses that no difference between fintechs and banks can be observed.

Table 5 Objectives of the introduction of agile methods in IT projects
Full size table

The data shows that the “acceleration” of projects is an important priority both for banks and fintechs, whereas cost savings and quality improvements are also on the agenda of panelists, but to a lower degree. Interestingly, cost savings seem to be slightly more important for fintechs than for banks. A similar observation can be made concerning the relative importance of “quality improvement”, which may relate to the innovative and somewhat immature character of the solutions offered by fintechs. However, based on a Chi-square test, for these objectives no significant statistical differences on a significance level of 5% could be observed between fintechs and banks, i.e. the null hypotheses are not rejected. But the data also suggest on a significance level of 5% that banks place greater importance on achieving better innovation performance than fintechs. This is not surprising, as the fintechs included here are startups and are usually founded to introduce innovative products and services, whereas banks hope to become more innovative when project management and the whole corporate culture becomes more agile.

Table 6 illustrates in which type of projects, in terms of project size, agile methods are applied. We distinguish large-scale projects, medium-sized and small projects, whereby we had to accept that even companies of similar size segment these project categories in different ways. Therefore, we did not precisely prescribe how to allocate projects to the three categories, e.g. in terms of project volume, rather we let the participants decide how to classify their project portfolio to consider company-specific circumstances. Consequently, it should be noted that the volume of projects associated with each category varies. Nevertheless, the figures give an indication of the field of application of agile methods based on the company-specific judgement of project size.

Table 6 Type of IT projects where agile methods are applied
Full size table

The data suggest that the application of agile methods is mainly focused on medium-sized and small IT projects and to a lesser extent on large-scale projects. However, there is a remarkable—though still not statistically significant—difference between fintechs and banks, as only about 71% of the banks versus some 47% of fintechs use agile methods in large-scale IT projects. Qualitative comments provided by some participants indicate that the comparatively low figure for fintechs may stem from the fact that younger fintechs, in particular, have less exposure to large-scale projects simply because of their limited size. Some banks stated that they are somewhat cautious about introducing agile methods in large projects as they are still in the process of gaining deeper experience with such methods in smaller projects.

4.2 Expectations and experiences with agile methods

Table 7 provides insights into the fulfilment of expectations regarding the main objectives of applying agile methods, i.e. reduction of project costs, reduced project time, improved quality and enhanced innovation performance, each of them analysed for banks and fintechs, applying the Mann–Whitney U test as rank sum test for ordinal scaled data. First of all, the data show that across all objectives only a small group of panelists (between 2 and 4%) consider their expectations from applying agile methods to not have been fulfilled at all. Conversely, the vast majority of participants see their expectations across all dimensions as at least partially fulfilled. Looking at the different objectives, it is striking that expectations regarding cost savings were only partially-fulfilled in most cases (fintechs 63%, banks 82%). Only a minority of participants were fully satisfied with their cost reductions, while only 6% of the banks and 0% of the fintechs report having missed their cost saving objective entirely. The difference between fintechs and banks is statistically significant on a 5% confidence level, indicating that it is more difficult for banks to achieve their cost savings targets by applying agile methods.

Table 7 Experiences and expectations with agile methods
Full size table

In terms of project acceleration, the analysis reveals that 51% of participants overall see their expectations as fully or at least partially (47%) met. However, the results differ substantially between banks (35% of fully met expectations) and fintechs (59%) although this difference is not significant on a confidence level of 5%, which could be related to the limited sample. On the other hand, a partial fulfilment of expectations was confirmed by 59% of the banks and 41% of the fintechs. This is an interesting aspect given that the acceleration of projects is mentioned as the most important objective by most banks and fintechs.

The experiences regarding the expected innovation performance show a similar overall pattern, with a high level of fully (43%) or partially (53%) met expectations. The figures differ again between fintechs considering their expectations completely or partially fulfilled (each 47%) and banks (35% fulfilled versus 65% partially met). Yet again the difference between banks and fintechs is not statistically significant on a 5% confidence level using the Mann-Whiney U test.

When it comes to expected quality improvements, around 98% of the participants see their expectations fully (53%) or partially (45%) met. While 66% of the fintechs were fully satisfied with their achieved quality improvements, only 29% of the banks achieved such a high satisfaction level. Nevertheless, 71% of banks (31% of fintechs) indicated a partial fulfilment of their expectations. This wide gap between the experiences of fintechs and banks is statistically significant on a 5% confidence level.

In summary, across all dimensions, most banks and fintechs see their expectations as either fully or at least partly fulfilled. While the expectations of banks in every dimension were predominantly only partially fulfilled, most fintechs report that their expectations were fully met with regard to acceleration of project execution and quality improvement. The data suggest on a confidence level of 5% that banks have more difficulty achieving their cost savings and quality assurance targets than fintechs. Based on the comments we received from interviews with company representatives, possible explanations for these differences include that some expected benefits among banks were unrealistically high and that banks have so far not gained enough experience with agile methods to exploit their full benefits.

We also asked the panelists about their views on the future relevance of agile methods for projects inside and outside the IT function. Table 8 confirms that there is a unanimous opinion that the relevance of agile methods in IT project management will further increase (94% of banks, 97% of fintechs). The response is similar, though not quite as pronounced, regarding projects outside IT, which may relate to strategic projects, for example, or projects in other centralised functions such as HR, Accounting or Finance. 82% of banks and 94% of fintechs expect that agile methods will also become more relevant outside IT projects.

Table 8 Expected future relevance of agile methods
Full size table

4.3 Implementation hurdles and success factors for agile methods

Finally, we want to get an indication about implementation hurdles and success factors for agile methods in the German banking sector based on the experience the participants have gained so far in practice. In order to facilitate the completion of the questionnaires, we wanted to avoid a too detailed segmentation of technical parameters. Therefore, we preselected five potential hurdles and five success factors. Although they represent a relatively rough grouping of parameters, they are in line with findings in other studies and with the feedback we received from some panelists before finalising the questionnaire. Table 9 shows that the compliance of project teams with the agile rules, i.e. accepting and consistently applying roles such as scrum masters, product owners and developers, is among the most important challenges in agile IT projects for both banks (76%) and fintechs (72%). Remarks from interview partners highlighted that proper training and coaching are viewed as essential before starting to apply agile methods. Comments from the participants also suggest that interdisciplinary project teams need to go through a learning curve in order to continuously put agile rules into practice.

Table 9 Implementation hurdles of agile methods
Full size table

Furthermore, the majority of banks (76%) and fintechs (69%) consider organisational interfaces as a possible hurdle that may exist between the respective agile project team and other projects (which may or may not also apply agile methods) or other organisational units (e.g. business divisions, centralised functions) affected by the project outcome. Possible frictions could arise, for instance, if product owners have multiple, perhaps conflicting, roles in a company or when there is a general resistance to major changes in the organisation.

Another aspect that could negatively affect the implementation of agile methods is insufficient management support, e.g. if senior managers are not already familiar enough with agile methods. Although only 27% of the institutions mentioned this as a possible hurdle, it is noticeable that the ratio is substantially higher among banks (41%) than fintechs (19%). This may be due to the fact that fintechs usually operate with much flatter hierarchies and that founders are often part of the management team. Hence, the acceptance of new (organisational) technologies seems to be higher among fintechs than established banks. However, this difference is not statistically significant on a 5% confidence level.

At the same time, the buy-in of the project team itself seems to be a challenge to promoting agility as well. For example, not all members of the project team may be convinced about the benefits of agile methods, perhaps because of limited experience with agile methods so far or because the defined role of the individual team member is perceived as a downgrade compared to former line management positions.

Some respondents from banks mentioned that the implementation of agile principles goes hand in hand with a flattening of the organisational hierarchy and hence a loss of management responsibility for some employees. It should be noted that only 34% of the fintechs, but 59% of the banks, consider this aspect a possible implementation barrier, although this difference is not statistically significant on a 5% confidence level. The buy-in of users/customers seems to be of minor relevance (24% overall). However, even this comparably low figure is remarkable, as the engagement of users/customers is crucial for a successful project. Overall, it is noteworthy that no statistically significant differences between banks and fintechs can be observed with regard to implementation hurdles, i.e. the null hypotheses have been all accepted (Table 9).

Finally, we raised the question about key success factors for applying agile methods in IT projects. It turns out that the know-how of the project team members regarding agile methods is viewed as an important prerequisite for a successful application. Some 76% of the banks and about 66% of the fintechs share this view (Table 10). Remarks from interview partners highlighted that proper training and coaching are viewed as essential before starting to apply agile methods. Another success factor mentioned by 82% of the banks and 72% of the fintechs relates to support from the responsible management to overcome scepticism towards agile methods in the wider organisation. This fits with the findings related to the previous question, where insufficient management buy-in was considered a possible barrier to successfully implementing agile methods.

Table 10 Success factors for implementing agile methods
Full size table

In addition, a clear project set-up, i.e. a consistent establishment of the agile framework selected, and the buy-in of the concerning business units were each mentioned as success factors by about 53% of the participants. A little surprising is the feedback on the significance of project budget constraints. Neither the majority of banks nor of fintechs report a sufficient budget as a key success factor. The difference between the responding banks (35%) and fintechs (3%) is statistically significant in that case, whereas no significant difference between banks and fintechs could be observed for any other factors. Qualitative comments from participants point to the fact that the pre-agreed budgets have been sufficient and in many cases have even not been fully utilised, partly because budgeting was based on past experience with waterfall methods, not taking into account the benefits of agile methods in terms of cost savings. Another reason mentioned refers to the fact that, in the banking sector, investments in digitisation enjoy a high priority, so budget negotiations are less contested than in other fields of investment.

5 Discussion

Our results show that agile methods are widely used in IT projects both in the German banking sector and in banking-related fintechs. However, fintechs have relatively more experience with using agile methods and apply them more intensively than banks. Given that only 47% of the banks, but 84% of fintechs, apply agile methods in at least 75% of their IT projects (Table 3), a significant part of the German banking sector seems to still be in a learning process of implementing agile methods or to prefer using more familiar, non-agile methods in many projects. The question as to whether this difference in adoption levels of agile methods between startups and established companies is specific to the financial sector or also applies to other industries has so far not been covered by other empirical studies.

As an agile mindset is considered to be strategically important to sustain and enhance competitive positions in a rapidly changing environment with more frequent disruptions, the somewhat sluggish implementation of agile methods by at least some German banks could be one reason for them losing market share to fintechs in a number of segments.

Both fintechs and banks state that agile methods are mainly adopted in medium-sized and small IT projects (Table 6), which is consistent with other empirical evidence and the intended field of application of basic, i.e. non-scaled, agile methods (e.g. Dingsøyr et al. 2019; Martin 2013; Schwaber 2004; Sommerville 2015). However, there is a clear tendency to scale agile approaches beyond single projects and apply them in multiple-project-settings or extend their implementation to whole business units, centralised functions or even to enterprise level (e.g. Abrar et al. 2019; Dikert et al. 2016; Conboy et al. 2019; Dingsøyr and Moe 2014). A significant portion of German banks (71%) and fintechs (47%) have also applied agile methods in large-scale IT projects, evidently often without using scaled agile frameworks such as SAFe or LeSS, which are so far negligible in German fintechs, while a minority of German banks have at least adopted scaled agile frameworks to a certain degree (Table 4). Responding fintechs pointed out that the limited size and complexity of their organisations and projects make scaled agile frameworks unnecessary.

Our survey does not allow an exploration of the reasons behind the limited adoption of scaled agile methods in German banks to date. This may, for example, be related to structural or cultural barriers in the respective organisation, possibly indicating that there is a lot of unexploited potential for agile applications, especially in larger banking groups. Comparable studies addressing these questions in international banking markets are not yet available.

However, the wide gap between the application of basic agile methods compared to large-scale frameworks is consistent with findings in other studies and supports the hypothesis that the increased level of complexity in a multiple project framework involving many stakeholders could be a barrier to a broader introduction of scaled agile methods (e.g. Dikert et al. 2016; Dingsøyr et al. 2019; Turetken et al. 2016).

Furthermore, Scrum is by far the most popular agile framework in both groups, while XP and Kanban are used as complementary tools in some cases (Table 4). These findings are consistent with the practitioner-oriented cross-industry study of Digital.ai (2021). Recent scientific studies analysing the usage of different agile methods are not available, either from a cross-industry or from a sector-specific perspective. Hence there is so far no evidence that the affiliation of a company with a particular sector affects the choice of the preferred agile method. Nevertheless, there is a broad consensus among fintechs and banks that agile methods will become more important within and beyond IT in the future (Table 8).

Agile methods are supposed to accelerate projects in rapidly changing competitive environments and reduce project costs (e.g. Flewelling 2018; Forsberg and Mooz 1999; Sommerville 2015; Sutherland 2015; Schwaber 2004). Other targets are improved quality (e.g. Chakravarty et al. 2021; Dybå and Dingsøyr 2008; Karhapää et al. 2021; MnKandla et al. 2006), and better innovation performance (e.g. Highsmith and Cockburn 2001; Kettunen 2007; Ravichandran 2018; Teece et al. 2016; Wilson et al. 2011).

Our analysis suggests that agile methods can indeed help to accelerate projects in banking, which is of the highest priority for both banks and fintechs when adopting agile methods. However, there seems to be room for improvement, as only 35% of the banks (59% of the fintechs) see their expectations fully met in that regard.

The achievement of cost savings by adopting agile methods seems to be a lower priority than other targets for both fintechs and banks, although high IT costs, especially in the financial services sector, are frequently mentioned as a source of poor profitability in the age of digital transformation. In addition, cost saving targets seem to be more difficult to reach, especially for banks, of which only 12% find their expectations fully met (38% of fintechs), possibly because they are subject to much stricter regulatory requirements and/or higher organisational complexity.

Other non-banking-related research studies also conclude that agile methods are contributing positively to project efficiency in terms of meeting schedules and budgets. In addition, prior findings include that agile methods can help to increase productivity in IT projects by reducing rework and defect rates (e.g. Alahyari et al. 2017; Dikert et al. 2016; Dybå and Dingsøyr 2008; Korpivaara et al. 2021; Olszewska et al. 2016; Reifer 2002; Serrator et al. 2015).

Furthermore, our findings suggest that agile methods can also contribute to quality improvements of products and services. However, banks reported significantly less satisfactory experiences than fintechs in that regard. The existing studies do not show a uniform picture of the link between quality of end products and the usage of agile processes. There are some studies that are in line with our banking-related findings (e.g. Ahmed et al. 2010; Dikert et al. 2016; Dybå and Dingsøyr 2008), suggesting that agility can lead to a higher quality of products, both directly through close cooperation and regular exchange with users and indirectly by supporting knowledge creation and motivation of team members. Yet there are also case studies indicating that agile methods may not always contribute to an increase in quality of project outcome (Li et al. 2010; Reifer 2002).

It is also noteworthy that a much higher portion of banks (77%) than fintechs (44%) intend to improve their innovation performance by adopting agile methods. Although our findings suggest that agile methods may contribute to improving innovation activities overall, most banks and fintechs state that their expectations in that regard have not been fully met. Empirical studies focused on IT projects do not cover the role of agile methods for innovation processes, although innovation is supposed to be part of the software value map (e.g. Alahyari et al. 2017; Khurum et al. 2013). Yet there is a growing body of research on the role of strategic agility (e.g. Ciric et al. 2018; Clauss et al. 2021; Denning 2017; Doz and Kosonen 2010; Gupta 2018; Wilson and Doz 2011) claiming that an agile mindset is essential to promote innovation in companies in general and business models in particular. The limited empirical research on this question supports this hypothesis (Clauss et al. 2021).

The data also shed some light on important hurdles when implementing agile methods in practice (Table 9). It is apparent that compliance with the rules of the respective agile framework plays a key role, which implies that a proper project set-up, including the selection and customisation of the respective agile framework, is an important success factor. This observation is consistent with other studies highlighting that typical implementation challenges include, inter alia, “general resistance to change”, the “misunderstanding of agile concepts”, “hierarchical management”, “inappropriate attention to design issues” and “incomplete user stories” (e.g. Chow et al. 2008; Dikert et al. 2016; Inayat et al. 2015).

The data also reveal that the majority (59%) of the banks and even a significant portion of fintechs (34%) have experienced that a lack of buy-in among the project team can be a relevant barrier to implementation. The comparably lower figure for fintechs may be related to the fact that fintechs usually work in organisational structures with flat hierarchies and low complexity due to their limited size. Besides, many fintechs as well as startups in other industries employ much younger staff on average than established banks, staff who might therefore prefer to work in more entrepreneurial and agile cultures. Nevertheless, both the majority of banks (76%) and fintechs (66%) consider the know-how of the team as an important success factor (Table 10). Therefore, suitable training of teams in agile methods is essential to ensure not only that the necessary technical agile skills are acquired, but also to convince team members of the benefits of working in an agile set-up so that organisations can learn how to become agile on a project or even organisational level. These results are also in line with previous studies (e.g. Aldamash et al. 2017; Dickert et al. 2016; Misra et al. 2009). The establishment of suitable incentives to reward the performance of agile teams may also foster an agile mindset.

The management of organisational interfaces between the agile teams and other organisational units is also mentioned as a potential barrier to implementation by about 76% of the banks (69% of the fintechs). This means that agile project teams cannot simply be implanted into the overall organisation, rather corporate culture has to be open-minded towards agile management approaches and strong management support is pivotal. Furthermore, successful implementation of agile projects can be hampered by frictions between self-organised agile project teams and departments that still have hierarchical structures and are affected by the project outcome. Besides, the lack of proper involvement of non-development corporate functions could also hinder implementation of agile projects. Similar findings have been reported in other research articles confirming that organisational resistance and scepticism towards agile principles and new working practices can be important barriers to implementation. (e.g. Conboy 2019; Denning 2016; Dikert et al. 2016; Kalenda et el. 2018).

The interviews with participating banks suggest that most of them are in the midst of a longer-term digital transformation process taking time, investments and cultural change to eventually become a more agile organisation. Fintechs are obviously not affected by a long-term corporate history that could become a barrier to more dynamic organisational models.

It may be noted that, based on our survey, insufficient buy-in among the management seems to be a notable factor in the German banking sector, given that some 41% of the banks (19% of the fintechs) consider this aspect as a barrier to implementation. However, this factor seems to be more important in established organisations than in younger fintechs, whose managers are often also founders of the respective companies, which could facilitate the alignment between owners, management and project teams. At the same time, some 82% of the banks (72% of the fintechs) consider sufficient management support as a critical success factor. This finding suggests that a significant portion of managers remains unconvinced or not fully convinced about the benefits of agile organisational frameworks. Similar results have been found in past studies outside the banking sector (e.g. Aldamash et al. 2017; Dikert et al. 2016; Kalenda et al. 2018; Senapathi and Srinivasan 2013).

Similarly, a non-negligible portion of German banks (some 18%) and of fintechs (28%) view a lack of buy-in among users/customers (internal or external) as a barrier to implementation, while at the same time some 65% of the banks (47% of the fintechs) consider strong user support as a critical success factor. The importance of this factor has also been emphasised in prior studies (e.g. Conboy et al. 2019; Misra et al. 2009). This evidence may also be a hint that intensive communication and training for all parties involved, including management and users/customers, is vital before starting an agile project.

6 Limitations of our findings

Our analysis focuses on the application of agile methods in IT projects. Hence, the trend towards a broader adoption of agile frameworks in other parts of organisations and even on an enterprise level is beyond the scope of our study. While the data are statistically robust for the German banking sector, as the participating banks cover more than 90% of the total assets in the German banking sector, the results for fintechs and, by extension, the difference between fintechs and established banks are statistically less reliable due to the limited number of participating fintechs.

Hence, the statistical robustness and power of the findings would benefit from a larger sample, which presupposes a higher willingness of fintechs to share their experience with researchers. Furthermore, it has to be taken into account that our analysis takes a corporate perspective, as our results are based on feedback from responsible management representatives (corporate development and/or corporate IT function, COO). However, especially in larger firms, the findings could vary across different business units and functions depending on their level of agile maturity. Moreover, our study does not allow for a deeper understanding of the reasons behind some of our findings, e.g. regarding the low adoption rate of scaled agile frameworks in German banks to date. The same applies to the fact that banks often fall short of their expectations regarding performance targets such as cost savings, quality improvements and improved innovation performance.

7 Conclusion

Our research provides the first comprehensive analysis of agile methods in the German banking sector. The comparison with a selected number of fintechs has revealed many communalities but also some differences between banks and fintechs.

We found out that all banks and almost all fintechs in the German banking sector apply agile methods in IT projects. However, fintechs seem to have relatively more experience with agile methods than banks and use them more intensively. Scrum is by far the most relevant framework used in practice. Scaled agile frameworks are so far negligible in the German banking sector. Another observation is that the application of agile methods is mainly focused on medium-sized and small IT projects and to a lesser extent on large-scale IT projects. Our findings suggest that the application of agile methods is usually beneficial for banks and fintechs, given that both see their expectations across all dimensions at least partly fulfilled. Acceleration of projects is apparently the most important objective of deploying agile methods. While fintechs achieve their acceleration targets in most cases, there seems to be room for improvement for banks. In addition, agile methods can contribute to both cost savings and quality improvements, though for banks it is evidently more challenging to reach their respective targets. Improving innovation performance is an important priority for banks and fintechs when applying agile methods. Yet in this regard too, most banks do not see their expectations fully met.

An agile mindset, as well as sufficient support from management, project teams and customers/users, are critical to enable a successful adoption of agile methods. This requires proper training and the adaptation of the respective agile methods to company-specific needs. Moreover, a longer-term change management process may be needed to make the whole organisation more agile. To that end, suitable review and incentive systems may play a role in unfolding the full benefits of agile teams. Effective management of organisational interfaces between agile project teams and other parts of the organisation is important to avoid implementation hurdles. Overall, our findings suggest that German banks are still in a process of becoming more agile, both in IT projects and—although the strategic dimension of agility is beyond the scope of our study—most likely also on an enterprise level. Therefore, the accelerated adoption of agile methods in general, and possibly of scaled agile frameworks in particular, could help German banks to improve their competitiveness.

8 Further research

Our study also suggests further fields of research. Firstly, it would be interesting to see whether or not significant differences can be observed between our observations for the German banking sector and those of other major financial markets inside and outside the EU. Besides, we think that a closer examination of intra-company experiences could provide interesting insights, for example by comparing projects of different business divisions and/or between front- and back-office departments in banks. Moreover, the possible impact of a company’s phase of development (e.g. startups versus established firms) on the adoption of agile methods could be the subject of a broader cross-industry research project. Furthermore, there seems to be room to improve the alignment between the different participants and stakeholders of agile teams. Hence a deeper understanding of the performance drivers of agile teams—such as the composition and backgrounds of team members, cultural aspects or incentive systems—could provide valuable insights as well. Whether or not agile methods could benefit from the integration of lean management tools (e.g. Kaizen, Six Sigma) could also be an interesting research question. First attempts in this direction can already be observed, as the latest release of the SAFe framework demonstrates.

Although our banking-sector focused findings are in many regards (e.g. implementation hurdles, success factors) consistent with other cross-industry studies, certain aspects of our research (e.g. targets, expectations and experiences) have so far not been covered in larger samples, either from a cross-industry or from a sector-specific perspective. Therefore, it would be interesting to find out whether or not sector-specific patterns in the application of agile concepts can be observed.

The data suggest that banks have more difficulty achieving their cost savings and quality assurance targets than fintechs. In addition, the so far low adoption rate of scaled agile frameworks in German banks is noticeable. The study does not enable a deeper understanding of the underlying drivers of these observations, which could also be a field of future research projects.