Keywords

1 Introduction and Motivation

Several large enterprises are in the process of agile transformation. Cisco [1] and Ericsson [2] are only two examples. The Volkswagen Group is also concerned in particular the Volkswagen Group IT. To support this transformation from the IT Quality Management (QM) perspective, the Quality innovation NETwork (QiNET) was founded in late 2016 [3]. The QiNET is under the patronage of the Test and Quality Assurance (TQA) department of the Group IT. The QiNET scopes on innovative methods and approaches around IT QM and its organizational and technological challenges. The QiNET is driven by its community demands and the derived backlog. The QiNET product owner—this article’s first author—organizes and allocates resources for the outcome-responsible teams via the QiNET innovation procedure. Given that in this context, long-term resource allocation is highly restricted in general, iterative and incremental assemblies are the appropriate way to deliver products. The first author of this article is also the architect of the agile delivery approach that fulfills these needs and that has been successfully deployed at the Volkswagen Group IT.

The challenge is to develop holistic approaches for agile transformation which.

  • support in particular large enterprises comprising different brands and legal entities;

  • address a highly diverse product and service spectrum;

  • manage diverse regulation and governance demands;

  • ensure the integration of the IT QM aspects in the specific organizational setting.

    A lot of literature related to agile approaches and methods for scaling in enterprises exists. The most relevant in practice are Scaled Agile Framework (SAFe®) [4], Large-Scale Scrum LeSS [5], Nexus [6] and Spotify [7]. Others like Recipes for Agile Governance in the Enterprise (RAGE) [8] or Disciplined Agile Delivery (DAD) [9] have also gained significance. Domain-specific challenges have led to specialized agile frameworks such as R-Scrum [10] and SafeScrum® [11].

In order to develop and produce high-quality products and services in an agile way within a large corporate setting having the characteristics listed above, there needs to exists a close and mutual interrelationship linking the teams with their product/services and the corporate governance. This vital triangular relationship is depicted in Fig. 1. It is our fundamental assumption which we evaluated existing large-scale agile frameworks against in Sect. 2.

Fig. 1.
figure 1

Interaction between the team with the product and the enterprise governance.

Full size image

Products and services are valuable solutions provided for customers and users by the enterprise organization. They require skilled teams for their creation and deployment. These teams need skills and capabilities to deliver solutions on a high maturity quality level. They need to balance the solution-specific business values and risks during development and delivery. This permanent balancing is guided by the organization’s governance. However, the teams are part of the organization enhancing their own organizational setup, too. The governance therefore not only has to guide the teams in this process, it also has to assess their solutions to be compliant to market standards and regulations. This leads to solution-specific ventures which have to be addressed within the organization.

An analysis of software process improvement (SPI) was made in [12] and [13]. One important outcome of this analysis is that established centralized managed SPI initiatives have their difficulties within agile organizations. On the other hand, the agile project review [14] shows potentials in agile transitions and their sustainability. These two observations led to a systematic study of the issues causing the symptom of the missing link between the organization, its governance culture and agile teams. Agile teams have to work hard to get some real autonomy, because the established organization governance implementations do not foster agile working culture. Neither Scrum, SAFe® nor other frameworks address this governance topic, which is why the sustainable impact of the transitions are at risk.

With respect to the important relationship visualized in Fig. 1, the key weakness of existing approaches such as the ones listed before is that they only partially cover systematic QM and governance demands of large enterprises. Therefore, the research underlying this article aims at answering the following research questions (RQ):

  1. RQ.1

    What is a feasible design and implementation of a lean and agile enterprise framework that helps managing diverse regulation and governance demands?

  2. RQ.2

    How can aspects of governance and quality management be integrated by design in an agile transformation approach that fosters the autonomy of (product and/or service) teams?

  3. RQ.3

    How can highly diverse product and service offerings of a corporate group’s different brands and legal entities be adequately supported in the enterprises agile transformation process?

2 Literature Analysis

In [15], a definition is proposed for large scale development by a criteria set including, e.g., the need to have at least 50 individuals in more than five teams, be allowed to apply agile methods and coordinate teams and have the freedom to perform. Enterprises typically fulfill these criteria by their very size.

A huge body of literature related to agile approaches and methods for scaling in enterprises exist like [16]. As stated earlier, the most relevant in practice are Scaled Agile Framework (SAFe®) [4], Large-Scale Scrum LeSS [5], Nexus™ [6], Scrum@Scale [17] and Spotify [9]. We will characterize each of them briefly below, with respect to their coverage of enterprise governance and IT quality management (QM).

SAFe® [18] was introduced in 2007 with a focus on programs. The most recent versions include portfolio management and hence focus on enterprises. One of the SAFe® core values is “Built-In Quality”, however, the focus is on product quality that is achieved through testing and/or design for quality. The quality management aspect of continuous improvement is part of the learning culture with a modified PDCA cycle [19]: the A stands for adjust instead of act in the original plan-do-check-act cycle [20].

LeSS was introduced in 2007. A core concept of LeSS is to reduce organizational complexity. There also exist the LeSS and LeSS Huge frameworks that address the environment. Less Huge is used for organizations with more than eight teams and introduces requirement areas that sprint simultaneously. As part of technical excellence, LeSS focuses on testing in terms of test-driven development, thinking about testing, unit testing, as well as acceptance testing. LeSS explicitly eliminates support groups like “quality and process” as potential bottlenecks [21].

In 2015, the Nexus framework [6] was introduced by the agile pioneer Ken Schwaber [22]. It is based on Scrum and defines additional accountabilities to the roles. However, it does not explicitly address governance, compliance and quality. Nexus can be seen as the enhancement of enterprise Scrum (eScrum) [23] which was introduced by Ken Schwaber in 2007.

Scrum@Scale® [17] is the newest scaling framework introduced by the agile pioneer Jeff Sutherland in 2017. It is an agile scaling framework based on Scrum [24] and scales with the Scrum of Scrum (SoS) approach. It does not explicitly address aspects of governance and quality either.

The Spotify Model is not a scaling framework by design, but rather an agile organizational building block kit [25]. Squads are delivery teams and organized in Tribes. The Chapters group people with similar skills and Guilds are communities of interest. Squads and Tribes are like value streams, and Chapters and Guilds the special matter topic organization base for the employees. Both are a kind of a matrix organization. Accountability is realized by the product life-cycle and features end-to-end responsibility [26]. Furthermore, the concept of alignment enabling autonomy is used as a base for different Squads to work cooperatively on features, infrastructures or client applications.

Recipes for Agile Governance in the Enterprise (RAGE) [8] was introduced in 2013 as an approach focusing on making decisions repeatable and transparent. It distinguishes project, program and portfolio level. It uses Scrum and Kanban as a base for the governance extensions called recipes. Recipes are built on roles, ceremonies, artifacts, metrics and governance points. They can be combined with SAFe® on the program level. For implementation RAGE offers a white paper [27] and blog posts [28].

Disciplined Agile™ (DA) was introduced by Scott Ambler of IBM in 2012 and is currently maintained by the Project Management Institute (PMI). DA is a framework supporting agile and lean ways of work. The outcome is focused on solutions rather than on software only. It contains different blocks like Disciplined Agile Delivery (DAD) [9] and DAE [29]. The DAE focuses on enterprise aspects like legal [30] and governance [31]. Furthermore, it addresses quality [32] in the context of software development and technical debt via the DAD process goals. It emphasizes the construction phase and is not established as a holistic quality management approach.

LeSS and Nexus fully adopt Scrum, while SAFe® and DAD use many Scrum [33] practices in combination with practices taken from other approaches like Kanban [34]. Spotify and RAGE are more open and allow many approaches by design like Scrum, Kanban, Lean Startup [35] or other hybrid combinations.

Domain-specific challenges have led to related agile frameworks. In [36], the safety aspects in the automotive industry are discussed. Especially for safety there are the two approaches R-Scrum [10] and SafeScrum® [11], the latter explicitly addesses the IEC 61508:2010 [37] requirements. An agile enterprise framework has to be open for extensions of domain specific agile approaches [38,39,40] and should be able to integrate other domain-specific competence development frameworks [41]. Additionally exists needs to bring product and service teams very closely together, in the increasing trend towards Industrial Product-Service-Systems (IPSS) [42]. Finally, the framework has to be open and foster business agility [43] and organizational agility [44].

Another important aspect is to keep the organization lean by agile descaling, which is a principle behind the LeSS framework. XSCALE [45] is an initiative to form a collection of practices to realize descaling. Relevant aspects for the governance and quality are autonomy in alignment and learning ecosystems of the descaling values.

Based on the insights gained from a deeper literature analysis of existing large-scale agile approaches and frameworks, we derive the following research objectives (RO) to find answers to the research questions RQ.1–3 defined before:

  1. RO.1

    Design an actionable framework that can operate, adapt and co-exist with other existing established agile frameworks by complementing those.

  2. RO.2

    Design an actionable framework that supports descaling of organizations as a lean approach by fostering organizational structures that do not require deep hierarchies.

  3. RO.3

    Design an actionable framework that fosters autonomy for agile, responsive and nimble teams while keeping their compliance with governance aspects transparent.

3 Methodology

This work has taken action research approach [46] to derive the framework elements needed to comply with the RO.1–3 defined before. In order to design these elements, a design science research approach has been pursued [47]. Breaking down the holistic framework view into individual, however, interrelated elements enables the simultaneous involvement of specific subject matter experts to design methods and artifacts that fulfill the requirement of actionability, i.e., immediate practical relevance. In the last three years more than 14 persons from four legal entities of the Volkswagen Group made contributions via working groups supported by experts from universities, including lots of feedback from internal and external reviewers, early adopters, etc. For example, experts from the financial domain are experienced with handling financial regulation requirements. For technology topics, competence center experts are ideal partners for developing and challenging artifacts related to their technology domains. At the same time, these experts will foster the agile adoption of these new methods and artifacts through their own involvement in their design. These outcomes are part of the orchestration and topic management of the QiNET delivery approach. In all cases, the QiNET brought together the experts and the topics in the working groups. Furthermore, the applied methodical approach fulfills the aspects modularization and extensibility of the framework and its artifacts by design. The integration of the elements that have been developed and validated in a holistic corporate setting, leads to the composition of a holistic framework that can be generalized and instantiated in several different enterprises and industrial sectors.

To address the research objectives RO.1–3 adequately, the following framework requirements (FR) to the framework design are defined:

  1. FR.1

    Modularization to enable the co-existence with other frameworks (RO.1) and thereby avoid in/out decisions.

  2. FR.2

    Extensibility to adapt to demands that are specific for users, customers and domains, as well as established regulations and compliance requirements (RO.1).

  3. FR.3

    Accountability not based on hierarchy to ensure reliable value streams and (shared) responsibilities for the granted/received autonomy (RO.2–3).

  4. FR.4

    Organizational learning in a decentralized way to ensure continuous improvement and learning on a wide basis within the organization (RO.1–3).

4 Overview of the Framework Elements

Over the last four years, the EFIS framework was designed and established within the context of QiNET. Table 1 shows the individual framework elements, the references to the publication that describe their creation and deployment in the form of an agile transition facilitation kit, as well as their validation, all in the context of the Volkswagen Group IT. It also shows their mapping to the cornerstones of the agile quality management triangle in Fig. 1. The (x) in the LoD context around the product is motivated by the product market compliance which is typically expected by the customer/user like privacy and security aspects. The (x) in the leading edge technology area like evAIa or BSea is driven by the state of the art which is defined by the teams and the components of the products or services. The elements keep evolving over time through their increasingly intensive development and deployment on a corporate group level at the Volkswagen Group IT.

The handling of operational issues around product quality with the Product Quality Risk (PQR) method and its combination with technologies like Machine Learning (ML) or Blockchain in evAIa and BSea respectively were drivers for a product-centric orientation. The process and governance issue is addressed by the Level of Done (LoD) approach and the latter’s enhancement with the LoD layer concept. The LoD approach makes all relevant standard and regulation requirements transparent to the product team. To establish sustainable agile teams, the agile Team Work Quality (aTWQ) approach was designed. (De-) scaling and knowledge sharing were addressed by the Self-Service Kit (SSK) approach.

The core elements are generic and “bundled” into the EFIS framework which combines the elements to a holistic framework. The specific knowledge needed by some teams and organizations about e.g. new technologies such as Machine Learning and Blockchain is transparently available via SSKs. This makes it possible for the QiNET to build and deliver valuable solutions for the partners of the initial development and evaluation quality engineering setting, and later on for the entire enterprise without a large organizational support headcount and therefore a low induced support budget footprint.

Table 1. Coverage of the agile triangle in Fig. 1 by QiNET.
Full size table

QiNET’s work is visible inside and outside of the organization. It has led to the publications in Table 1 and to numerous invitations to conference committees and journal reviews.

5 The EFIS Framework

The EFIS framework is the compilation of key outcomes related to QiNET’s works listed in Table 1. EFIS combines its key building blocks to a holistic framework – the geared building blocks works together like a flywheel. The intention of the framework is to address compliance with regulation and governance requirements of large organizations in a lean and agile manner. It can be implemented as a stand-alone or as an overlay framework to address design weaknesses of existing frameworks in the context of large enterprises. The four pillars of this framework are.

  • Empower product teams by systematic team development for facilitation of autonomy with the aTWQ approach.

  • Focus on each product/service by handling their specific risks for high quality deliveries with the PQR approach.

  • Integrate processes by interface-driven flows for ensuring that business domain- specific regulation and governance requirements are implemented for reliable value streams with the LoD approach.

  • Scale knowledge beyond individual experts and teams by encouraging knowledge self-services for organizational learning with the SSK approach.

The EFIS framework does not explicitly require further methods, practices, roles etc. because by design, it is open for individual adaption by the product teams to fit their specific demands. Thanks to its lean mindset, EFIS supports the descaling of organizations, since it does not require new organizational roles or hierarchies. Furthermore, existing roles and hierarchies can be mapped to EFIS, in order to reduce overhead as much as possible during the adoption process.

Figure 2 presents an overview of the EFIS framework in an enterprise context. Internal and external regulations (top right) interact with a particular Organization@Enterprise (center). The latter’s autonomous value streams implement the business domain-specific regulations and relevant standards the organization is accountable for. Stakeholders contribute knowledge and tool libraries for their domains (bottom right), serving as means of governance interaction between the organization and the enterprise. Each value stream instantiates the relevant library artifacts and enhances them if needed through its contributions via the Scale pillar (bottom left).

Fig. 2.
figure 2

The EFIS framework for autonomous value streams of an enterprise.

Full size image

Table 2 compares the most relevant agile frameworks and models for enterprises with the EFIS framework. The aspects were selected with the scope of large heterogeneous enterprise demands. Descaling was not been selected, even though it should be a strategic element of all agile initiatives to ensure sustainable agile proceedings by avoiding complexity by design were possible.

Table 2. Comparison of different agile approaches in enterprise contexts.
Full size table

The EFIS framework’s adaptability to domain- and team-specific demands, as well as its capability of being used as a stand-alone or as an overlay framework, makes it compatible with any other agile approaches wherever a co-existence of several frameworks is considered appropriate. Based on the building block design of the EFIS pillars it is possible to implement EFIS building block based to address identified gaps in the existing setting and avoid redundancy – however in all cases the completeness about the EFIS framework aspects of the implementation setting should not be lost.

6 Evaluation and Discussion

In order to show the adequacy of EFIS, we evaluate it against the framework requirements (FR) derived previously in Sect. 3, the research objectives (RO) specified in Sect. 2, as well as the research questions (RQ) defined in Sect. 1.

The Modularization (FR.1) is achieved by the possibility to adopt only selective elements of the framework, such as the PQR method or the LoD approach. The Extensibility (FR.2) is realized by the framework’s open design, which does not depend on other frameworks, and makes it possible to use it as a stand-alone or for example together with Scrum or SAFe® or any other agile method. The Accountability (FR.3) is realized by the shared responsibility approach with leads to autonomy by mastery. Both are part of the LoD and aTWQ approach, which enable mature teams to work more autonomously through the demonstration of high team maturity and LoD-compliant delivery. Learning (FR.4) is realized by the SSK approach, which can be applied to both business and technology domains, as well as to different organizational levels.

The operates and co-exists (RO.1) is given by the implementation of FR.1 and FR.2. The descaling of organizations (RO.2) is given by the composition of the EFIS pillars, which does not require any kind of hierarchy. This makes is possible to build “flat” organizations with few experts, who can be grouped virtually to deliver and maintain LoD layers or dedicated knowledge in SSKs. The fosters autonomy (RO.3) is mostly given in the EFIS framework by the aTWQ approach, which focuses on teams. These teams do not have to be the product delivery teams of an organization. Also virtual teams like experts for a specific SSK can apply aTWQ.

The managing diverse regulations and governance demands (RQ.1) is handled by the EFIS framework’s I-pillar for Integration with the LoD approach. Governance and quality management integration (RQ.2) is primarily handled by the EFIS framework’s F- and I-pillars with focus on products and services with the PQR method and the integration with the LoD approach. Highly diverse product and services of the different brands and legal entities (RQ.3) are addressed by the EFIS framework’s openness and extensibility, which make it easy to adapt to different specific demands.

Different instantiations and adoptions of EFIS exist in different legal entities. One example for the finance domain is described in [49]. Another example is the value delivery stream around TaaS [66]. One observation is that all instantiations are value stream-specific because their LoD addresses the product domain-specific compliance demands that impact the framework’s instantiation and adoption. Another aspect is that the instantiation varies depending on the organizational size and its agile adoption. This is the motivation for the design of a transition kit [60] to handle this specific demand. However, the focus on the teams’ quality development as an extended quality view needs to be implemented in all instantiations in order to assure the holistic coverage of quality management and culture.

An example for a larger application is an organizational unit with five value streams. Each stream consists of at least one team. Some teams have additional external independent contractor teams working aligned with relevant EFIS elements like the product domain-specific LoD for compliant deliveries.

Figure 3 presents the extended quality view, which is an implicit additional outcome of the EFIS framework. Established quality management focuses on product and process quality. The quality management of agile organizations has to focus on the team quality, too. During the evaluation, the application of the aTWQ approach in a cyclic way reveals the teams’ progress in their agile maturity levels. It is worthwhile noting that we observed that changes in team compositions will not negatively impact this maturity progress as long as the affected teams were able to compensate the changes themselves autonomously.

Fig. 3.
figure 3

The tree pillars of quality management in agile organizations.

Full size image

It is also worth mentioning that one SSK has been integrated in the Volkswagen Group IT Architecture Guiding Principles (IT-AGP) compiling group-wide policies, guidelines and best practices. This shows that the structured content of SSKs gains additional relevance over time if it is pulled by the related governance instances, in this case the Volkswagen Group IT Enterprise Architecture Management (EAM).

The effort to instantiate the EFIS framework can be seen as acceptable for a team with in best case situations with a half day EFIS introduction training for the team. The aTWQ instantiation can be realized in the context of existing retrospectives. The first aTWQ self-assessment takes one to one and a half hour – follow-up sessions mostly half an hour less. The initial PQR workshop often is approximately two hours – the follow-up is typically much shorter. The instantiation of the LoD depends on what is pre-elaborated by the governance. If only pre-designed LoD layers have to be “checked” about instantiation a few hours are needed. To develop a new LoD from scratch can take several days and depends on the regulations and organization setup to get commitment. The usage of SSKs reduces efforts – feedback to the SSK owner is also not to mention. To produce for a new SSK starts at a few hours if only the existing knowledge have to be written down in the SSK format – if content have to be elaborated it can take much more time. Overall the effort for the EFIS instantiation and establishment depends on the organizational setup and agile mindset and maturity of the product teams. Also the product impacts the effort with the amount of regulations and standards which have to be addressed and the need for PQR updates depends on the specific product life-cycle.

7 Contributions, Limitations and Perspectives

7.1 Contributions

The key contributions of EFIS with its pillars and building blocks to practice can be summarized as follows:

  • An approach to scaling and descaling agile organizations with lean approaches and models as the core building blocks of the framework.

  • Open, adaptable design enabling the overlay and stand-alone integration option to organizations and teams for combining different lean and agile concepts.

  • Establishment of an explicit shared responsibility and accountability to foster governance and compliance with the “autonomy by mastery” paradigm for teams.

  • Positioning of teams as the key to success with the three pillars of quality, which is fostered by the aTWQ approach as core element in the EFIS framework.

  • Organizational learning through the SSKs as practice collections while preserving the autonomy of distributed teams.

  • Develop building blocks in independent teams (with experts from the legal entities with the highest requirements) for a holistic framework works well.

The key contributions to theory can be summarized by the following aspects:

  • Closing of the gap of existing agile frameworks and models in the context of enterprise governance for quality management and compliance.

  • Closing of the gap in quality management that is demanded by the core element of agile environments: the team.

  • A three-pillar quality approach to emphasizing teams as the major key to success in agile environments.

  • A model including governance as a core element of an enterprise-level agile framework.

  • An approach to distributed organizational learning based on practices derived from experience and learnings.

7.2 Limitations

One obvious limitation of the presented work is that it has been achieved in only one large multi-national enterprise, with a focus on the automotive (with includes processes like production, mobile online services or after sales) and finance domains. Furthermore, the research has taken an IT perspective for integrating specific technologies like cloud, machine learning and blockchain. Other enterprises may have other needs and priorities. We are nonetheless confident that the results and outcomes we have achieved can also be validated in other business domains like government, energy, education or agriculture.

Business and industry domains that are less technology-driven than the automotive sector might need an adaptation of the presented approaches and framework. Apart from this, the predominant technologies might also differ, which would imply moving the focus from IT to e.g. industrial engineering technologies. However, since IT is at the core of modern Industry 4.0 environments, the strong IT orientation of the current framework design should not be an obstacle.

Some further design limitations of the presented initial EFIS framework version are the following:

  • EFIS does not yet explicitly guide the teams during instantiation and adaption of elements of the framework depending on scenarios.

  • EFIS does not yet have a generic set of metrics for a systematic data-driven improvement of the specific instantiation and adoption of EFIS.

  • EFIS is not yet provided as a fully-blown service, like SAFe® or other frameworks, including exhaustive online documentation and various training packages and certified coaches.

  • EFIS does not yet have any open governance instance, like the Mozilla foundation, which collects feedback from all adopters to enhance and evolve the framework in a generic and public way.

Additionally, the aspect of sustainability of the effects and observations we made over four years of time of simultaneous development and deployment need to be validated in the long-term perspective. Huge corporate programs typically have a lifecycle of at least a decade, which is a timespan that could not be covered in the current work.

7.3 Perspectives

Depending on its diffusion and deployment within Volkswagen, the generic and holistic EFIS framework has the potential to become the Volkswagen model for agile organizations. Already at this current stage, all the presented elements have been usable stand-alone in organizations and teams to foster and improve lean and agile working within large enterprises. This bottom-up approach by “cherry picking” is how all the outcomes can be used in other organizations and enterprises, too.

Along the way to becoming more viral, an online framework documentation can be established. In addition to the online documentation, framework- and pillar-specific trainings can be designed for sustainable and well-defined knowledge transfer to potential implementers and adopters. To scale this knowledge, certifications for EFIS coaches and trainers can be established. Furthermore, a step in the direction of public governance is to setup an EFIS foundation. This foundation has to ensure that feedback and lessons learned about the EFIS instantiations are systematically collected and used for a continuous improvement and evolvement of the EFIS framework. This foundation can also group and select practices for domains or offer LoD layers for their domain- specific regulation as a public property. This will reduce the work of organizations significantly and help to define a de-facto interpretation of regulations which encourages organization to implement these “publicly validated” LoD layers.

Also, there is a research gap about up to which level of complexity – the product/service, regulation etc. – EFIS is useful, in order to avoid too many restrictions for the teams and organizations. To leverage this, a set of key performance indicators assisting the decision-making concerning the required depth of EFIS implementation are required, including methods of collecting those in a way that teams are not impacted.

Another open end is the governance of the EFIS instantiation. To facilitate this, a set of metrics will be useful. This set of metrics can also be used to benchmark organizations.