Alexander Poth
email: alexander.poth@volkswagen.de

Mario Kottke
email: mario.kottke@volkswagen.de

Christian Heimann
email: christian.heimann@volkswagen.de

Andreas Riel
email: andreas.riel@grenoble-inp.fr

Jan Jacobsen
email: jan.jacobsen@vwfs.com

Kerstin Middelhauve
email: kerstin.middelhauve@audi.de

Torsten Mahr
email: torsten.mahr@vwfs.com

The EFIS Framework for Leveraging Agile Organizations Within Large Enterprises

Keywords: Large-scaling agile, Agile transformation, Agile framework Software development management Á Agile software development Á Regulation compliance Á Large scaling agile Lean Software Development, Agile Software Development, IT Governance, IT Compliance Categories: D.2 Agile team work quality (aTWQ) Á Large-scaling agile Á Quality assurance (QA) Á Agile transformation

In the context of the fourth industrial revolution, many large established organizations and enterprises are conducting an agile transformation. The agile culture requires autonomous teams for sustainable adoption of agile approaches and methods. Building on personal and professional responsibility chains rather than on hierarchy, this autonomy mindset has a huge impact on required governance structures affecting in particular accountability and quality management. Established agile frameworks, like SAFe® or Scrum, do not address the challenges related to reorganizing compliance structures accordingly.

This doctoral thesis proposes the EFIS framework as a novel holistic approach to complementing existing agile frameworks. EFIS builds on loosely coupled building blocks that facilitate agile adoption. At the very heart of them is systematic team empowerment to foster product-specific mastery of teams that ultimately leads to team autonomy through the assumption of responsibility as part of shared responsibility. EFIS' key building blocks for team empowerment for both responsible collaboration and technical mastery are agile Team Work Quality (aTWQ) and Technical Team Maturity (TTM). The Product Quality Risk (PQR) building block supports teams in systematically focusing on product risks. This is complemented by Level of Done (LoD) helping them to integrate specifically regulation and governance requirements.

In order to leverage its fast adoption and scaling on a large enterprise level, the thesis proposes the Self-Service Kit (SSK) approach as a fundamental part of EFIS that by itself fosters autonomy and asynchrony with knowledge scaling. Teams act as prosumers, most time they consume the offered SSK's. However, some individuals or teams develop new knowledge during their product specific work. As a kind of mastery, they can share this by extending or building SSK's.

By design, the EFIS framework works like a flywheel for agile transformation: teams grow in their maturity and mastery, mastery leads to autonomy, autonomy leads to self-responsible decisions and actions, actions lead to insights, and insights lead to learnings that can be scaled and make other teams more mature. EFIS' building blocks are systematically provided to teams for example based on regular aTWQ team maturity evaluation, which forms an integral part of the agile transition facilitation and governance process of the company's IT. EFIS is also modular and open to integrating domain-and technology-specific elements and building blocks to adapt to the product teams' demands.

Using a methodological approach that combines Design Science with Action Research, the entire EFIS framework has been developed, deployed, and validated in different legal entities and business domains of a German automotive OEM over the last five years. At this stage, it has become an instrument for the company's agile transition towards a more nimble enterprise.

Résume

Dans le contexte de la quatrième révolution industrielle, de nombreuses grandes groupes industriels mènent une transformation agile. La culture agile nécessite des équipes autonomes pour son adoption durable. S'appuyant sur des chaînes de responsabilité personnelle et professionnelle plutôt que sur une hiérarchie, cet état d'esprit d'autonomie a un impact considerable sur les structures de gouvernance requises, en particulier sur la responsabilité et la gestion de la qualité. Les cadres agiles établis à ce jour, comme SAFe® ou Scrum, ne relèvent pas les défis liés à ces aspects.

Cette thèse propose le cadre EFIS comme une nouvelle approche holistique pour compléter les cadres agiles existants. L'EFIS s'appuie sur des éléments constitutifs faiblement couplés qui facilitent l'adoption agile. Au coeur même de ceux-ci se trouve l'autonomisation systématique des équipes pour favoriser la maîtrise spécifique des équipes qui conduit finalement à leur autonomie grâce à la prise de responsabilité partagée. Les éléments clés de l'EFIS sont la qualité du travail d'équipe agile (aTWQ) et la maturité technique de l'équipe (TTM). L'élément risque qualité produit (PQR) aide les équipes à se concentrer sur les risques produits. L'élément du niveau de réalisation (LoD) les aide à intégrer spécifiquement les exigences de la réglementation et de la gouvernance.

Un autre élément fondamental de l'EFIS est le concept du kit libre-service (SSK) qui en soi favorise l'autonomie et l'asynchronie pour la mise à l'échelle des connaissances. Les équipes agissent comme des prosommateurs : la plupart du temps, elles consomment les SSK proposés. Cependant, certaines personnes ou équipes développent de nouvelles connaissances au cours de leur travail spécifique à un produit. En guise de maîtrise, ils peuvent partager leurs connaissances aquises en étendant ou en construisant des SSK.

De par sa conception, le cadre EFIS fonctionne comme un volant d'inertie pour la transformation agile : les équipes grandissent dans leur maturité et leur maîtrise, la maîtrise conduit à l'autonomie, l'autonomie conduit à des décisions et des actions auto-responsables, les actions conduisent à des apprentissages qui peuvent être mis à l'échelle et rendre les autres équipes plus matures. Les éléments constitutifs de l'EFIS sont systématiquement fournis aux équipes, par exemple sur la base d'une évaluation régulière de la maturité de l'équipe aTWQ, qui fait partie intégrante du processus de facilitation agile de la transition et de la gouvernance de l'informatique de l'entreprise. EFIS est également modulaire et ouvert à l'intégration d'éléments spécifiques à la technologie et au domaine afin de s'adapter aux demandes des équipes produit.

En utilisant une approche méthodologique combinant la science de la conception et la recherche en action, l'ensemble du cadre EFIS a été développé, déployé et validé dans différentes entités juridiques et domaines d'activité d'un équipementier automobile allemand au cours des cinq dernières années. À ce stade, il est devenu un instrument essentiel à la transition agile de l'entreprise.

List of Essential Abbreviations and Symbols

AI

List of Figures

Figure 1: The Agile QM Triangle -Team, Product/Services, Governance . Figure 2: The EFIS framework for autonomous value streams. ................. Figure 3: The tree pillars of quality management in agile organizations. ...

List of Tables

Thesis Structure and Reading Guide

This thesis is designed as a compilation of all the publications that have been issued from my work. This is primarily due to the fact that any of these publications has had to undergo a detailed and strict verification and validation procedure at the Volkswagen AG, before being released for publication. Such a procedure, however, is not foreseen for PhD thesis documents. Yet, my PhD supervisor and I placed a high value and emphasis on the PhD thesis be publicly available rather than confidential, in order to create impact. By compiling published papers, we could overcome this process.

In order to provide a holistic overview of the key contributions of each publication the main part of this dissertation document is composed of seven sections that resemble the structure of a traditional PhD dissertation document. The literature analysis there is limited to the overall EFIS framework that integrates all the thesis' key contributions, as are the references listed in the corresponding section. In order to assure compliance, this part has been reviewed by the Volkswagen AG as well, and published at the EuroSPI 2021 conference [AP2].

Detailed literature reviews for each contribution are part of the related publications, which are characterized in detail in Appendix A. In order to still provide a guide through the literature reviews, and their relationships with the overall framework, Appendix B provides a graphical overview of the essential literature review topics per paper.

Appendix C picks and chooses key figures and tables from each paper, in an attempt to provide a guided tour through the contributions, and their interrelationships. Finally, Appendix D contains all the publications issued from this PhD thesis work in full length.

Given this structure, it is recommended to completely read the seven sections to get a holistic insight into the key research questions and the achieved contributions of the thesis. Subsequently, to pick individual building blocks and understand their integration in the holistic framework, Appendix A to C should be studied before and after reading the most relevant papers for the chosen blocks.

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 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 -the thesis 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 thesis author 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 Figure 1. It is our fundamental assumption which we evaluated existing large-scale agile frameworks against in section 2. 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 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 Figure 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): RQ.1 What is a feasible design and implementation of a lean and agile enterprise framework that helps managing diverse regulation and governance demands? 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? 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?

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. As stated earlier, the most relevant in practice are Scaled Agile Framework (SAFe®) [4], Large-Scale Scrum LeSS [5], Nexus™ [6], Scrum@Scale [16] 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® [17] 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 [18]: the A stands for adjust instead of act in the original plan-do-check-act cycle [19].

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 [20].

In 2015, the Nexus framework [6] was introduced by the agile pioneer Ken Schwaber [21]. 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) [22] which was introduced by Ken Schwaber in 2007.

Scrum@Scale® [16] is the newest scaling framework introduced by the agile pioneer Jeff Sutherland in 2017. It is an agile scaling framework based on Scrum [23] 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 [24]. 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 lifecycle and features end-to-end responsibility [25]. 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 [26], videos [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: RO.1 Design an actionable framework that can operate, adapt and co-exist with other existing established agile frameworks by complementing those. 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. RO.3 Design an actionable framework that fosters autonomy for agile, responsive and nimble teams while keeping their compliance with governance aspects transparent.

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 three 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: FR.1 Modularization to enable the co-existence with other frameworks (RO. 1) and thereby avoid in/out decisions. 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). FR. 3 Accountability not based on hierarchy to ensure reliable value streams and (shared) responsibilities for the granted/received autonomy (RO.2-3). FR. 4 Organizational learning in a decentralized way to ensure continuous improvement and learning on a wide basis within the organization (RO. [1][2][3].

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 Figure 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. 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. 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 QM Triangle by EFIS elements.

Contribution/ reference

Team Product/Services Governance enhance make demand venture assess guide EFIS framework [48] x x x x x x

Level of Done (LoD) approach [49] [50] x (

LoD layer concept [51] x (

x aTWQ approach [52][53] [START_REF] Poth | Measuring team work quality in large-scale agile organizations[END_REF] x x TTM approach [START_REF] Poth | Teamwork quality in technology-driven product teams in large-scale agile organizations[END_REF] x x

Product Quality Risk (PQR) method [START_REF] Poth | Quality requirements elicitation by ideation of product quality risks with design thinking[END_REF] x x x Self-Service Kit (SSK) approach [START_REF] Poth | The implementation of a digital service approach to fostering team autonomy, distant collaboration, and knowledge scaling in large enterprises[END_REF] [START_REF] Poth | Scaling agile on large enterprise level with self-service kits to support autonomous teams[END_REF] x x

Transition-Kit [START_REF] Poth | Scaling agile on large enterprise level-systematic bundling and application of state of the art approaches for lasting agile transitions[END_REF] [START_REF] Poth | Scaling Agile-A Large Enterprise View on Delivering and Ensuring Sustainable Transitions[END_REF] x x evAIa [START_REF] Poth | Quality Assurance for Machine Learning -an approach to function and system safeguarding[END_REF] (x) x (x) x x x BSea [START_REF] Poth | Quality Assurance for Block-chain-based Services. A Systematic Guidance Framework[END_REF] (x) x (x) x x x AI4QA [START_REF] Poth | Artificial Intelligence Helps Making Quality Assurance Processes Leaner[END_REF] x Serverless sustainability [START_REF] Poth | Sustainability Efficiency Challenges of Modern IT Architectures -A Quality Model for Serverless Energy Footprint[END_REF] x x x CI/CD aspects [START_REF] Oyelami | Quality Assurance and Traceability in Containerized Continuous Delivery Process[END_REF] x x

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

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.

Evaluation and Discussion

In order to show the adequacy of EFIS, we evaluate it against the framework requirements (FR) derived previously in section 3, the research objectives (RO) specified in section 2, as well as the research questions (RQ) defined in section 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 [START_REF] Poth | Scaling agile on large enterprise level-systematic bundling and application of state of the art approaches for lasting agile transitions[END_REF]. Another example is the value delivery stream around TaaS [START_REF] Poth | Make product and service requirements shippable -from the cloud service vision to a continuous value stream which satisfies current and future user needs[END_REF]. 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 [START_REF] Poth | Scaling Agile-A Large Enterprise View on Delivering and Ensuring Sustainable Transitions[END_REF] 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.

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

7

Contributions, limitations and perspectives

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.

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.

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

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

Agile Teamwork Quality (aTWQ)

Figure 4 shows the process how aTWQ should be used to identify significant issues. A good practice is to evaluate the first data at the end of the transition phase, and then regularly every 6-9 months.

Technical Team Maturity (TTM)

Figure 6 presents the TTM as an extension for technology-specific maturity aspects to the aTWQ approach. The TTM Reference Model (TRM) is a pattern that can be instantiated for different technologies like cloud or machine learning. The TRM is refined by the TTM Evaluation Model (TEM), which checks against the specific technology's current state of the art at a given time in the form of a technology audit. The TEM is appropriate for governance aspects to get a compliance overview. The TTM Belt Model (TBM) is designed to enable teams to develop their maturity and compare each other based on their belts. This benchmarking approach is used as a kind of gamification between teams to drive their continuous improvement. The teams have to select one or more relevant TTM Technology Models (TIM) to address their product-specific demands. This implies that teams can have different belts depending on the selected TIMs.

Product Quality Risk (PQR)

Figure 7 shows the high-level iterative quality strategy for product development in the Volkswagen Group IT. The PQR approach mostly supports the steps 1a, 2a, 3 and 4. Guided ideation directly addresses step 1a). Figure 8 shows the set of ideation methods used in the currently rolled-out version. While implementing mitigation actions, the teams can iterate for an incremental ideation of their product quality risks as new insights become available. This is visualized by the blue circle in the lower part of Figure 8. The amount of four ideation methods turned out to be an adequate trade-off between output quality and quantity and team acceptance. The opening phase shown in Figure 8 is used to establish a common understanding in the team about their product and influence to the product design, development and delivery. This phase spans up the product quality risk space that shall be handled in the subsequent focusing phase. Figure 9 depicts the flow from the posters to the story. On the bottom-right, Figure 9 shows the risk ideation with a filled Pre-Mortem poster. Based on the ideated Pre-Mortem quality risks, the PQR definition (mid-left in Fig. 11) was used to derive the quality risks with Risk-Carousel for the systematic handling during the next phases of the product/service life cycle. The PQR mapping to the story is based on the story template with the acceptance criteria (AC) header and the PQR's block. Each of the four PQR's is considered for each story. In the upper-right part of Figure 9, the last six lines of PQR mapping to story are the part in our focus. In the story template, the four bullet points come with empty parentheses. Depending on the risk, the mitigation is based on constructive actions like a special design (e.g. the isolation of the workload in the first of the four bullet points within parentheses in Figure 9) or analytic actions (e.g. the cyclic testing to detect derivations in the second of the four bullet points within parentheses in Figure 9).

Level of Done (LoD)

The LoD building block facilitates identifying all the regulations and standards that are relevant for the enterprise to provide compliant products and/or services. It helps identify how many stages shall be available for product development via a Kanban board. The Kanban board helps to identify handoverpoints in a work stream. These points are the most relevant for LoD. Enabling teams to choose the most effective ways to comply with regulatory relevant outcomes by mapping them to the stages of the Kanban board. A transparent traceability from the regulation to the LoD will facilitate regulation adoption. However, finding adequate implementations should be delegated to the team to give them freedom to find solutions that fit into their particular context. The openness about how to reach the outcomes give the teams the autonomy to work as it is best for their specific demands and the mastery (responsibility) about their implementations. Add the PQR dimension to assure that products and services have a comprehensive quality approach (Figure 10). The decision of a pre-or post-deployment check is based on Table 3 (Check time). Relevant parameters are the product risks form the deployment, the team maturity and the accountability of the team. Based on the parameter value combination the check is done with a high sample size and preventive (bevor deployment) down to a low sample size and detective (after deployment).

LoD Layers

Different LoD layers are combined to build a complete LoD for a specific product. The layers can address domain-specific regulations and organizational compliance aspects. This makes it possible to stack layer by layer to a fitting domain-specific LoD. For example, the base layer could be the domain-specific regulation layer, the organization layer can be stacked on top, and finally the product-specific regulations layer could be added. Figure 11 visually presents the merging of two LoD layers. To ensure that the responsibility and accountability for the compliance is established adequately, the organization has to identify the appropriate type of accountability. In classical enterprises, accountability is mainly allocated per hierarchy and legal competences. Often less pronounced are personal accountability by culture, value and ethics as a second type of accountability. Other types of accountability are included as a kind of "supporting" accountability to the main type. In agile mindsets and methods, the professional accountability with peer reviews and professional roles with expert scrutiny are dominant.

Figure 12 shows the schematic concept behind the shared responsibility of compliance and accountability. Each team has an exposed person who is accountable for the team. However, everyone in the team can take over tasks as a responsible person. The shared responsibility between the governance and the product teams is realized by the instantiation of the relevant LoD layers for the specific product setting.

Self-Service Kit (SSK)

The fundamental SSK artefacts are as follows (Figure 13):

• A short introduction including: o Information about the purpose of the SSK. o Overall instructions how to use it. o A summary of the SSK's contents. • The core working artefacts are materials that shall be used to produce the desired outcomes, or otherwise the outcomes themselves in the form of templates, spreadsheets for checklists, as well as documents and vector-graphics that can be scaled to posters to facilitate interactive team work. • Background information about the SSK providing answers to fundamental or frequently asked questions linked to the SSK's motivation, its purpose, its producers and supporting communities, etc.

Transition Kit

The outcome of the toolkit's application to the Volkswagen AG Group IT is shown in Table 5. The first column lists the toolkit's artifacts as methods and tools resulting from the grounded theory derivation process. The second column represents the team maturity rating according to the spiral dynamics model. The third column shows the Stacey matrix mapping. It is certainly possible to apply methods/tools in other settings of the spiral dynamics or Stacey mapping, however in the specific enterprise setting this is not recommended.

Motivation, Context and Methodology

In the ongoing trend of the agile transformation of large companies, the set of established large-scale lean and agile frameworks has grown to a considerable number. The most established ones in practice are Scaled Agile Framework (SAFe®) [1], Large-Scale Scrum LeSS [2], Nexus [3] and Spotify [4]. Domain-specific challenges have led to specialized methodologies such as R-Scrum [5] and SafeScrum® [6] for safety. Additionally, agile organizations should address autonomy, mastery and purpose adequately [7].

Analyzing these frameworks, we identified the following shortcomings:

(1) The governance in terms of a reliable chain of accountability, responsibility, sharedresponsibility, mastery and autonomy is only vaguely addressed. (2) Measuring the progress of the adoption of framework practices by the teams and the overall organization is not clearly covered by indicators and methods. (3) Scaling of the framework practices without significant coaching and training efforts is not explicitly addressed.

This paper proposes the EFIS (Empower, Focus, Integrate & Scale) framework that aims at addressing these shortcomings from a holistic perspective. It has been designed with a bottom-up design science research approach [8] within the context of the Volkswagen Group IT. Over a timespan of five years, several building blocks have been designed, implemented, evaluated and improved. Their proven-in-use designs have been integrated in a larger framework, paying close attention to the consistency between blocks in order to ensure a holistic perspective when addressing the organizational challenges. The validation of the entire framework has been done implicitly through the validation of each building block in at least two different organizational units, as well as by measuring several teams' agile maturity progress over time.

Section 2 presents the literature and established agile frameworks. Section 3 elaborates on the architecture and application of EFIS, as well as its key characteristics. Section 4 explains how EFIS helps implementing accountability at large-scale through mastery within the scope of an agile team. Section 5 reports on how EFIS has been implemented at the Volkswagen AG, and critically evaluates success. Section 6 discusses the limitations. Finally, Sect. 7 concludes by summarizing the article's key contributions to research and practice and giving an outlook to the authors' ongoing research activities.

Established Agile Frameworks and an Literature Overview

One of the SAFe® [9] 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 [10]: the A stands for adjust instead of act in the original plan-do-checkact cycle. A core concept of LeSS [2] is to reduce organizational complexity. 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 [11]. Nexus [3] 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). Scrum@Scale™ [12]: It is an agile scaling framework based on Scrum [13] 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 [4]. Accountability is realized by the product life-cycle and features end-to-end responsibility. 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) [14] are 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 [14] and blog posts [15]. Disciplined Agile™ (DA) [16] 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) and DAE. The DAE focuses on enterprise aspects like legal and governance. Furthermore, it addresses quality in the context of software development and technical debt via the DAD process goals.

The Architecture and Characteristics of EFIS

Figure 1 shows an overview of the EFIS framework and the interaction of its individual building blocks. Internal and external regulations (right-hand side) interact with a particular organization within the enterprise (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). The operational core is the instantiation of the Focus and Integration pillars by identifying the specific product and service quality risks and integrate the related mitigation actions into the value streams' committed set of regulation and standard requirements. Once the requirements are implemented and validated systematically they assure compliant delivery outcomes. The Empower pillar (top left) continuously improves teamwork quality, for more mastery which leads to more autonomy, limiting the need for regular team supervision and evaluation.

Openness by design is a cross-cutting aspect for all pillars, and therefore not explicitly modelled. It is achieved by reducing the recommended practices to a minimum. This reduces potential conflicts with other practices and methods that can be included.

Empower. Empowerment of product teams and their organization is achieved through systematic team development that leads to mastery, which is the prerequisite for letting them take over responsibility for their actions in an autonomous way. This, in turn, is indispensable for governing the accountability for any shipped deliverables. Empowered teams can build and improve their delivery procedures and processes independently for fast and innovative solutions. The enabling building block for systematic team empowerment is aTWQ (agile Team Work Quality) as introduced in [17].

Focus. Focus shall be set on each product/service by handling their specific risks for high quality deliveries. Each product or service comes with its business chances that also imply risks that need to be continuously investigated and updated. Systematic risk mitigation actions need to be derived and the effectiveness monitored. At the same time, the organization has to remain open for new innovative products and improvements and associated new risks. EFIS provides the building block PQR (Product Quality Risk) as introduced in [18] to address keeping focus.

Integrate. Integration of processes by interface-driven flows ensure that business domain-specific regulation and governance requirements are implemented for reliable value streams. Value streams need to be identified, including their interfaces and handover points. Regulation requirements have to be identified and derived for these value streams and their outcomes, and mapped to the hand-over points. Optionally, organizational intellectual property artifacts related to the value stream can be added to the hand-over points to ensure the property exploration within the value stream processing. Controls associated with the hand-over points enable compliance checks. One assigned individual assures the accountability for the implementation and the compliance governance of the value stream. The EFIS building block to instantiate systematic process integration is LoD (Level of Done) as introduced in [19].

Scale. Scaling of knowledge beyond individual experts and teams is achieved through encouraging knowledge self-services for organizational learning through a prosumer (producer and consumer) principle. Learning from self-services to become more mature within the business, product or service domain is encouraged. As are the sharing of any team learnings with others by building new knowledge self-services and updating existing ones. EFIS adopts the SSK (Self-Service Kit) approach as introduced in [20].

The EFIS framework establishes accountability: mature teams master their deliveries, hence they can take responsibility for their actions which enables autonomy.

Leveraging Compliance Governance with EFIS

In organizations, development and delivery processes are confronted with a growing number of regulation requirements. To avoid process complexity becoming ever larger, product-and service-related risks can be integrated into corporate governance. In an agile organization, this is feasible since the product teams are responsible for both the process and the product compliance. In EFIS, we integrated guidance and support for this incorporation process through the Product Quality Risk (PQR) building block [18]. EFIS builds on the shared responsibility commitment between the enterprise governance and the local organizational governance for example of a subsidiary or unit. The enterprise governance is able to delegate risk management to the local organization within a shared responsibility approach -however, the local organization risks are still part of the enterprise risk. With this approach, the process and procedure complexity can be reduced by focusing to the explicit process demands for compliance for the specific product -complex one size fit all processes are simplified to the specific products.

All procedure-and process-related compliance aspects are guided by the LoD building block [19], with the topic tasks (t) derived from the regulations. The delivery of relevant internal organizational structures like interfaces and handover-points are modeled through the number of LoD levels. The LoD incorporates the product-specific PQR mitigation actions. The LoD and PQR together make up the core of the lean compliance approach, as depicted in Fig. 2. To reduce the amount and efforts for compliance checks, the organizations' product teams have to be enabled to build compliant deliverables (entire products or services or parts of them as parts of their solutions) and assure their compliance continuously. To realize this, the teamwork quality is key: a more mature teamwork leads to better outcomes, as well as increased performance and quality of deliverables. The team maturity and mastery grows with the teams' skills and capabilities, and the organization can trust and rely on the shared responsibility principle. A highly matured team can master their products and services and work autonomously. To make team maturity transparent and help improve it, the aTWQ approach [17] is part of the empowerment pillar of the EFIS framework.

Scaling individuals' and teams' knowledge within large-scale organizations requires encouraging employees, especially experts, to share their knowledge. In large organizations, however, not all employees know each other. Furthermore, they need to synchronize information and knowledge because the teams' product and service life-cycles are mostly independent of each other. This leads to the demand of providing expert knowledge independently of the experts' current availability. In the EFIS framework, this was realized through the SSK (Self-Service Kit) approach [20]. The essential idea behind SSKs is to share several proven-in-use practices rather than enforce particular practices as a one-size-fits-all approach. The organization and enterprise can further foster the mindset of knowledge sharing and collaboration by establishing incentives such as gamification concepts [21] for contributing to the creation and continuous improvement of SSKs.

Instantiation, Evaluation and Improvement

The Volkswagen AG has instantiated and deployed EFIS and its building blocks at different organizations and business areas. The Agile Center of Excellence (ACE) of the Volkswagen Group IT provides it in the form of an Agile Toolbox that is available to all Volkswagen Group employees. Additionally the ACE, Test & Quality Assurance (TQA) including Quality innovation NETwork (QiNET) experts are providing coaching and facilitation services.

Some organizational units focus on all pillars, e.g., in the finance domain as well as smaller product delivery organizations such as a cloud service. Other units have been adopting selected pillars to address specific product domain demands in combination with other lean and agile methods. This is possible thanks to EFIS' modular building block architecture. Domain-specific SSK frameworks have been built to scale special matter knowledge to decentralized expert competence fields. In the Spotify model, this corresponds to a guild orchestrated by a squad of experts. However, while Spotify takes a rather structural and organizational approach, EFIS relies on a more operational and operations structuring one. Both can be fitted together, as shown in the example in Fig. 3, visualizing the instantiation adopted for the transversal expert areas like ACE, Machine Learning and Blockchain which are organized in line and virtual organizations. In this example, the Tribe Lead is accountable for the compliance of the organization and owner of the LoD. Furthermore, the Tribe Lead is interested in the continuous improvement of the organization and accountable for the SSKs. The Squads and Chapters have built and maintain both the LoD and the SSKs. They are responsible for fit for purpose in their product or service domain and the operational instantiation. The Squad Leads are accountable for the adequate instantiation of the PQR and aTWQ approach in the teams. The teams are responsible for instantiating and maintaining the EFIS artifacts.

During the EFIS evaluation period, the authors accompanied EFIS instantiations in the IT domain of finance and automotive. The acceptance and added value of EFIS is indicated by the feedbacks of people for example to SSKs and contributions to the enhancement of the EFIS framework like the LoD enhancement with LoD layers by Audi AG and Volkswagen Financial Services AG. Additionally, explicit coaching and facilitation demands are requested to the ACE. New insights and learnings were used to enhance the SSKs and delivery kit of the EFIS framework. Furthermore, the EFIS framework was introduced via the Agile Community of the Volkswagen AG to the community as the last step of the initial evaluation. To improve the EFIS framework continuously, feedback is collected wherever possible. Currently, the LoD layer approach in the context of shared responsibility with different governance units is under development and evaluation. For the teamwork quality pillar, the refinement of aTWQ is in progress. Due to complex IT projects, the teams need technical skills to build high quality products and services. This is addressed by team maturity for specific technologies like cloud computing.

In terms of limitations of this work, the currently known EFIS instantiations are located on different sites and legal entities in Germany. Therefore, there is a lack of information about the application of the EFIS framework in other geographical areas, especially non-European ones. However, some of the investigated teams and organizations in the German sites are highly diverse and international. Furthermore, the SSK approach fostering the autonomous instantiation of the framework and its individual building blocks limits the completeness of measurements and observations related to the actual spread and adoption levels across the entire enterprise group.

Discussion and Limitations

EFIS is a methodology with a supporting set of tools. As SAFe® or Scrum call itself a framework the authors decide to use the term framework, too -to indicate that EFIS can be used stand-alone and as overlay framework on the same level as other established frameworks. An added value for product teams to the generic description of compliance integration like in SAFe® [1,22] is that with the LoD explicit all relevant regulation and compliance requirements to the specific product are made transparent. Furthermore, all product relevant quality risks are explicit handled. Both together can be used to ensure the product and process compliance of deliveries explicit in the context and responsibility of the product team. Depending on the compliance requirements the teams can do checks manually or automated (e.g. integrated into a continuous delivery chain [23]).

As a limitation of the evaluation the instantiation in the different legal entities is that in all cases the IT applies EFIS -however this indicates that EFIS is applicable to IT organizations and also can be applied outside of the Volkswagen Group. Furthermore, no large metric set about efficiency is established for systematic monitoring and enhancement -only downloads or page views of EFIS SSKs are measured. The currently feedback driven development has to be developed to a more objective indicator and metric driven set. An idea is to use the aTWQ maturity of teams as an long-term indicator of evolvement.

Conclusion and Outlook

The EFIS framework proposed in this article provides a way to build a lean and agile environment in large-scale organizations and different domains like automotive IT or finance. Its open, modular design makes it combinable with other lean and agile practices and approaches. In particular, EFIS addresses the needs of large enterprises for systematic team development to facilitate autonomy through mastery. It achieves this through product-specific quality risk management for continuous high quality value delivery, as well as process integration for establishing delivery chains under the enterprise-compliance-governance conditions. Its fundamental underlying lever is knowledge scaling within the entire organization for continuous improvement.

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

-The EFIS framework focusses on domain-specific governance in a lean and agile way, with the LoD to ensure compliance requirements and aTWQ for fostering team autonomy through mastery. -The EFIS framework has a simple, modular structure based on four pillars and minimizes the amount of methods and practices. This is considered a key success factor for the creation and adoption of specific organizational instantiations. -The EFIS framework can be combined with other established practices and frameworks like SAFe® to complement them and/or to leverage transitions.

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

-Identification of the gap of systematic governance and quality management by the established lean and agile practices in the context of large enterprises. -Identification of a way to handle the accountability required by regulations by proposing a chain of accountability, responsibility, mastery and autonomy in large enterprises.

-Demonstration that framework openness and modularity contribute to a holistic yet gradual adoption of agile and lean practices and mindset at a large scale.

Future research will address specific demands of various business domains. Furthermore, specific governance and compliance requirements have been selected for developing lean instantiation approaches and scalable patterns for the affected agile organizations within the enterprise. Additionally, systematic measures have to be established to indicate the effectiveness of the application of the EFIS framework. The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Introduction

Established industry sectors are more or less regulated. Less regulated sectors solely have to incorporate basic requirements like European Union regulation, i.e. the General Data Protection Regulation (GDPR) [1], and/or national requirements such as the German Commercial Code (HGB) [2]. In highly regulated sectors however, products and services have to comply with further extensive standards and regulations. The financial sector, for example, has to fulfill regulations imposed by the EU countries' national supervisory authorities, as well as Minimum Requirements for Risk Management for financial institutions (MaRisk) in Germany [3]. Many regulations are domain-specific like medical, finance or automotive. However, regulations have some common aspects like quality assurance evidences for verification and validation which demand a more or less stringent traceability and risk management [4].

Our research objective is to design a framework that can be used to derive a specific compliance guideline offering as much autonomy to agile teams as possible by fitting the required specific regulations of the product or service with its organization. In large organizations, specific organizational units have to be aligned with specific compliance requirements. To support this specificity, the approach shall be generic by design. This will enable scaling the approach into different organizations and their units. As for evidences for the effectiveness of the framework, we want to meet the following three core requirements. First, the external confirmation by audits with focus on compliance shall be facilitated. Second, the delivery of the demanded business value shall not be hampered and remain an essential part of the outcome flow. Third, the framework shall be adaptable to new regulations over time.

Related Work and Methodology

A huge body of documentation exists to handle regulation and compliance. However, these works mostly focus on a specific solution or aspect within the respective domain. This leads to partial [5] and inconsistent [6] agile adoptions [7] like ScrumBut. Examples for agile development in regulated domains are [8] for safety related products, [9] for the medical, and [10] for the finance domain. However, it is difficult to find a generic practical framework for regulated domains.

The framework presented here was developed following the design science research approach [11], demonstrating the framework's application in a case study in the financial domain. The framework's general applicability is assured by design thanks to its independence from any specific regulation. Furthermore, it is adoptable by design to different business domain specific demands in large organizations to scale into their units.

Scaling Conformity to Regulations via Levels of Done

The development process has to address two dimensions. The domain dimension handles the organizational and procedural compliance requirements. It has to assure that the compliance requirements be fulfilled at least at the latest required point in the product or service life cycle. Earlier assurance of regulatory requirements is possible and a part of the team's self-organization. The product specific dimension helps teams identify and realize their product specific quality-risk requirements. Within this dimension, the team handles product or service specific quality-risks in a structured and transparent manner to assure an adequate risk management. For handling the product specific quality risks, we use the Product Quality Risk (PQR) [12] approach, which focusses on quality risks implied by the specific market chances and opportunities of each service or product. PQR guides the teams from a systematic identification of specific service and product quality risks, and helps them define adequate mitigation actions.

To leverage a lean and agile development process, which teams can apply outcomespecific refinements to, only a minimum predefined framework shall be set while still assuring a systematic handling of the team's refinement work. The process outcome's value is assessed by its (inherent) quality risks. Systematic product or service quality risk identification and handling proposed in [12], can be used to assure that the development process does not lose outcome focus. In [5], the product capabilities and features are used to derive the product specific quality risks. Based on the identified and prioritized quality risks, adequate mitigation actions are scheduled during the development to ensure a compliant and high quality outcome.

To assure that product teams incorporate both dimensions just in time, we propose a Levels of Done (LoD) approach. LoD are an enriched variant of the Definition of Done (DoD) of Scrum that is aligned with requirements [13] at defined milestones in the development process. The LoD approach applies the concept of boundaries [14] beyond the sprint time-box between Definition of Ready (DoR) and DoD to all takeovers in a value chain. This makes it simple and independent from any specific agile approach based on sprints, as well as sufficiently generic to adapt to different regulation domains with the specific check-points they require. This is necessary to fulfill a systematic product and process quality approach demanded by most quality related standards, as well as to allow agile scaling while staying effective [15].

The LoD-PQR Approach

While in a traditional compliance scope, the software development life-cycle is clearly defined by a comprehensive set of fixed requirements and deliverables prior to project start, we propose the following four steps to define LoD in agile environments:

Identify all relevant regulations and standards of your enterprise for compliant products and/or services.

Identify how many stages you have for product development via a Kanban board. The Kanban board helps to identify handover-points in a work stream. These points are the most relevant for LoD.

According to Conway's law [16], the structure of an origination drives their outcomes. Therefore, alignment of the "planned" outcome architecture with the organization shall be considered. This should also drive future changes to an existing LoD to support the transformation in a pull-fashion. The LoD does not refine the internal team organization between two stages. The teams can apply their preferred agile approach like Scrum, Kanban etc. in their self-organized working flows to fit the next stage.

Enabling teams to choose the most effective ways to comply with regulatory relevant outcomes by mapping them to the stages of the Kanban board.

A transparent traceability from the regulation to the LoD will facilitate regulation adoption. However, finding adequate implementations should be delegated to the team to give them freedom to find solutions that fit into their particular context. The openness about how to reach the outcomes give the teams the autonomy to work as it is best for their specific demands and the mastery (responsibility) about their implementations. The traceability from the external requirements to their internal representationsthe topics in Fig. 1 shall be established to avoid interpretations by missing "root" and to avoid non-value adding activities in a lean context.

Reduce the outcomes of "chains" to the last outcome for a shorter list.

To optimize the LoD, chains of dependencies can be reduced to the latest outcome. For example, a separate test protocol is not needed if the test result log and protocols are saved as part of the comprehensive deployment-log and stored in an auditable way. This is covered by an underlying internal control system.

Provide additional information about practices and work instructions about outcomes for assisting the teams. To help the teams for a fast instantiation, a practice collection can be provided sharing of experiences across the organization. If a new practice is identified, it will be added to the practice collection to leverage continuous improvement and replacement of outdated practices.

Add the PQR dimension to assure that products and services have a comprehensive quality approach. To derive systematically the specific PQR a self-service kit for the teams is recommended as described in [17]. While the LoD covers only formal regulation requirements, the PQR method handles business risks related to deliverables by quality related mitigation actions as described in [12] and [17]. These mitigation actions are mapped to the corresponding stages and handled by the teams. Based on the regulation and quality risk dimension, a holistic quality management system can be established. Figure 1 shows how the actions fit together in a product team specific instantiation. It visualizes the instantiation of the 4 LoDs, the product team specific PQRs actions (a) on top of the organization-wide valid LoD topics (t), as well as the numerous product checks.

The LoD-PQR approach is easily repeatable for the iterative and incremental development in agile product teams. It also foresees cross-team reviews conducted by technical reviewers (IT experts) providing evidence of compliance with the LoD. Quality standards covered in the reviews include: architecture, code quality, PQR, security, documentation, etc. Every topic has its own LoD acceptance criteria. Depending on the technical review result, the accountable role (e.g. Head of IT) grants technical approval for the product release (Fig. 2).

One difference to a DoD is that the latter is typically defined by the team, while a LoD is given by the organization to a team, and team-specific parts are defined via the PQR with a product or service focus. A second difference is that a DoD addresses aspects which are handled by the team, while the LoD-PQR approach ensures an end- to-end view for a delivery of a product or service. Furthermore, the DoD is checked by the team as a kind of a self-commitment, while the LoD is typically checked and ensured by team external reviews initiated by the organization's compliance.

For the review and approval process as well as the LoD, internal criteria shall be derived. The control owner shall establish a monitoring on the whole process against these criteria (via preventive gates and/or detective post-checks) in order to conduct appropriate actions depending on the level of conformance and control effectiveness.

Derivations to the LoD shall be assessed and tracked to sign-off by the risk owners. Teams "pull" experts for specific standards for support in case of new or special issues. Any regulation changes shall be integrated into the LoD as soon as possible and all teams have to ensure to fulfill the current version as soon as possible. Teams can autonomously set synchronization points in case of inter-team dependencies. The time span between the different levels of the LoD in a team mostly depends on the team's delivery frequency, and is independent from a team's delivery cycle duration. Some teams need weeks, others months.

Case Study: Instantiation, Deployment and Its Limitations

The Volkswagen Financial Services AG Digital Unit Berlin (DU) identified four stages for their LoD (cf. Fig. 1). First, the business takes over the stories into the team. Second, the team implements the requirements according to compliance for security etc. Third, the product is checked for compliance and business process integration. Finally, the product's functionality is verified during operation. The last stage is interesting for the handover in cases were no DevOps is applied.

The identified regulations and standards for the financial domain are defined by the European Union and are instantiated by German governance and regulation institutions like the MaRisk, BAIT [18] or GDPR. As shown in Fig. 1, a key input to LoD was the experts' collection of LoD-relevant requirements. They derived them from the relevant regulations and collected them in a central document. Subsequently they mapped similar requirements and merged them. They integrated requirements addressing the development process (e.g. independent checks from the business of IT systems in BAIT requirement 41) into the LoD design. These requirements from the identify compliance aspects of Fig. 1 have an impact on the team's organization and their interfaces. Hence, regulations impact organization setup and team handovers (identify handovers for levels in Fig. 1), in as described in Conway's law. In the given context, this happened for the acceptance testing by the business which is realized in an independent stage in map § to levels in Fig. 1. Based on this, all teams have to instantiate this regulation implementation before they can add product specific PQR actions in the last step in Fig. 1. Another example is the regulation requirement about systematic requirement documentation of the BAIT requirement 37 "Requirements for the functionality of the application must be compiled, evaluated and documented in the same way as for non-functional requirements." This regulation requirement about requirements is handled in the LoD's first level with the task to refine requirements based on the recommendation to align stories on the INVEST criteria [19]. INVEST stands for Independent, Negotiable, Valuable, Estimable, Small and Testable. The recommendation is given to establish a kind of state of the art for requirements documentation however teams have the option to substitute the recommendation with another more adequate method for the product or service context. Furthermore the BAIT 37 requires "The organisational units shall be responsible for compiling and evaluating the requirements." which leads to assign it to the LoD's first levelresponsibility for this level is by the business product owner -and not to the second level with IT responsibility. Both examples show that in a regulated finance environment one team have to has hand-over points which leads to at least three levels of done to be compliant to the BAIT.

Preventive checks of the LoD's correct application are conducted before a productive deployment, while detective compliance check are done after deployment. To assure LoD compliance, the DU adopted the approach from Fig. 2 with some refinements for adequate review sampling and time (pre-or post-deployment). To reduce the direct effects of the LoD procedures on team level, the objective is to reduce the predeployment checks, which interrupt the delivery workflow of the team for a compliance task. However, each team has to ensure that in an audit, all relevant artifacts and evidences are available to demonstrate a compliant delivery.

The LoD of the DU has been developed by a cross-functional team. The team incorporated experts from the headquarters compliance, headquarters security, business and development teams, as well as external experts from the Volkswagen AG. Reflections with external consults (agile coaches, auditors etc.) were done cyclically too. Throughout the development period of almost one year, the team allocated approximately 6-7 experts. The initial application (evaluation) in the first teams was done with facilitation by the expert team. After small enhancements and the positive feedbacks of the early adopter teams, a LoD Community of Practice (CoP) was established. This was useful to ensure that the scaling to all teams can be made efficient and quick. The experts are limited resources and in the CoP the teams can help each other toothis helps to reduce bottlenecks by the experts who were focusing on the new issues and questions.

In the last 3 years we established and enhanced the approach for more efficient delivery and to regulation updates with the Scrum masters and the teams. Currently more than 100 developers are working with the LoD-PQR approach, and further locations and organizational units are in the adoption phase.

The application to the DU financial case revealed the following limitations of the LoD-PQR approach with respect to the corporate governance having to assure

• The correct outcomes for the compliance requirements, as well as • The expected deliverable which creates the customer/user value;

• The update of the LoD by the regulation experts;

• The update of the PQR by the product or service experts.

These limitations are partly addressed by the review procedure (Fig. 2), which however generates a base workload scaling linearly with the delivery frequency of the products and services. To reduce this linear correlation of reviews to deliveries, a team maturity approach can be established. Higher team maturity leads to more autonomy and thus reliefs the team from having mandatory pre-deployment LoD-triggered technical reviews by team-independent reviewers.

Discussion and Conclusion

The LoD-PQR approach addresses the demand for a generic approach to handling regulation requirements and product specific quality management in an agile environment. While we have shown the generic LoD-PQR method application to the European finance domain, other domain specific requirements would need to be identified, e.g. for the DO-178 (avionics safety) or ISO 26262 (automotive safety). However, the amount of regulation requirements in finance was lower than initially expected, approximately 50 with direct impact to the software development. The product specific PQRs strongly depend on the outcomes, however the workload which can be handled by a team is a "limiting factor".

The acceptance of our methodology within the agile-teams was encouraged by the committed degree of freedom. In our case, we have witnessed that implementing the LoD-PQR approach supported the teams to navigate through the complex compliance requirements in our domain in a lean way (conformity). Our approach enabled the product teams to realize efficiency by design and to share techniques how to implement compliance requirements in an uncomplicated way. Besides, the genuine learning character of the LoD-PQR approach leads to streamlined development processes of the approach itself, leading to a positive impact on process performance. , 18]. IT products developed for these legal areas and business domains have to be compliant with the state-of-the-art regulations and standards. Organizations have to ensure the product compliance with controls and checks of their products. Depending on the structure and culture established in a company, the organization can choose different approaches to comply with regulations and standards. This is possible because applicable regulations and standards mostly impose requirements with focus on what and not on how. The main driver for the selected instantiation approach is the type of accountability that is used within the organization. Many concepts like [Seal,06], experiences like [Herbert,12] and examples like [Abdel-Kader, 08] or [Karhapää,21] exist to show how to instantiate compliance in established classical hierarchical organizations of companies and large enterprises. Agile organizations structure this accountability differently, i.e., in autonomous product teams. To support this way of working, the governance has to be aligned with these organizations' types of accountability and responsibilities. In agile environments, a shared responsibility approach is common [McHugh,11]. The expectation of the product teams is that shared responsibility [Scott,05] approach will be supported by the governance, too. This leads to the expectation that a lean governance is established, and procedures for compliance are aligned with the agile mindset and procedures of product development and delivery working.

With this expectation, a set of questions around accountability and responsibility arises: Who is accountable and responsible for the specific governance instantiation in terms of 1. the selection of all relevant (regulation) requirements? 2. the implementation of (regulation) requirements in the product and its organizational setup? 3. the check of the compliant application of the (regulation) requirements by the teams?

A risk management of the shared responsibility approach is needed to make the current state of the instantiation and application of the specific governance actions transparent for an active handling of the identified risks on organizational level. In [Poth,20a], a systematic check of the decentralized instantiations is proposed and the autonomy grows with team maturity [Poth,20b].

Typical objective of an agile organization is to adapt specific product team demands by

• designing an approach which fosters agility of product teams by keeping compliant; • fostering lean governance by reference/base to the source requirements.

Various different more or less suitable solution approaches to implementing compliance governance exist:

• A central governance unit for security, privacy, Free/Open Source Software (FOSS) compliance etc. These organizations tend to establish one big governance framework to address all (edge) cases. This may lead to a one-size-fits-all approach, bureaucracy, and frustration in agile teams. • Local Governance units for domain-specific instances of governance like ISMS. This kind of organization tends to multiply efforts for compliance in all phases of the life cycle with plan, build, run the local governance instantiation. • Meta models are mapping all regulation and governance relevant aspects of a business domain into one model. One generic, however, probably complex, point of truth as base for specific derivations. All derivations are based on the indirection of the meta model and focused/reduced by context-specific filtering. The filter is the key for the outcome completeness and leanness.

We are building our approach based on the assumption that industrial organizations have an increasing demand for lean approaches that are adaptable to different organizations. Therefore, the solution approach has to address the following requirements: a) Define the scope of the product-specific compliance setup to avoid unnecessary efforts. b) Build a transparent base of implemented regulation and standard requirements to make transparent for everybody what is handled and what is not (base for sharing responsibility) and to make it easy to identify nonnecessary aspects for the specific product context. c) Have the possibility to combine different regulations and standards to make the approach generic and applicable in different product domains. d) Foster a lean and agile mindset by design to get acceptance in modern organizations.

Section 2 presents related work. Section 3 describes the methodology. Section 4 presents applications in the security and privacy domains. Section 5 evaluates the insights and results obtained during the iterative development process. Section 6 concludes with a discussion, while section 7 gives an outlook.

Related work

The accountability and responsibility are a basic concept to established a sharedresponsibility approach [Lindkvist,03]. However, the approach has to be designed for a lean governance environment to ensure leanness across its entire life cycle by design. To ensure adaption to different organizations and business domains, process tailoring approaches are relevant, too.

Accountability and responsibility

Accountability and responsibility are a widely discussed topic in different contexts like e.g. Cooperate Social Responsibility [Ribstein,05]. Various types of accountability exist [Erkkilä 07], see table 1.

Table 1: Types of accountability according to [Erkkilä 07]

Shared responsibility is established in agile approaches in the safety domain with SafeScrum® [Hanssen,18] or R-Scrum [Fitzgerald,13]. Both approaches use a shared responsibility approach to ensure that all relevant safety related artefacts are built and maintained.

Lean governance

Scaling agile software development through lean governance is described in [Ambler,09]. There, the bridge from traditional IT governance to agile value-driven work is proposed.

Ensuring regulations compliance is a big topic in governance. In [Mussmann,20], mappings of security standards like ISO 27001, ISO 27002, GDPR, COBIT [COBIT,21] and BSI C5 [BSI,21] are analyzed, as well as how they can be mapped to each other directly or via an ontology. This shows that generic IT standards like the ISO 27000 series (short ISO 27000 in this article) need alignment with technology domainspecific standards like BIS C5 for cloud computing. In [Di Giulio,17], this technology domain-specific comparison is made in more depth. This leads to the challenge that depending on the specific product, business and technology domain-specific mappings are needed.

Lean governance frameworks have been developed over years like [Pinheiro,14]. To combine them with agile [Ambler, 09] is not new, either. However, the scope on teams has been established only later. In [Horlach,18], lean governance aspects of frameworks are compared down to the teams by offering practices for different governance aspects. The safety domain agile approaches R-Scrum and SafeScrum® use team external assessors or auditors to ensure compliant instantiations over the product life-cycle. These are steps for continuous compliance. However, a systematic and critical self-reflection e.g. with retrospectives [Przybyłek,17] to keep focus and stay lean can be a useful approach, too.

Process Tailoring

Tailoring approaches to agile processes are investigated and analyzed in [Akbar,19]. Different types of process tailoring operations are identified like add, delete, modify, split, merge, shrink and wrap up. The RegTech approach comes from the finance domain [Butler,19], however, is not limited to it [Johansson,19]. It works with metamodels [Feltus,17] to describe the different regulation requirements in a generic and holistic model. Then the model is implemented into different IT workflows to automate parts of them. Combination of standards like security and privacy are created in [Lopes,19a] and [Lopes,19b] or to the ISO 9000 [Tzolov,18] to realize holistic compliance approaches. An approach or framework has to be designed openly and foster business agility [Triaa,16].

Methodology

The development of the proposed approach is based on a design science research approach according to [Hevner,07] with the three cycles for relevance, design and rigor. In a first step, the relevant concepts like shared responsibility are analyzed and then combined and integrated to the proposed approach. Then the evaluation starts and iterates as long as the approach needs refinement to get acceptance by the practitioners of the evaluation context.

Shared responsibility for regulations compliance and standard requirements

To ensure that the responsibility and accountability for the compliance is established adequately, the organization has to identify the appropriate type of accountability. To map the table 1 to enterprises and organizations, the established main type of accountability has to be identified to enable an adequate instantiation of a lean governance approach. In classical enterprises, accountability is mainly allocated per hierarchy and legal competences. Often less pronounced are personal accountability by culture, value and ethics as a second type of accountability. Other types of accountability are included as a kind of "supporting" accountability to the main type.

In agile mindsets and methods, the professional accountability with peer reviews and professional roles with expert scrutiny are dominant. Furthermore, deliberation, transparency and information access are part of the accountability, too. This can lead to holacracy [Holacracy,19] based on democratic election and chains of accountability. Having these different types of accountability in one organization makes it difficult to work in a hybrid organization because they all have to be strong enough to run the business. Hybrid organizations can exist with the classic enterprise setup driven by hierarchy. At one point, the "agile silo" is "integrated" by one accountable person who builds the connector to the "agile silo". Without this connector, it is difficult for the established classical accountability system to work with the agile organization. A hybrid organization coming from the agile type of accountability can add the classical accountability elements gradually without too much pain during the transformation.

To move from accountability to responsibility, the relevant aspect is that accountability is the ultimate instance (not shareable) after something happens or not. Responsibility is the owner of (future) tasks and can be shared between different owners. The shared responsibility approach is part of the autonomy in the agile mindset. The product teams have the autonomy to decide by having the responsibility for their decisions. In the case of compliance aspects, the paradigm leads to the teams getting support for structuring and ensuring their compliance. The governance supports the teams to decide how to instantiate the regulation and standard requirements. Furthermore, the ways of measuring their compliance to the requirements needs to be addressed.

For the proposed approach, governance experts are enabler by providing support through Self-Service Kits (SSK) [Poth,20c] for specific regulation requirements sets, including examples showing their instantiation. This gives guidance to the product teams by keeping up their autonomy. This builds a shared responsibility in which the governance is responsible to select the relevant regulation and standard requirements for specific product domains. The product teams are responsible for the adequate instantiation. In terms of accountability, the governance has to ensure that the complete set of currently applicable regulation and standard versions provide the base for the SSKs. The product teams are accountable for the instantiation, compliant application and delivery of evidence about compliance status, since organizations depending on their regulations environment need to be able to know about their overall compliance status. Using Scrum terminology, the Scrum master is responsible for the rituals and procedures. Compliance is part of the Scrum master's duties as described in the Scrum guide [ScrumGuide,20]. E.g. "The Scrum Master is accountable for the Scrum Team's effectiveness" by "Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done", "Causing the removal of impediments to the Scrum Team's progress" or "Removing barriers between stakeholders and Scrum Teams". The Scrum master is the ultimate instance in the team regarding the topic, and therefore accountable for compliant outcomes of the team as part of an effective team. However, the Scrum master can delegate tasks which are conducted by all team members. In other agile approaches like the Spotify model, the squad lead, who is responsible for delivery, can be the compliance accountable person. In all cases, the teams work in the companies' governance frameworks. They have the freedom to act in alignment within their area of autonomy in the governance setup of their organization, which is typically authorized and managed by the senior management.

Figure 1 shows the schematic concept behind the shared responsibility of compliance and accountability. Each team has an exposed person who is accountable for the team. However, everyone in the team can take over tasks as a responsible person. The shared responsibility between the governance and the product teams is realized by the instantiation of the relevant LoD (Level of Done, according to the concept presented in [Poth,20a]) layers for the specific product setting. Independent checks about compliance can be conducted by regulation experts of the company's internal governance teams or by company external experts depending on the regulation requirements. Furthermore, it is possible to establish cyclic checks conducted by other product teams to get compliance feedbacks and practical tips about instantiation alternatives from other practitioners. The overall accountability for compliance is assigned to a dedicated person like the Chief Governance Officer. The governance can conduct audits to check for adequate instantiation of LoD layers in product teams.

LoD layer concept

The authors' LoD approach [Poth,20a] provides the fundamental basis for the LoD layer concept presented here. First, the organization's handover points are identified.

Each handover leads to an additional level of the LoD. At the core of the LoD concept are the experts for governance who identify all relevant requirements to be compliant for a specific organization which operates in a dedicated business domain. The selected requirements are mapped to the levels. Where possible, the requirements are deduplicated if required (i.e., if e.g. they overlap). Then, the LoD for an organization of a specific business domain is ready for instantiation by their product teams. As the LoD only focuses on regulation and standard compliance, each product team has to identify product-specific risks to mitigate them adequately with associated actions. These actions are added to the LoD to build a product-specific LoD. By that, the LoD has been refined specifically for the business domain and is therefore ready to be used.

Lean governance

As long as the LoD is streamlined to the regulation requirements, there is not much room for tailoring by reducing aspects. However, the adaptation to the specific product team context is possible and needed for the integration into the "DNA" of the product teams' workflows and deliverables for adequate responsibility for LoD compliance.

The adaptation is based on integrating the specific activities and tasks into the product teams' delivery procedures. Furthermore, product-specific changes of the LoD have to be validated (with the LoD provider) and safeguarded with at least an additional compliance control to ensure that this modification is transparent for external compliance checks. The product team is responsible for the compliant implementation and continuous application of the LoD. However, the governance will still conduct external compliance checks or demands regular evidence about compliance status, which is preferable, because it gives the team autonomy how to achieve evidence and reduces the external compliance check scope and needs.

Shared responsibility for regulations compliance and standard requirements

For the presented large-scale industrial context, the lean governance charge in the shared responsibility approach is:

• Stay up-to-date about external regulations and standards.

• Offer up-to-date LoD layer.

• Offer a Self-Service Kit (SSK) and additional training and learning material to facilitate the LoD layer instantiation. • Pre-validate the LoD layer with typical conflict areas that offer also LoD layers; resolve conflicts or give clear recommendations for operational ways of handling these conflicts. • Offer support to the product teams for instantiation issues and questions (serving governance). • Cyclically check compliance of the LoD layer application of the instantiations in product teams, including learning what should be improved in the provided LoD layer for further increasing the compliance level.

In case of growing complexity in the decentralized domain-specific instantiation, a domain accountability for compliance can be useful. To establish decentralized accountability, local stakeholders can be made accountable at some or each of the company's sites. This helps making the accountability transparent and staying lean, because the local domain knowledge can be used to perform adequate instantiation, controls and checks. Figure 2 presents an approach to establishing decentralized accountability. The central Chief Governance Officer is accountable for the bullet points above. The Local Governance Officer is accountable for the business domainspecific instantiation and application within the product teams. This can reduce the compliance check efforts of the Chief Governance Officer significantly by giving autonomy to the local organization and thereby foster shared responsibility. Mastery about compliance is needed to ensure that the local responsibility will be instantiated adequately. To establish a lean governance, the layers should be kept as simple as possible to facilitate their acceptance and practical application in product teams.

Figure 2: Schematic view of accountability and shared responsibility about local compliance

An example for the proposed setup can be the ISO 27000 with the ISMS, which typically the organization's Chief Information Security Officer (CISO) is accountable for. However, it is possible to have Local Information Security Officers (LISO) in the specific business areas or domains. The LISO is accountable for an adequate establishment of the ISMS in the organization for their specific business domain. This includes selection and refinement of relevant aspects of ISMS.

LoD layers

The LoD approach as described in [Poth,20d] combines all relevant regulation and governance requirements in one single instance of LoD. This makes it difficult to see in the LoD, which source each part of the LoD comes from. This limits the method's flexibility of reusing parts of the LoD in another product context, which has similar but not equal conditions. To address this, the introduction of LoD layers enables an enterprise to have specific topic-related LoDs maintained by experts. LoD layers are dedicated for regulations like the GDPR or standards like the ISO 27000. Each LoD layer is self-contained and can be build and maintained by its independent experts. Different LoD layers are combined to build a complete LoD for a specific product. The layers can address domain-specific regulations and organizational compliance aspects. This makes it possible to stack layer by layer to a fitting domain-specific LoD. For example, the base layer could be the domain-specific regulation layer, the organization layer can be stacked on top, and finally the product-specific regulations layer could be added. Figure 3 visually presents the merging of two LoD layers. The two layers are for example offered by the independent regulation or standard experts and are merged by the product team. The merge process will have to handle the levels (columns of the Kanban board in Figure 3) of the LoDs that are combined. It also has to ensure that the dependencies of levels are maintained. This is the main work at the merge of different

LoDs to identify the level dependencies -respectively their tasks -between the different LoDs.

Figure 3: Schematic view of the merge of different standards and regulations into one LoD

The merge of more than two layers is done iteratively by merging the LoD layers with the highest amount of levels. For this, edge cases concerning the best and worst case of increasing the amount of layers need to be considered. In the best case, the amount of levels of the LoD with the higher number of level maintained by sorting the level of the other LoD's into the existing levels. In the worst case, all tasks of the LoD with the lower amount of levels have sequence dependencies with LoD containing the highest amount of levels. This leads to the point that each dependency requires a new level. However, this case is a theoretical edge case with a very low probability of occurrence in practice. Hence, the following relationship holds for the amount of levels in layered LoD after merge of LoDs:

#LevelmoreLevelLoD <= #LevellayerLoD <= (#TaskslessLevelLoD * 2) + 1 + (#LevelmoreLevelLoD -1)
with "#" meaning "amount of", and "<=" meaning "smaller or equal to". Edge case: the semantic content of layers are contradicting. In this case, the formal merge can be conducted, but the semantic conflict cannot be solved. While the presented LoD layer approach helps identifying this issue, its resolution is beyond the scope.

Generic instantiation examples

This section elaborates on a minimal example case for the merging of two specific layers related to regulations and standards concerning data privacy and cybersecurity. The assumed organizational context is given by the following preconditions:

• The focus of the organization is on software development.

• The software is developed on customer demand.

• The software is developed using agile and lean methods and practices.

• The software is developed with in-house resources (software engineers and development infrastructure). • The product is for the European Union market.

• The software development organization can rely on enterprise services like facility management for physical access and human resource departments caring about on/off-boarding -so these service providers are responsible for their process implementations. The example focuses on LoD layers for the standardized security management aligned with an ISO 27000 based ISMS and privacy regulations compliance with the GDPR.

4.1

IEC/ISO 27000/1/2 layer for IT product development

Given by the context assumptions, the organizational (like employee on/off-boarding, physical access or teleworking) and operational (like monitoring and logging) aspects are not in scope. The LoD layer is motivated by the ISO 27000 chapter 4.6 and mentioned in the standard as critical success factor for implementing an ISMS with "information security policy, objectives, and activities aligned with objectives" and "an approach and framework for designing, implementing, monitoring, maintaining, and improving information security consistent with the organizational culture". Given by the context assumptions, the ISO 27000 [ISO27000, 18], ISO 27001 [ISO27001, 13] and 27002 [ISO27002, 13] are relevant. Especially domain specific refinements like the ISO 27009 and the 2701x are not in scope.

Identified requirements and relevant aspects for the LoD layer

The ISO 27001 controls dedicated to IT systems development are defined in annex 14.

In addition to these explicit controls, there are generic aspects relevant to ensure the sensitiveness of the developers for security, and to ensure that the controls are up-todate, applied and realized during the daily development business. The compliance has to be ensured by the (development) organization aligned with ISO/IEC 27002:2013 section Compliance. The source links to the ISO standard requirements are marked for traceability with the related number in parenthesis from which the text is extracted or derived. Especially the technical compliance reviews (18.2.3) for the software artefacts have to be checked. It is recommend to have this performed by an experienced system engineer with tool support for analysis and report generation. Moreover, security testing (like pen-testing or vulnerability assessments) has to be performed in a repeatable way and documented. The accountable and qualified person for this task is authorized to perform/supervise the reviews. The reviews are conducted by independent persons in intervals (18.2.1) and aligned with the security policies and standards (18.2.2). The developers using cryptographic libraries need authorizations that are aligned with the product usage taking into account e.g. encryption restrictions in China or export restrictions from the European Union e.g. to North Korea (18.1.5). These controls have to be instantiated by the software development organization and teams.

The Intellectual Property (IP) rights (18.1.2) have to be ensured with appropriate procedures. Free/Open Source Software (FOSS) and proprietary licenses have to be fulfilled. An appropriate asset registry has to be maintained, in particular a Software Bill of Material (SBOM), which includes a listing of the reputable sources. The assets registry/lists have to be maintained and reviewed.

The privacy aspects (18.1.4) are refined by the relevant legislation and regulation like GDPR and have to be based on an organization's data policy for privacy and protection of personally identifiable information.

The developers have to care about (bug) tickets with focus on security incidents (16) and availability (17) (like business continuity and recovery) topics to support the operations. Especially the responsiveness to security incidents (16.1.5) has to be ensured. Furthermore, the developers have to establish a knowledge base from the analysis and resolving learnings of security incidents (16.1.6).

An appropriately protected secure development environment (14.2.6) like a dedicated dev-environment is required.

Development of software and systems is based on established rules of the organization (14.2.1) by e.g. secure coding guidelines, security in the development methodology, security requirements in the design phase, security checks within milestones (like sprints, release trains), required application security knowledge and developers' capability of avoiding, finding and fixing vulnerabilities. Security is established for repositories and the version control.

The systems have to be acceptance tested (14.2.9), security tested (14.2.8) and the test data have to be protected (14.3). Changes to software packages have to be limited to necessary and strictly controlled (14.2.4). System changes shall be controlled by formal change control procedures (14.2.2) which include review and approval by authorized users. The changes shall be documented and have an audit trail.

Secure system engineering principles (14.2.5) have to established, documented, maintained and applied.

Aspects like data classification (8) and labeling, access control (9), cryptography (10) and logging and monitoring (12.4) capabilities are requirements to the software under development too, but are refined and documented about their specific implementation with the relevant stakeholders and reviewed by all stakeholders (14.1.1). Furthermore, procedures like technical vulnerability management (12.6) have to be supported by the developers.

The developers have to establish awareness about security and be trained, educated, and updated about organizational policies and procedures, as well as their job function regularly (7.2.2).

Table 2 is an extract of the ISO 27001 with the scope-related audit controls. This is helpful to cross-check the LoD layer for completeness of the extracted requirements of the ISO 27000.

GDPR

In this section, we present a schematic example of how to instantiate a GDPR LoD layer which may differ from enterprise to enterprise, as well as within enterprises between the interpretations of the different legal departments of the independent legal entities. The software aspects related to the GDPR have to be developed with the business owner to ensure effectiveness and completeness related to the use case and regulation compliance. However, developers should have sensitiveness to some aspects closely related to the software architecture, design and implementation to fulfill their part of the shared responsibility. The scope of the developers is to ensure that privacy by design is the default architecture for software and IT systems. Furthermore, they have to ensure that the records of processing activities are documented in a compliant way. Aspects like data processing outside the EU, i.e., in third countries, or with external processing partners -the processor -(like cloud providers or partner companies) are not considered here, based on the given frame conditions of an in-house development scenario.

Identified requirements and relevant aspects for the LoD layer

Below we provide some sample GDPR clauses [GDPR,21] to show that the approach to designing a GDPR LoD layer is analogous to the one shown in the ISO 27000 series:

Art. 5 §1 Personal data shall be: a) processed lawfully, fairly and in a transparent manner in relation to the data subject ('lawfulness, fairness and transparency'); b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; … ('purpose limitation'); c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed ('data minimization'); d) accurate and, where necessary, kept up-to-date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay ('accuracy'); e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; … ('storage limitation'); f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures ('integrity and confidentiality').

Art. 5 §2 The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ('accountability').

Art. 6 §1 Processing shall be lawful only if and to the extent that at least one of the following applies: a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; b) … Art. 6 §4 Where the processing for a purpose other than that for which the personal data have been collected is not based on the data subject's consent … the controller shall, in order to ascertain whether processing for another purpose is compatible with the purpose for which the personal data are initially collected, take into account, inter alia: a) any link between the purposes for which the personal data have been collected

and the purposes of the intended further processing; b) the context in which the personal data have been collected, in particular regarding the relationship between data subjects and the controller; c) the possible consequences of the intended further processing for data subjects; d) the existence of appropriate safeguards, which may include encryption or pseudonymization.

Based on this selection, we provide some generic examples from the GDPR for inclusion in the LoD layer: Developers support the records of processing activities of Art. 30 with their implementation knowledge and data protection impact assessment of Art. 35 with their technology knowledge. Furthermore, developers act compliant to the code of conduct of Art. 40. The joint controllers' approach of Art. 26 is not suitable for the proposed shared responsibility approach because it impacts the external communication of the organization with its reference to Art. 13 and 14.

Derivation of the GDPR LoD layer

One level is demanded by the standard, because no handover points are required. Independent reviews could be modeled as handover, but in this case, not all outcomes have to be reviewed. Therefore, the explicit formal modeling of a level is not useful. The objective is to reduce the amount of handover points were possible to reduce organizational and process complexity to instantiate the handovers -keep it lean were possible. This makes it possible to have the option to realize all GDPR aspects in one LoD level. However, for a customer driven development organization, as of our initial assumptions for this case study, a two-level LoD is the only practical option. It is needed to make transparent which aspects of the GDPR are managed by the development team, and which have to be handled outside of it. This leads to the mapping of Art. 25 and Art. 15 to the stakeholder/customer handover level, because the final accountability for data protection is a business topic. All other identified GDPR aspects are assigned to the development level. Table 4 presents an LoD layer for the GDPR. Art. 5 is used to structure the LoD layer GDPR. The GDPR's Articles are assigned to the structure like Art. 6 to purpose limitation. Table 4 does not limit the responsibility of the data owner.

Typically the data owner is located in the business unit which demands the data processing by IT systems or services.

Customer level

Development level Data protection by design takes into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing and necessary safeguards into the processing (Art. 25).

Lawfulness, fairness and transparency. Personal data shall be processed lawfully, fairly and in a transparent manner in relation to the data subject (user or other person) (Art. 5) Offer interfaces for structured, commonly used and machinereadable format and have the option to transmit those data to another controller/system (Art. 20). Be able to collect fast all data of an individual person on demand (Art. 16). Implement an easily accessible information for users/persons processing about the data subject in a concise, transparent, intelligible and easily accessible form, using clear and plain language -Art. 13 and Art. 14 offer additional information about typical content (Art. 12). The data subject shall have the right to withdraw his or her consent at any time. It shall be as easy to withdraw as to give consent -established by a rigor UX. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof (Art. 7). Be able for restriction, like temporal disabling, of data processing for individual personal data (Art. 18). The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the Purpose limitation. Personal data shall be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes (Art. 5) -keep in mind to have consent for data usage in the context of testing, bugreproduction and training of Machine Learning (ML) algorithms. The request for data subject's (user/person) consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration which constitutes an infringement of this Regulation shall not be binding. Be able to demonstrate the consent of a person to legitimate the data processing (Art. 7). Where the processing for a purpose other than that for which the personal data have been collected is not based on the data subject's consent (like for ML training data or test data) the controller (developer/tester in the testing context) shall, in order to ascertain whether processing for another purpose is compatible with the purpose for which the personal data are initially collected, take into account, inter alia: period of their storage and their accessibility (Art. 25) a) any link between the purposes for which the personal data have been collected and the purposes of the intended further processing; b) the context in which the personal data have been collected, in particular regarding the relationship between data subjects and the controller; d) the possible consequences of the intended further processing for data subjects; e) the existence of appropriate safeguards, which may include encryption or pseudonymization (Art. 6). Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation shall be prohibitedsafeguard the demand it in case of an implementation request (Art. 9). Define what and how the data of an individual person are processed (Art. 15).

Data minimization.

Personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (Art. 5). Be able to delete data on an individual person on request or automatically if purpose for processing is not given anymore (Art. 17). If processing of personal data do not or do no longer require the identification of a data subject the data can be deleted (Art. 11). Accuracy. Personal data shall be accurate and, where necessary, kept upto-date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (Art. 5). Storage limitation. Personal data shall be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed (Art. 5). Enable policy or life-cycle driven delete of expired data (Art. 15) Integrity and confidentiality. Personal data shall be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures (Art. 5).

Appropriate

security which includes encryption, pseudonymization of data and the confidentiality, integrity, availability and resilience of the processing systems and services. This includes regularly testing, assessing and evaluation of the effectiveness of the technical security (Art. 32). (Info: use the LoD layer ISO 27000) Accountability. Be responsible and be able to demonstrate compliance (Art. 5). Be accountable for adequate data-protection by design and by default contributions to the overall software and its derived component implementation of data protection by design and by default (Art. 25). Be accountable for acting compliant to the privacy code of conduct of the organization (Art. 40). Be accountable for correct and updated information contributed into the records of processing (Art. 30). Be accountable for technical knowledge contributed to the data protection impact assessment (Art. 35).

Table 4: LoD layer for GDPR for in-house software development in an agile organization

Merge of the ISO 27000 layer and the GDPR layer

In this example, the merge is trivial because no conflicts or dependencies between a sequential work-order between the ISO 27000 and GDPR are identified. In the ISO 27000 18.1.4 the privacy aspects are "delegated" to the GDPR for refinement. In this case, both layers can be stacked into the same level of an LoD. This is beneficial, because it allows the developer team to map the merged level without required interfaces. This enables a dev-team to work autonomously in the context of ISO 27000 and GDPR as long as mastery for autonomy is given.

Evaluation

The presented evaluation setting is the Volkswagen Group IT. The evaluation took place in the Volkswagen AG, Audi AG and Volkswagen Financial Services AG.

Build of the approach

The focused layers for security and privacy are derived in a Community of Practice (CoP) initiated by Volkswagen's Agile Center of Excellence (ACE). The CoP was built with experts of agile methods, quality management and assurance, software engineers and governance standard specialists.

Offer to the product teams

The LoD approach itself is provided as SSK, as well as each layer. The basic layer contains the basics for IT software development aligned with the ISO 9000. The security layer addresses the IT software development related aspects of the ISO 27000. The privacy layer addresses the GDPR aspects for IT software development. The combination of the layers is "pre-verified" by the VW Group-IT Agile Center of Excellence (ACE) for fast and easy instantiation in the product teams. Some additional information concerning the layer derivation that is not presented in this article: The ISO 9000:2015 requires in clause 8.2 the determination of requirements with (potential) customers and clause 8.6 authorization (like sign-off) of the product or service by the customer where possible or another authorizer after verification and validation of the product or service. This leads to at least a two level LoD. However, in a typical customer-driven development a third level is needed to fulfill clause 8.3.1 to hand over the product or service requirements from? the customer or interested parties to the design and development process.

This "pattern" of customer requirements, development, customer acceptance maps with the presented levels of the LoD layer for the ISO 27000 and GDPR.

Usage and application

The product teams used the LoD layer SSKs to decide about the relevance of each potential layer for their product. Then they merged the relevant layers and added specific instantiations where they considered useful like for the GDPR Art. 5 §1 a) practices on how the data flows shall be documented. Once the building of the LoD starts and the teams commit to the content, the teams start to take over responsibility. The tour of mastery for more governance autonomy starts. During the evaluation, some teams -depending on factors like the current product and its life-cycle state -also maintained the established governance tasks and procedures for safeguarding the evaluation experiment on compliance.

Learnings of the product teams

The minimal amount of levels for a customer-driven development organization aligned with the ISO 9000 is a three level LoD. The handover from the customer to the development team and the handover for the authorization of the release by the customer leads to the three levels. In case of an additional operation, the fourth level is needed for the operating/serving. This has an implication for devops-teams, which have to establish a level for the release authorization by the customer between dev and ops. The development organization can establish a pre-merged LoD with the ISO 9000 layer and ISO 27000 layer for all products and for products with privacy aspects the GDPR layer as an additional layer.

Discussion and Conclusion

The general contribution of this paper is an approach to ensure a systematic shared responsibility in large agile organizations between the governance and product teams.

The approach presents examples of accountability in large organizations and the possibilities to delegate responsibility to autonomous teams via the LoD layers. The LoD layers are built and maintained by the governance and compliance experts of the entire organization and the instantiation is made by the autonomous product teams with their knowledge about the delivered services and products. This leads to a lean governance.

Contribution for practitioners

Practitioners are focused on observations and practices applicable/transferable to their context:

• The presented LoD layer approach can be used as a common base for product development in inter-legal entities to establish a governance environment without adding more complexity by merging all existing governance frameworks of the legal entities. • The presented LoD layer approach can reduce a complex set of internal rules and regulations of enterprises based on relevant external regulation and standards without additional interpretations and extensions. • Depending on the enterprise's accountability type, the change to a lean governance approach will be more or less difficult. • The shared responsibility of adequate compliance instantiation in agile organizations leads to a shift from classical centralized governance to product teams; autonomy comes with the mastery of compliance. • The central governance provides to agile product teams the domain-specific regulations and standards requirements. Furthermore, governance makes independent checks of the adequate instantiation and application within the organization. • This is a chance for classical enterprises to stop growing or start reducing centralized governance functions by developing this knowledge and awareness in the affected product teams. • The moving responsibility is a chance for classical organization to reduce hierarchy and its management functions by developing more qualified job profiles in the product teams.

Contribution for researchers

Researchers are primarily interested in new insights and potential investigation areas:

• Not all parts of an enterprise need an agile organization. A connector is needed for transforming the instantiated types of accountability between the established and the agile part of the enterprise beyond the separation into independent legal entities or install the "hero-interface-manager" who is "siloaccountable". • The accountability type changes over time have to be investigated more to build clear transition paths -especially in the direction from classical to agile organizations. • The current initiative is initiated and driven bottom-up. The initiative has identified central governance functions as potential entities which are slowing down delivery performance. There is no work on the possibilities and limitations of bottom-up transitions in governance to evaluate the chances of success of a bottom-up initiative.

• The support with technology to instantiate regulations and standards transparently has to be pushed and needs investigation to ensure a trustful usage in product teams and help to scale efficiently. • Establishing automated checks of compliances controls will be the next big step. Efficient scaling methods for compliance checks and compliance derivation risk evaluation and mitigation within large enterprises will have to be investigated.

Limitations

The evaluation is a limited study of selected cases and not a systematic application within a large organization. It demonstrates opportunities, but does not provide evidences on a large company level -the design science research rigor cycle is limited at this point. The approach works better in purely agile organizations because their types of accountability are more compatible with the decentralized handling of compliance in a lean governance approach. Furthermore, the amount of investigated LoD layers is limited. We also did not demonstrate edge cases like a lot of layers in one product team, or conflicting handling of contrary requirements in LoD layers.

Future Work

Upcoming steps will show if the evaluation of selected field studies becomes a transition. The change support from all involved governance parties will be crucial.

Additionally, over time we expect that the amount of LoD layers will grow, driven by the company's obligation of addressing the different product and business domains of their increasingly heterogeneous product portfolio.

Introduction

Several big enterprises like Cisco [1], Ericsson [2], and Volkswagen [3] are in the process of agile transformation. Accompanying tools and measures have to scale from individual project teams to bigger organizational entities [4]. The key of agile development is the team who delivers the customer value. However, systematic approaches to team development in software developing industries are rare. They need to cover criteria for the determination of team culture and performance, metrics, as well as recommendations for improvement. In this article, we present the aTWQ (agile Team Work Quality) approach to supporting teams in improving their agile mindset and practices by themselves without external assessments. Given the legislative and cultural context that is typical for large European enterprises, aTWQ shall meet the following particular requirements and constraints:

-The approach shall not use specific roles that are typically fulfilled by a particular person to avoid individual performance measures to be aligned with workers council mindset in enterprises. -The approach shall be appropriate for integration in project and program reviews to measure transition progress from a governance perspective.

-The approach shall be applicable as a self-service by the teams to ensure scaling without centralized coaching etc. and support the autonomy of the teams during evolving.

The lean and agile approaches most frequently used in industry, Scrum and SAFe®, do not address TWQ explicitly. In SAFe®, one of the four core-values is "Build-in Quality" [5]. In the deep dive documentation [6], however, the focus is product quality and "Flow" as a generic construct for all other aspects of quality. The process quality is implicitly addressed by links to other topics. TWQ is not mentioned at all, and therefore implicit. On the other hand, the consequence of this observation is: everything that is needed for quality is done inherently and not defined in SAFe®. In Scrum, the heart of the value creation is the team, which is supported by the Definition of Done (DoD) for achieving product quality, as well as the team retrospectives for process improvement. The team itself does not get any kind of explicit quality-related instructions and tasks. Instead, the daily, open communication and commitments are essential parts of TWQ. This is motivated by the aspects like mutual trust and performance monitoring which are observed in [7]. Also in [8] aspects like the ability to complete whole tasks or feedback are shown to have an impact to the team work quality. In [9] it is observed that team work quality correlates with performance in some settings which is an important fact for organization development. Also, collocation and diversity in teams [10] helps to improve team work quality.

The particular challenge related to TWQ is the fact that TWQ is part of internal quality aspects that are typically hidden and invisible from the outside. This makes it difficult in lean and agile environments to identify and explicitly "spend effort" on them. The ISO/IEC 25010:2011 makes this more transparent by distinguishing "quality in use" from "product quality". The latter is often directly addressed by regulation and compliance requirements like security or reliability. The process quality is treated as a "first class citizen", because there are powerful and influential (external) stakeholders for legal compliance. Therefore, without some explicit measures and metrics related to TWQ, a systematic development is difficult from the organizational point of view.

2 A Team-Based Approach to Agile TWQ Team work aspects have been treated to a large extent in literature, e.g. [11] and [12]. Some of this previous work addresses agile team work quality explicitly [13] or [14] some also propose organizational models fostering team work quality [15]. During the design of our approach, we focused on integration of different concepts with a longer evaluation time to not have the work to start from scratch and get benefits form the diversity of the different approaches we are integrating. The three approaches we consider most relevant are the Team Work Quality (TWQ) [14], Team Climate Inventory (TCI) [16] and Group Development Questionnaire (GDQ) [15] because they address both the team development and maturity. The TWQ approach focuses on quality indicators of team work. The TCI approach developed over years and evaluates team indicators related to the teams' working structures for innovation. The GDQ approach focuses on evaluating the teams' alignment with stages of group development. Based on [17], the following empirical observations provide the basis of our aTWQ approach: a) Team Performance is based on TWQ. b) TWQ and the TCI have similar "content". c) TCI works well with GDQ.

Based on [14] and [18], we derived the initial team-level approach covering the six aspects communication, coordination, balance of contribution, mutual support, effort, cohesion. These six quality aspects lead to team performance [19], legitimating economically the effort for measurement and further TWQ improvement. We combined these aspects with those of TCI and defined 19 related questions to come up with a holistic team evaluation questionnaire for aTWQ, see Table 1. TWQ aspects not explicitly covered by the TCI questionnaire have been added and printed in italics. Terms printed in bold letters signify the most important aspects of the respective question. Column 3 and 4 show the mapping of the questions to Scrum and SAFe®, respectively, based on the specific approach's elements covering the aspects addressed by the questions. Hence, the TCI/TWQ questions represent generic practices, while the associated elements from Scrum or SAFe represent specific practices of either approach. Both combined constitute the practice set of aTWQ in a specific team environment. The sparsely populated columns 3 and 4 indicate that neither Scrum nor SAFe® cover aTWQ aspects well. The indicators of the approaches are based on the current versions of SAFe® 5.0 and the Scrum Guide version of Nov. 2017.

For the integration into the project reviews [20] evaluating individual product teams, a group of teams (like programs), as well as entire organizational units, an extension beyond a typical team size is needed. For the context of aTWQ, a team is constituted by people who have common goals within a purpose. The team size is aligned with the agile definition of 7-9 individuals [21]. A group is a collection of people or teams coordinating outcomes and efforts.

In the aTWQ approach, the extension to groups larger than one team is realized with the Group Development Questionnaire (GDQ) because in scaling agile approaches there is no "one big team". In SAFe®, for example, there exist different types of teams like the technical and business teams sharing a common basic approach. "Both types of teams strive for fast learning by performing work in small batches, assessing the results, and adjusting accordingly" [22]. This leads us to deriving that in SAFe, a group of different types of teams is managed. To handle this appropriately, something beyond TWQ is needed to show that the group which forms a SAFe® environment works fine.

The evaluation of the readiness of organizations is based on the spiral dynamics approach, which is usable in larger social systems like the GDQ. These two models provide the basis for using the aTWQ approach from individual teams to larger organizational units including many teams that work for some shared objectives. Based on this, the Level specification has been made in column 5 of Table 1. These levels represent the following GDQ approach stages: (I) Dependency and inclusion, (II) Counter-dependency and fight, (III) Trust and structure, and (IV) Work and productivity. The numbers in parentheses indicate the rating aligned without the mindset objective primarily based on the formal application of the respective agile aspects only. For example, in the Scrum theater, people apply some Scrum methods "mechanically" without actually forming a Scrum team with an agile mindsetthis Scrum theater have to be rated with the parentheses level. The levels can be used by the teams to prioritize the improvement actionsstart with actions on lower levels to establish a base to build on for higher level actions. The four maturity levels can be easily mapped to ratings used in specific process assessment frameworks such as the ISO/IEC 33001:2015. To have some specific indicators for the rating, column 3 and 4 can be used. Furthermore, the level rating is an indicator for the maturity of teams based on the TCI/GDQ approach.

Evaluation and Improvement Iterations

In the first step, the initially designed approach was simulated with the coaches of the Agile Center of Excellence (ACE) [23] which are the Volkswagen Group IT competence center for agile transitions and quality experts from the Quality Innovation Network (QiNET) [24] which is an innovation network for IT quality within the Volkswagen AG. The simulation was realized by virtual application of the aTWO questionnaire to teams coached in the past. For each simulation a point in the past was used as timestamp for answering the aTWO questions based on the situation around the timestamp. During the simulation the answers of the teams were simulated by the coaches/experts based on their knowledge about the team. Based on the answers potential chances and risks for the team development were derived. Then the timestamp was move ahead to check if the chances or risks identified by the aTWO approach are realistic to validate the questionnaire as a starting point for team improvements. An initial Proof of Concept (PoC) was done in the Scrumban aligned product team of TaaS [25]. The self-assessments taken ca. 1.5 h. The team can answer the questions in a way it is most useful and common in the teambullet points or phrases are valid options to document evidences and indicators as well as for improvement ideas. But it is important to make the rating in the defined NPLF-schema to be able to compare team ratings of different organizations.

Some facts about the TaaS PoC: The concerned service was introduced in 2016 and has been offered in the Volkswagen Group since 2017. Over the years, evolving the team constellations have led to an established devops team with end-to-end responsibly for the service delivery. In April 2020, the team included an internal product owner, two internal software engineers and one external software engineer with a primary focus on product development and third-level ops-support, as well as one external parttime devops engineer with primary focus on first and second-level support and some third-level support activities. The team members' experience levels covers a wide range from junior developer to senior engineer. After a team composition change a few weeks earlier, the team was in a re-balancing phase. The application of the aTWQ questionnaire worked fine and was conducted as a dedicated task of a team retrospective. The identified enhancement potentials were used like retrospective outcomes and lead to actions for team improvement. Some small improvements based on the feedbacks and observations were made about aTWQ and are reflected in the version of Table 1. As an outcome, a spreadsheet was derived with supporting notes and remarks for the teams. This sheet is the core of the aTWQ self-service kit.

Team sizes and self-assessments were similar in the two other applications we investigated. The teams remained stable at least one year before the self-assessment was conducted. All these teams belong to the same organizational unit, which has approximately 25 employees. Furthermore, the organizational unit "shares" experts in the teams. Therefore, in each self-assessment of a team at least one person has two selfassessments. The organizational unit achieves a 2-digit million Euro turnover based on a service-catalog based delivery approach. The service delivery is realized with a few hundreds of external partners. The service are a full stack from management activates, consulting, coding to operations. The evaluation results from this application shows that the self-service kit is ready to use. This leads to the next step to reflect the aTWQ self-service kit in the coach guild of the Volkswagen AG and offer it to the coaches with all brands. In a final step, the integration into the agile tool box was made for a general availability to everybody in the Volkswagen AG. Furthermore, aTWQ was integrated into the agile project review [20] in June. This provides the base to compare teams and organizations in the future. To avoid that this approach is used only as a management tool the self-service kit offered to ensure that independent form external triggers the team can work in a safe private environment to improve them.

Conclusion

With aTWQ, we proposed a model for the awareness of the team-dimension of the three quality dimensions product-, process-and team-quality. We specified an explicit indicator set for the most popular agile approaches Scrum and SAFe®. First evidences for relevance and added-value for effective team development in Scrumban environments have been given by the self-assessments and the derived team actions.

The key contributions to theory can be summarized by the identification of the gap between the current quality-models to the real world in industrial settings which emphasize agile team work which is not explicitly addressed and covered by the established product and process quality models and approaches. The identification of possible approaches reduced this gap by the integration of the TCI, TWQ and DGQ approach to the aTWQ approach with a focus on the application in real world product teams. The initial analysis about the state-of-the-art provides a basis for more sophisticated research about the added value created by the aTWQ approach in the context of team-, multi-team-and organizational-level.

The context of the development and evaluation of aTWQ is a large enterprise setting with a European culture and mindset. This narrows the possibilities and degrees of freedom by design. The evaluation criteria in the questionnaire are not fine grained which lets room for interpretation of what is adequate if no explicit evidences are expected and no indicators are given by the evaluation model. Currently aTWQ has an open design to leave the decision by the teams in case of self-application and by the reviewer from the governance in case of "external" team evaluations. The interpretation by a more or less constant governance reviewer team will give sufficient comparability between the teams within an organization. Really mature agile teams will actively request for external "feedbacks" to get the ranking to other teams and learn from external inspiration for their improvement journey. This kind of limitation is a chance by design to ensure continuous improvement within the teams and organizations because they have not static target like an evidence or indicator list which have to be fulfilled and the "aTWQ story is done".

Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Abstract

The maturity of organisations is measured using process assessment models like the International Organization for Standardization (ISO)/IEC 33001. Product quality is refined with internal and external product quality characteristics based on models like the ISO/IEC 25010. With the shift from the Tailorism-driven process orientation to a more people-centric organization, the process and product quality dimensions have to be extended by the teamwork quality (TWQ) dimension. For the sake of systematic organization development, this new third quality dimension needs to be integrated into existing quality frameworks to achieve a holistic quality approach. This article introduces agile TWQ as the method of choice. It explains its design, implementation and evaluation in the large enterprise context of the Volkswagen AG. It provides insights into the effectivity of this approach in heterogeneous multi-team settings, as well as into its strengths, weaknesses, and limitations.

K E Y W O R D S

agile teamwork quality (aTWQ), agile transformation, large-scaling agile, quality assurance (QA)

| INTRODUCTION AND MOTIVATION

In order to adapt to the ever faster evolving challenges linked to the economy, ecology, as well as the social domain, numerous companies in various sectors see themselves confronted with the need for agile transformation [1][2][3]. The latter may affect the entire organization at a large-scale, at the scale of multi-teams, as well as of individual teams. The transformation can be driven either top-down or bottom-up, as well as both together at the same time [4].

With emphasis of the agile working paradigm, the focus on the transition process becomes a cultural change towards an agile mindset. Figure 1 shows the key role of the teams within an agile organization. The team creates and evolves the products and services of an organization. The governance has to establish procedures to guide and facilitate the teams' daily business. Furthermore, the governance has to assess the delivered products and services to ensure compliance to market and domain regulations and standards. The agile project review supports these tasks, which can be scaled from individual project teams to bigger organizational entities [5].

Established standards for product quality like the International Organization for Standardization (ISO) 25010 [6] for software, and the universal ISO 9000 [7] lack focus on teams. Instead, they scope on processes, which are not at the heart of agile organisations. A logical consequence of this is that traditional quality management (QM) has a focus on the product and process quality rather than on teamwork quality (TWQ). Other common approaches like Total Quality Management have some focus on human resource management and trainings for successful implementation [8]. However, they do not emphasize teams. Teamwork quality is the blind spot of an organization's success. This is where the 3-pillar quality approach comes in. It stresses the explicit demand for a new perspective on QM and evaluation.

The product quality pillar represents the traditional and therefore most established QM domain. Its focus is on the outcomes and deliverables and their internal and external characteristics. With this product quality mindset, any product version has to be assessed to confirm the expected quality

This is an open access article under the terms of the Creative Commons Attribution-NonCommercial-NoDerivs License, which permits use and distribution in any medium, provided the original work is properly cited, the use is non-commercial and no modifications or adaptations are made. characteristics. This can be a time-and effort-intensive work whenever many complex products are delivered in highly frequent releases. With Tailorism, the process view was added as the second pillar of QM. The focus of process quality is to ensure high process determinism. The assumption is that the deterministic process activities result in deterministic process outcomes. The expectation is that higher process quality leads to higher outcome quality that is also reproducible. Over the years, different process quality standards and assessment approaches have been developed. This kind of process quality work is an indirect effort that should affect the product quality. The benefit behind this mindset is that not every product will have to be assessed if the applied process is validated as adequate for a specific product development. This scales down efforts for dedicated product quality assessments by assessing only the product development process.

The additional third pillar is team quality. The team quality focuses on the systematic enablement of the product team to do all relevant things needed to deliver a specific product within adequate quality. This includes that the teams can adopt their development and delivery procedures as well as the product itself for a better market fit. To do this, the teams need productand domain-specific knowledge. This knowledge includes the technology and regulation requirements to define and design adequate products and related procedures. The benefit of the team-oriented mindset is that it reduces the amount/the complexity of process and procedure assessments by assessing only the product team. This usually requires a significant amount of time and effort in case of complex development environments with frequent adaptions of the delivery procedures. Especially for products that need to scale along the product life cycle, there is a demand for continuous adoption of new technologies, as well as the adaptation of the delivery flows.

Figure 2 shows the three pillars of quality in agile organisations, starting from the uniqueness with the product quality approach via the repeatability with the process quality approach to the facilitation of the ability to create ('createability') with the team quality approach. The createability is achieved by the product and domain mastery of the team. Mastery leads to a high autonomy in terms of product and process quality aspects. The grey bar indicates the movement from the product via the process to the team. This also indicates that quality awareness is built and driven typically from left to right. It shows an abstraction from the product to more indirect quality drivers.

The challenge is to assess the mastery of a team in a specific product domain context. Although any agile method emphasises the central role of teams and their abilities to collaborate, they lack systematic evaluation measures for rating TWQ. Certainly, such measures need to be aligned with the agile mindset in terms of team autonomy, lose governance coupling, holacracy [9], and similar. Therefore, classical topdown organization evaluation frameworks are likely to fail in a competing value framework [10]. Instead, lean methods that can neatly be integrated into the teams' regular agile activities applied in the form of a self-driven self-service approach have a higher chance to be accepted. To evaluate the team quality, there exist approaches like [11], which can be applied to every team. Established agile frameworks like SAFe® claim through the core values [12] terms like built-in quality [13] that shall address any quality relevant aspects. However, a deeper investigation of these frameworks reveals that they lack a clear and holistic quality practice set. A similar handling of the quality term can be found in Scrum. It focuses primarily on product quality aspects through the DoD [14]. To bring the generic quality term of agile frameworks and the elaborated teamwork approaches together, the agile Teamwork Quality (aTWQ) approach is proposed in [15]. Pursuing the objective to establish the third pillar of the concept in Figure 2, the research question derived from this introduction is as follows: How to establish an aTWQ approach that is applicable in different agile frameworks like Scrum or SAFe®?

To answer this research question, an internal 'market analysis' of TWQ approaches is needed. The results provide the basis for the development of the aTWQ approach. During development, the relations to established agile frameworks have to be ensured. For rollout and establishment, an evaluation is required to ensure that the designed artefacts of aTWQ actually cover the demand. With the described approach, the gap in current TWQ approaches will be identified and closed with a focus on delivering a practicable approach whose industrial applicability will also be demonstrated.

Section 2 presents related work in terms of a kind of 'market analysis'. Section 3 focuses on the development and enhancement of aTWQ. In section 4, the evaluation and improvement are shown and discussed. The last section summarises the article's contributions.

| RELATED WORK

This section discusses the reviews of existing works in the areas of TWQ in agile, as well as teamwork evaluation methods and approaches.

| TWQ in agile

Literature related to TWQ in general has been published for 2 decades [16]. For more than 1 decade, the topic has been investigated in the context of agile teamwork [17]. The team setup is an important part of organisations by allocating the right skills in agile teams for high performance [18]. Team maturity and agile methods focus on performance and present correlations [19]. In [20], it is shown that teamwork correlates with productiveness of agile software development teams. Also, TWQ and team performance are analysed in [21] with the observation that they impact the product quality positively especially in smaller teams. Reference [22] elaborates on correlations which are confirmed by team roles regarding the topic aTWQ. Another study [23] evaluates the relationship of personality and teamwork in agile working environments with the Bayesian model approach. In reference [24], gender-specific aspects on TWQ are analysed in the context of agile development teams. The work that it is specific per country and/or innovation domain presents an extension to TWQ to represent observations in creative research for sustainable innovation within teams [25].

The identified works do not define a systematic generically applicable approach for agile teams by linking and using artefacts of established agile frameworks as indicators for the facilitation of (self-) assessment.

| Teamwork evaluation methods and approaches

Teamwork aspects have been treated in literature, for example, in the context of assessment of teamwork skills in computer engineering and science education [26]. In [27], teamwork is assessed in an educational context. Teamwork and engagement in the context of feedbacks is analysed in [28]. Some of this previous work addresses aTWQ explicitly like in agile contexts [19] or innovation teams [16], some also propose organizational models fostering TWQ like [29] with the spiral dynamics model, which distinguishes team maturity characteristics. In [30], a systematic questionnaire is developed to determine TWQ. The three most promising structured teamwork approaches are the TWQ [16], which focus on quality indicators of teamwork. The Team Climate Inventory (TCI) [31], which has been developed and established over years, evaluates team indicators related to the teams' working structures for innovation. The third is the Group Development Questionnaire (GDQ) [32], which addresses both team development and maturity.

The investigated works propose differently sized generic questionnaires, which are typically used by experts to assess teams. These questionnaires need to be consolidated and rephrased to also suit non-experts. This is a missing step for deploying them widely in autonomous agile teams.

To summarise, existing works do not offer a ready to use approach to address the expectations of autonomous teams to elaborate their TWQ in a self-service way for continuous improvement. This leads to the need to bundle existing elements and building blocks to a holistic approach that is usable in industry.

| CONTEXTUALIZING aTWQ TO FOSTER aTWQ

In [33], based on [16,34], we derived the initial team-level approach including the six aspects communication, coordination, balance of contribution, mutual support, effort, and cohesion. These six quality aspects also lead to team performance [11]. This legitimates economically the effort required for the actions of measurement and further TWQ improvement.

The TCI with its focus on four key aspects and its short set of 19 questions extends the six key aspects covered by TWQ to a holistic team evaluation questionnaire for aTWQ. The objective of the questionnaire, as presented in [33], has been to create a concise single questionnaire by merging TCI and TWQ aspects. To achieve this, the TCI questions were extended by the missing TWQ aspects. Figure 3 shows the mapping of the questionnaire's main topics to Scrum and SAFe®, respectively, based on the specific approach's elements covering the aspects addressed by the topics. Hence, the TCI/ TWQ questions represent generic practices, while the associated elements from Scrum or SAFe® represent specific practices of either approach. Both combined, constitute the practice set of aTWQ in a specific team environment. The indicators of the approaches are based on the current versions of SAFe® 5.1 [35]. For Scrum-based teams, they were built on the Scrum Guide version of November 2017 [36] and the version of November 2020 [14] to support the 'upgrading' and newly established teams.

For the integration into the project reviews [37] to evaluate individual product teams, a group of teams (like programs), or entire organizational units, an extension beyond a typical team size is needed. In the context of aTWQ, people who have common goals within a purpose constitute a team. The team size is aligned with the agile definition of seven to nine individuals [38]. A group is a collection of people or teams coordinating outcomes and efforts.

In the aTWQ approach, the extension to groups larger than one team is realized with the GDQ, since agile approaches that scale do not have 'one big team'. In SAFe®, for example, different types of teams exist, like the technical and business teams sharing a common basic approach. 'Both types of teams strive for fast learning by performing work in small batches, assessing the results, and adjusting accordingly' [39]. This leads us to deriving that in SAFe®, a group of different types of teams is managed. To handle this appropriately, something beyond TWQ is needed to show that the group forming an SAFe® environment works fine. Furthermore, it cannot be assured by default that teams of the same type share a common purpose or challenging goals within an Agile Releases Train (ART). Perfectly independent feature teams share only the same timeline for their deliveries during the ART. For the mapping, aTWQ uses the following observation of [40]: 'How are team climate theory (measured by TCI) and the integrated model of group development (measured by the GDQ) connected? … the two models are closely related'.

The evaluation of the readiness of organisations is based on the spiral dynamics approach, which is usable in larger social systems like the GDQ. These two models provide the basis for using the aTWQ approach from individual teams to larger organizational units including many teams that work for some shared objectives.

Based on the ISO/IEC 33001:2015 [41], a maturity rating of each question can be made in the four categories: No (0%-15%), Partly (16%-50%), Largely (51%-85%) and Fully (86%-100%). If needed, each topic can be evaluated based on the rating of its questions. The rating is needed at least in the context of the externally driven application of aTWQ, for the purpose of for example, comparing different teams. Figure 3 presents the relations of aTWQ v1.1 with Scrum and SAFe® (solid blue lines). The dotted red lines are new relations in version 1.1. The focus on Coordination of SAFe® in aTWQ v1.1 is more transparent. In the version 1.0, the designer avoided the high amount of relations with the topic Coordination. However, practice shows that especially in aTWQ self-service application, these missing relations can result in misunderstanding parts of the questionnaire. The relation links are set to show 'contributions' of rituals, artefacts etc. of the agile frameworks to aTWQ questionnaire. However, these contributions are indicators and do not assure that, for example, by fulfilling formal rituals (e.g. with Scrum theatre), the aTWQ topic is addressed adequately. Also, the links are not set in cases of weak indication/contribution to the aTWQ topic. The detailed questionnaire related to the topics is presented in [33].

| VALIDATION AND IMPROVEMENT OF aTWQ

Within the Volkswagen AG, the evaluation, rollout and establishment of aTWQ have been introduced as follows:

-Simulation: based on the historical experience of coached agile teams, the aTWQ approach is simulated. -Proof of Concept (PoC): first real team application of aTWQ under expert observation is conducted. -Feedback, Self-Service Kit (SSK) and Coaching: Rollout preparation with feedback loops and the creation of different service offers for team individual 'service consumption'. -Integration into project reviews: integration in governance procedures of the aTWQ as a step of establishment. -Continuous improvement: based on the collected observation information and first re-checks of teams with aTWQ, the establishment of a continuous improvement wheel starts. -Demand for technology: to ensure that tech teams are able to perform their specific product/service delivery/offer tasks adequately, the presented aTWQ needs a technologyspecific extension. -Integration into other initiatives: for sustainable establishment, aTWQ is integrated into related initiatives.

We will elaborate on each of these in the following subsections.

| Simulation

In the first step, the initially designed approach was simulated with the coaches of the Agile Center of Excellence (ACE) [3] and quality experts from the Quality Innovation Network (QiNET) [42]. The simulation was realized by virtual application of the aTWQ questionnaire to teams coached in the past. For each simulation, a specific point of time in the past was used as the timestamp for answering the aTWQ questions based on the team's situation at that time. During the simulation, the answers of the teams were simulated by the coaches/experts based on their knowledge about the team.

Based on the answers, potential chances and risks for the team development were derived. Then the timestamp was moved forward to check if the chances or risks identified by the aTWQ approach were realistic to validate the questionnaire as a starting point for team improvements.

| Proof of Concept

An initial PoC was done in the Scrumban-aligned product team of Testing as a Service (TaaS) [43]. Two additional teams also helped to improve the questionnaire and the SSK iteratively. The self-assessments took approximately 1.5 h. Some facts about the TaaS PoC: The concerned service was introduced in 2016 and has been offered in the Volkswagen Group since 2017. Over the years, evolving team constellations have led to an established devops team with end-to-end responsibility for the service delivery. The team members' experience levels covered a wide range from junior developer to senior engineer. Recently, the team constellation was changed putting the team in a re-balancing phase. The application of the aTWQ questionnaire worked fine and was conducted as a dedicated task in a team retrospective. The identified enhancement potentials were used like retrospective outcomes and led to actions for team improvement. Some small improvements based on the feedbacks and observations were made which have already been integrated into Figure 3.

| Feedback, SSK and coaching

In the second step, two other applications were conducted in similar team sizes and the self-assessment was realized in a similar way to get more feedback from application and see how the self-service maturity is. A further reflection was provided by the Agile Community (AC) of the Volkswagen AG to get a more holistic feedback about the understanding of the questions from different people to see what else is needed as the explanatory and supporting material in an SSK. To support the scaling approach of the Volkswagen Group IT [5], an SSK has been designed with the questionnaire and additional information about 'how to use' the kit to establish a continuous improvement of the TWQ. Figures 1 and2 are part of the SSK. For the latter, a demand for multi-language questionnaires was identified to avoid translation mis-interpretations.

For teams with more support demand, the ACE provides coaching packages for the adoption of the aTWQ approach.

| Integration into agile project reviews

The integration into Agile Project Review [44] was the next step for the sustainable establishment of the aTWQ approach at the Volkswagen Group IT. The chosen integration approach was to conduct an aTWQ self-assessment in the teams. This makes it possible for each team to reflect and answer the aTWQ questions in their safe and private environments. Optionally, however, they may ask for facilitation by team externals, for example, an ACE coach. The self-assessment result will be used as an input to the agile project review in order to ensure that the team's individual interpretation of the questions is in a comparable range between different projects within the organization. The reviewers use the aTWQ answers to crosscheck them with the observations during the project review. As long as the answers and the observations are aligned, there will be no further discussion about the aTWQ during the agile project review. In case of deviations, the reviewers will try to get more information about the observed gaps. To make this new step and enhancement of the established project review official, the aTWQ approach needs commitment by the ACE and AC. To achieve this commitment, the setup and integration of the aTWQ in the project review will be discussed and feedback collected. The commitment to the extended agile project review was published in the AC in summer 2020. Agile project reviews initiated after this announcement will have to conduct the selfassessment before the agile project review.

Currently, the observation is that the implemented frontloaded aTWQ self-assessment in the context of the agile project review works fine. Sometimes projects are late with their self-assessment result delivery, and the reviewers have to cross-validate the observation of the agile project review and the self-assessment results after the review session. However, as long as no significant gaps are identified, the review does not need to be re-conducted. In any case, gaps present a risk of rework efforts, and therefore have to be minimised whenever this is possible. Another observation is that especially in programs involving several teams, the selection of the right aTWQ participation is difficult for the teams. Currently, the lessons learned are handled by the reviewer. In case of programme reviews, a short additional introduction into the aTWQ is given. During this introduction, the programme members are informed about how to set up the right aTWQ self-assessment. The current recommendation for starting with aTWQ is to select at least one team of each programme hierarchy level. If the programme decides to use aTWQ more intensively in their continuous improvement and/or agile transition, the rollout to other teams can be easily initiated. With this approach, the aTWQ is enforced at least as a trial in the projects and programs. However, teams can decide on their own if they want to adopt aTWQ in their strategic improvement and team evolvement work, depending on the benefit and prioritisation of aTWQ in their product roadmap.

The integration into the project review is a way to gather feedback. For example, the aTWQ questionnaire version 1.1 added to the question 'Do people in this team always search for fresh, new ways of looking at problems'? to the Scrum practices 'refinement'. Some teams reflected the question in version 1.0 only regarding their working approaches and not regarding the products. But the question is open and both aspects need to be dealt with.

An insight for the authors was that product teams handle their contractors and suppliers differently based on their established working approaches. Some product teams see them as a part of the delivery team, but others do not. Depending on the view, the scope of the conducted aTWQ assessment is completely different. Also, this leads to different application approaches. For example, the German Act on Temporary Employment Businesses demands an evaluation on the Original equipment manufacturer side and another on the supplier side, which makes some collaboration settings in some particular working approaches difficult.

| Continuous improvement scenario

In 2021, the first wave of the continuous improvement of teams with aTWQ re-assessments started. One of the findings so far is that it is useful to wait approximately 6-9 months before doing the second self-assessment. This gives the teams time to work on the actions derived from the initial aTWQ assessment. Work on these actions requires more than just implementing those. Teams need time to integrate the newly implemented actions in their team culture and mindset. This is the reason why the re-assessment should not be too close to the initial assessment. On the other hand, a re-assessment should not be conducted too late to avoid losing speed of the team's work quality improvement.

Two of the observed teams had smaller changes in their team composition (one team substituted one person, while the other team integrated one additional person), in another one, roughly half the people changed (three changes and one additional person). Depending on the team and its individuals, the changes have more or less impact on the team's selfassessed maturity. In all cases, aTWQ helped to make the current maturity state transparent to the teams. Based on the state, actions for improvement could be derived to ensure and improve the teams' capabilities and efficiencies. We could not find any indication that after a team setup change, the concerned team should conduct an aTWQ self-assessment right after the change. We currently recommend to schedule a reassessment (re-check) not before the new individuals have gone through the team integration phase.

Another interesting, however still open, aspect is, how fast and how much a team setup needs to change to impact the aTWQ assessment outcome significantly. This is a product team's individual tipping point, which depends on many factors, not only on the addressed aspects and indicators of the aTWQ approach. However, the aTWQ approach can help to make the status quo transparent. This can reveal the probability of an upcoming tipping point (as it is the case) when too many product-relevant ratings are decreasing. Figure 4 shows the process where aTWQ should be used to identify significant issues. We found that a good practice is to evaluate the first data at the end of the transition phase, and then regularly every 6-9 months.

| Demand for technology and domain regulations

To address the product domain and technology-related requirements, the generic aTWQ approach can be refined. In one project, the authors extended the self-assessment with a technology-specific questionnaire. This questionnaire focusses on identifying the status quo of the team's maturity to handle the technology adequately. The objective is to avoid product risks by achieving the team maturity required to work and develop products with the technology. In that project, the cloud technology was assessed. In another project, a questionnaire about IT security aligned with the ISO 27000 [45] requirements, the recommendations of the Center for Internet Security [46] and Open Web Application Security Project [47] for the product domain was added to ensure that security compliance was inherent in the quality goals of the team.

The observation is that it is useful to refine the aTWQ approach in case of product teams that work with complex technologies to ensure that the latter become part of the team's DNA. The same is useful to address specific domain regulations with the teams. This fosters a common understanding of which technology is used in the product team context, and how.

| Integration in other initiatives

The next step was the integration of the third quality dimension into other related initiatives and procedures. This helps to establish the aTWQ approach and the three-dimensional quality mindset in the network of QM activities and agile governance in an organization. The aTWQ SSK is provided to the quality community via the agile toolbox for the AC members and via the Quality innovation NETwork (QiNET). As the AC is organised by the ACE, the QiNET is organised by Test & Quality Assurance of the Volkswagen Group IT and open for all Volkswagen Group members. Furthermore, the integration of the aTWQ approach and the third dimension of quality into governance procedures and patterns for operational structures of organization was initiated. This helps to establish the aTWQ approach and the mindset behind by design for future re-organisations. The communication flows were triggered, and the approach is still actively promoted to reach more and more potential users for the self-service application. Additionally in 2021, the aTWQ approach has been integrated as a module into related training offers of the Volkswagen Group Academy. The Volkswagen Group Academy offers qualification services for all business-related topics to all employees.

| Summary of the evaluation

The authors have facilitated or checked more than 20 aTWQ self-assessments. By the self-service approach it is evident that they cannot track which teams actually use the aTWQ SSK, and how often they apply aTWQ. Teams from different business areas, from small projects and products to large programs were observed by using aTWQ, and their feedbacks were collected for improvement. However, the insights derived from the facilitation activities and checks during the agile project reviews, are sufficient to validate and further improve the aTWQ approach, and update the SSK accordingly. The duration of the evaluation from the first team applications with version 0.9 to version 1.1 took more than 1 year to also evaluate re-checks of teams.

The evaluation shows that the aTWQ approach can be conducted as a self-assessment in autonomous teams by using the aTWQ SSK. The results of the self-assessments can be validated in the agile project review. This validation confirms the rating of the self-assessments, as well as the correct application in the autonomous teams. The integration into the ACE transition coaching is a strategic element (reference check) to ensure sustainable TWQ development. First, it ensures that the teams apply the questionnaire appropriately. Second, it creates a baseline of the TWQ maturity profile for continuous team improvement with re-checks. The evaluation confirms that all teams can work with the approach and the SSK offer. It shows that most teams apply the aTWQ selfassessment during their retrospectives as a new fresh method complementing established approaches like starfish, which gives new insights with another perspective on the team.

| CONCLUSION AND OUTLOOK

The third dimension of quality has to be established as integral part of QM and Quality Assurance by design. For a systematically safeguarding all three quality dimensions (product, process and team), are needed. This implies holistic trainings and coaching of the product teams in all dimensions for the needed awareness during the daily business.

| Contributions and added value

The key contributions to practice can be summarised by the following aspects:

-The team quality as the new pillar of QM is set as next generation quality topic with the three dimensions' quality approach: product, process and team quality.

-aTWQ defines a model for the explicit awareness of the team dimension as the new third quality dimension. -An explicit indicator set has been defined for the most popular agile approaches Scrum and SAFe®; it can be used during agile transformation. -Evidences for relevance and added value for effective transformations in Scrumban environments have been given. -aTWQ is useable for continuous team quality improvement of a single team and organisations with more teams. -For product and process mastery, the presented aTWQ approach is necessary but not complete for all cases. In case of dealing with complex technologies and regulations, additional team maturity indicators are needed for high autonomy.

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

-Identification of the gap between the current quality models to the real world in industrial settings that emphasize agile teamwork, which is not explicitly addressed and covered by the established product and process quality models and approaches.

-Identification of possible approaches to reduce this gap by integration of the TCI, TWQ and DGQ approaches to the aTWQ approach with focus on application in real world product teams. -Identification of generic TWQ aspects with the aTWQ and the demand of technology and domain regulation-specific refinement is needed for highly autonomous teams. -Initial analysis of the state-of-the-art as basis for more sophisticated research on the added value created by the aTWQ approach with some interesting challenges such as: � Evaluate and study the effects of aTWQ on the team(s) and organization. � Extension of the view from team concepts to the spiral dynamics approach with GDQ for larger groups or organisations. � Extension to a more fine-grained approach set like for example the filling of Scrum-of-Scrum in between the existing two approaches Scrum and SAFe.

| Limitations

The three dimensions' quality approach is driven by individual complex system developments like IT systems with their highly knowledge-and skill-driven product and service development.

In this case, the collaboration of people in teams is key to success. However, there exist product development settings in which the development of individual systems is not given. In case of repetitive work or less complex variant building/derivation of an existing product or service, the additional effort in 8 -

POTH ET AL.
team quality development is a trade-off between standardized Tailorism-driven process environments and the new team quality driven approach. Currently there is no clearly defined approach on when to start working with the third quality dimension of TWQ. For introducing this approach, organisations are best advised to start with one highly complex system development team and find the tipping point by adding product teams with less complex systems to the organizational team transition portfolio. This approach is motivated by the assumption that in complex environments, the teams are the key to success -the domain of the aTWQ approach. Furthermore, there is no sharp black and white border, and in the grey area, mastery and autonomy have to be balanced adequately in new product development teams [48].

The limitations of the evaluation context are the same as in the previous aTWQ evaluation of [33], as it is a similar evaluation context. The aTWQ design limitations of [33] are still valid, too.

An additional limitation of the current instantiation of the third quality dimension with TWQ approach aTWQ is that organisations have to check if a technology or/and domain regulation extension is needed for the specific product team. Technologies need internal capabilities for effective usage [49]. When the necessary capabilities in the team are missing, technology can become a risk [50]. Without this reflection for each team, there is a risk that teams get too much autonomy if the generic indicators of aTWQ are applied without evaluating the product-or service-specific team needs. The good news is that an organization typically makes business in a specific domain with limited domain regulation. An approach to address domain-specific regulation knowledge in teams is to apply the generic LoD approach [51], which reduces the aTWQ refinement. Often, the regulation defines some scope of risk management, including technology risks. The same applies to technologies: an organization typically makes active decisions about their technology portfolio. This leads to a more or less limited technology stack, which has to be addressed with additional TWQ indicators. Knowledge and practice frameworks exist for specific technologies helping to address this refinement topic also for the TWQ aspect. An example for cloud technologies is the Amazon Web Services Well Architected Framework [52], which can be a base for the refinement for an organization.

| Outlook

Future investigations will address current limitations and build a more holistic and integrated QM framework. Another key aspect is spreading the approach to non-IT projects, as well as other brands [53] and markets with different cultures in order to evaluate the transferability of the approach. An additional point for investigation is to identify triggers for re-calibration of the teams' quality evaluations. A trigger based on objective behaviour or events for an aTWQ (re-)assessment is desirable compared to a trigger that is based on gut feeling or a fixed time span.

Abstract -Organizations are looking for ways of establishing agile and lean delivery processes. In this paper, we propose a particular way which based on self-service kits (SSK's). The SSK approach can be used to share expert knowledge in an agile and scalable way to the teams by offering them approaches, methods and tools with background information about the addressed topic. An SSK is provided as a digital bundle of artifacts that help solving an issue related to agile teams. Built upon the pullprinciple, it supports team autonomy during teams' delivery procedures. An SSK addresses generic as well as domain specific topics. As all SSK's share a common structured approach to supporting an agile organization, they help systematically scaling expert knowledge. This leverages establishing best practices elaborated by experts in a large scale organization in a native agile manner. As an SSK is structured as a "how-to" guide including templates for learning by doing, it helps emphasizing quality aspects too. We demonstrate an example of the systematic application of the SSK approach as well as its scaling in the Volkswagen Group IT.

I. INTRODUCTION

O achieve the agile transition of large enterprises, approaches beyond coaching are needed for non-linear scaling. As coaches are limited resources that cannot be easily increased on demand, new ways for scaling agile knowhow, methods and tools have to be identified and implemented. The challenge is that people involved in the transition have to learn and understand the new agile mindset with their specific -values and principles [1,2] and its characteristic approaches. An inherent job of coaches is to facilitate these learning activities and the agile mindset adoption. In this context, the term self-service kit (SSK) shall denote an approach to enabling teams to handle specific topics of their product and service related work. The way of facilitation isagile without team external persons (coaches etc.) by providing relevant knowledge and artifacts in digital form and in a pull-based manner. The objective of this work is to propose and evaluate such an approach within a large corporate environment. Based on observations of daily business during the facilitation of transitions, we derived the following requirements for This work was not supported by any public organization or funding. approaches which support scaling without direct teamexternal human integration and interaction: R1) The scope of the scaled facilitation, deliveries have to be designed as to offer a valuable outcome to the teams. R2) To ensure scaling, the deliveries have to be completely digitalized and offered anytime (24*7). R3) Guidance is needed for the teams during application and learning. R4) Teams need background knowledge about the facilitation delivery to be able to make adaptations to their specific context. R5) A feedback loop is needed to request an expert like coaches for additional support. R6) Quality has to be built in the delivery procedure to avoid scaling of errors. These requirements lead to a combination of different learning and facilitation approaches having to be considered during the development of a solution. In order to do so, we use the design science approach [3], taking into account the R1 to R6 systematically.

Section II introduces related work, section III provides an overview of the SSK approach and section IV characterizes examples of selected SSK's. Section V elaborates an experience report about the SSK application, while section VI concludes and section VII shows next steps and future work.

II. RELATED WORK

This section identifies related work based on key topics. The literature research has been conducted in alignment with Webster & Watson [4]. As the term SSK has not been used in literature so far, the search structure has been aligned with related concepts .

A. Blended Learning

Blended learning combines different web-based technologies with various pedagogical approaches. It integrates different instruction approaches and brings together working and training [5]. One of the web-based technologies of e-learning are labs [6]. Labs are used for practical training guided by instructions. However, labs are experimentation environments that normally represent only a limited set of T Scaling agile on large enterprise level with self-service kits to support autonomous teams real-world scenarios and their contexts. In the case of SSK's, the lab is replaced by the real-life context. Therefore, it is important that both the problem identification and the solution guidance is appropriate in order to avoid significant failures [7] leading to harm [8] either by misguidance, misuse or even by accident. Consequently and according to Bloom's model of learning [9], the minimum SSK objective has to be "applying" rather than "understanding" or even lower, which is typically the minimum learning target for Web-based trainings (WBT). WBT are established approaches to train people online. While WBT's transfer knowledge [10], they do not have the objective of guiding the transfer and recontextualization of the transferred knowledge to a specific task or entire project. From that perspective, SSK's have learning objectives and maturity expectations that are significantly superior to common WBT. This further augments the need of setting SSK's into an adequate design [11] context, which depends on a lot of influencing factors.

B. Problem Based Learning

Problem-Based Learning (PBL) [12] is a topic related to SSK's because the latter address particular problems while supporting the SSK applicants in solving them. Approaches to providing guidance are analyzed in [13]. The SSK, however, does not pose a particular problem but rather provides the appropriate set of questions to ask to identify a problem in practice, and leverages on this problem identification process to propose methods that help in the problem resolution process motivated by [14]. As design patterns are widely used in industry [15] there is a difference in the application of a pattern to build a product, service or process flow by standardized patterns. The understanding and learning to be able to adopt the methods and tools is offered in SSKs is the additional objective.

C. Learning by Doing

Learning-by-doing is a useful approach in practice and industry [16]. SSK's foster the learning-by-doing method based on goal-based scenarios [17] by adopting a guided approach through the combination with other learning concepts, in particular blended learning. There exist many different blended learning approaches [11]. In this context, the focus is mostly on self-paced and asynchronous formats [18] extended by synchronous online formats for the online meetings of groups to work together on a topic.

D. Scaling Agile

Scaling Agile focuses on establishing a set of agile methods for a building complex systems within an organization [19]. Existing many different approaches for scaling agile with their specific benefits and issues [20]. However most of the established scaling methods and framework do no scope the how to establish the knowledge about the agile mindset and methods in the teams they focus on the demands for methods like [21] and their implementation order like in ASM [22]. Knowledge sharing and improvement is still a topic in scaling agile [23]. Coaching is the preferred knowledge transfer approach like in SAFe [24] with the certificated trainers and role specific trainings [25].

E. Agile Teams Demands

For example, the SAFe Lean-Agile Principle #8 recommends autonomy for employee engagement [26]. Other agile approaches emphasize T-shape [27] skills to form interdisciplinary, independent and autonomous teams. Team autonomy in large-scale corporate organizations is efficient if goals are well defined and transparent on a team-level [28]. For SSK's to be most effective, this implies that they have to support setting and achievement of goals in a effective way [29]. Furthermore, autonomy and self-organizing teams come together and need cross-functionality, which is based on sharing of knowledge [30] that is available both with and outside the teams.

F. Quality and Life-Cycle Management

To assure the quality of learning materials, embedding the latter in a life-cycle is useful [31]. Quality assurance is an established habit for learning materials for distance learning artifacts [32] like for the curriculum and instructions. To achieve organization-wide standardization, a systematic governance has to be established [33]. International standards have been elaborated [34] like for open and distance universities with UNIQUe.

III. SELF-SERVICE KIT APPROACH

To scale agile in an organization without explicit time intensive coaching of all teams SSKs are an alternative knowhow transfer approach to the teams. In our context, an SSK is a combination of a web-based training (WBT) [35] and a digital tutorial [36] provided by domain-experts to a large number of -in general -geographically distributed users [37]. A WBT facilitates the delivery of specific knowledge to people needing it or asking for it. This pull of SSKs knowhow by the teams supports autonomy. Furthermore the setting supports the agile mindset with the support of develop adoption know-how to enable the teams to enhance SSKs for their specific demands.

An SSK is designed to support teams to do their work with a high quality. To realize this, each SSK has to ensure that the relevant knowledge needed to perform the work is delivered to the team. The SSK approach supports autonomous teams in applying SSK's by its design. This lead to the point that SSK's can be used for autonomous knowledge scaling and as a key element of a flywheel approach for agile transitions. Depending on the individual scope of a specific SSK, the knowledge has to be identified, documented and integrated into supporting artifacts like checklists and other tools. As SSK's shall be used many times and in several different teams and places, assuring a high quality level of SSK's is important to avoid mistakes on a large scale. To this aim, SSK's need a rigorous design, production and delivery procedure, which experts of the specific SSK topic perform. As experts are not always good trainers and educators, they can themselves get support from SSK's for their SSK development. Figure 1 shows the relation between one (1) governance to a few (n) experts that develop a particular SSK, as well as many (m) applications of that very SSK. The basic structure with governance, team and product/service has been introduced in the context of the enterprise transition approach [38] and is enhanced to the SSK approach for autonomous scaling in this context.

The governance establishes the SSK approach with its development and delivery procedures. This includes templates and platforms for digital delivery of SSK's. Experts of different teams form a development team to develop an SSK for a specific topic. As the experts are "grounded" in normal teams of the organization they know about the latter's demands and issues and therefore can address them by design during the SSK development. For different SSK's, different experts work together in expert teams. They also have to ensure the cycle updates of the SSK (R5). These updates address feedbacks (R5) for improvement and the alignment with the development of the state-of-the-art (R6). The governance regularly checks that these updates are actually made for all SSK's which are in delivery. In case that an SSK has no experts for adequate maintenance, the SSK is marked as "retired" by the governance to show all users that they should not use this SSK anymore. Based on this generic approach with the life-cycle states for SSK development, deliver, update and retired, a framework is established to provide SSK's to the organization (R2).

This setting makes it easy for an organization to start with one lean governance for the SSK framework and scale to as many SSK offers as there are experts who produce and maintain SSK's. The instantiation of each SSK is independent of these in general highly limited human resources as long the SSK is delivered in a digital way to its consumers (users).

From a quality perspective and with respect to the objectives they want to help achieve, three types of SSK's shall be distinguished (R1):

• Product quality: the SSK's objective is to improve the product or service with its outcomes.

• Process quality: the SSK's objective is to improve the process of a service or product delivery.

• Team quality: the SSK's objective is to improve the team who produces and delivers a product or service. All types of SSK's have as common objective to facilitate scaling knowledge within the organization in an agile manner. However, each type has some specific aspects to focus on. The following section presents examples for each type.

IV. SELF-SERVICE KIT

All SSK's shall include the following artifacts (R3):

• Introduction: a template for all SSK's to ensure their common structure including: scope, context, outcomes, application and references to further artifacts of the SSK.

• Working artifacts: one or more working artifacts are in an SSK. They are highly specific to the scope of that SSK. They are designed with the purpose to guide the teams during the outcome production.

• Background information: provides to the users information about the design requirements and constraints of the SSK and the development approach and evaluation context of the SSK. Furthermore it offers detailed descriptions of the working artifacts design. All artifacts have information about the producer (author) and a version. Based on these three artifact types, all SSKs are build. However depending on their scopes, the specific instantiation is different (Table I). All SSK's have to be designed to offer the teams the opportunity to adopt the SSK to their specific demand by addressing Bloom's taxonomy domains with high learning objectives (R4). This is also important because the teams are working and learning by doing in a real life lab and should be able to see risks by mis- I shows the product, process and team quality with the learning aspects within a SSK.

A. Product Quality

The development of product quality related SSK's is driven by outcomes for a specific product or service. These products are driven by technology that has to be handled adequately by the teams. To support the usage and adoption on a large scale of specific technologies that are new to the organization, such as machine learning [39] or serverless [40], SSK's can be useful. As presented in Table I, the SSK guides with questions about the technology adoption and offers checklists about the technology usage. As a product is a "real outcome", the valuable product related outcomes of the SSK are mostly persistent and measurable evidences. Mapped to Bloom's taxonomy, a product quality related SSK has to enable users in the cognitive domain for evaluation of product characteristics. This high learning level is not needed in every usage, however it is the objective of the SSK to support up to this level. In the affective domain, the high level of organizing of the product usage and its features or capabilities is a supporting objective. Furthermore, the psychomotor domain with origination is a valid objective to enable the agile teams to develop new ways of usability and interactions with the software. Not all product related SSK's need these high learning curve in all domains, but every SSK design has to check how much learning is needed (R4) to reach the expected outcomes (R3). With a problem-based learning view, a product related SSK makes it easy to learn as they related to tangible objects which typically can be measured and improved by observation of change impacts.

B. Process Quality

The development of process quality related SSK's is driven by outcomes that build workflows or activities in procedures. For example, our Level of Done approach derives organization specific procedures to be aligned with regulation [41]. In the context of our hybrid SSK for the systematic elicitation of product quality risks [42], a design thinking process is used to ideate specific product characteristics while being part of our Level of Done approach. As presented in Table I, the SSK guides with questions about workflows and activity adaption and offers methods to development and adoption. As a process is a "logical outcome", the valuable outcomes are descriptions and interfaces of workflows and activities. Depending on the implementation, the evidences are temporary (i.e., an interaction between individuals) or persistent (e.g. workflow logging). Mapped to Bloom's taxonomy, a process quality related SSK has to enable users up to the cognitive domain for evaluation of workflow sequences or activities. In the affective domain, the high level of organizing of the process workflow usage and its activities is a supporting objective. Furthermore, the psychomotor domain with origination is a valid objective to enable agile teams to develop new ways of usability and interactions with their workflows and procedures. Not all product related SSKs need such a high learning curve in all domains, however every SSK design has to check how much learning is needed (R4) to achieve the expected outcomes (R3). With a problem-based learning view, achievements of a process related SSK are mostly observable and measurable thanks to their interfaces and activity outcomes.

C. Team Quality

We address team quality aspects with agile Team Work Quality (aTWQ) [43]. As presented in Table I, the SSK guides with questions about the indicators of behavior and interactions between individuals. Both behavior and interactions underlying subjective observations and impressions, the evidences are rather indicators. Furthermore, behavior is often specific for a situation or setting which makes it non-deterministic. Mapped to Bloom's taxonomy, a team quality related SSK has to enable users up to the cognitive domain for evaluation of adequate improvement action for the team. In the affective domain, the high level of organizing of the team's behavior and knowledge to identify improvements is a supporting objective. Furthermore, the psychomotor domain with adaptation is a valid objective to enable the agile teams to leverage the potential for better fitting interactions and working methods to the specific team. Not all product related SSK's need such a high learning curve in all domains, however every SSK design has to check how much learning is needed (R4) to achieve the expected outcomes (R3). With a problem-based learning view, a team related SSK does not make this easy because only the outcomes of behavior or interactions can be observed. This is an indirection rather than a direct measure. However, the outcomes are what is used in the real life too. In this case, the intention of the behavior or interaction is not the fact that matters; only the outcome is the valuable factum. For learning, this indirection can be difficult in case of missing openness between the interacting people (in case of lack of trust etc.).

These three SSK types have proven useful to support the entire agile transition approach of Figure 1. The product quality SSK's support the product/service development. The team quality SSK's facilitate the teams by their maturity. The process quality SSK's are useful to establish processes and integrate those in the organizational governance. This leads to opportunities for the entire organization to scale all relevant parts at the same time thanks to the holistic SSK approach. SSK deployment in different organizations implies the challenge of identifying all relevant topics at the right time to have the SSK's developed just in time as they are demanded and needed by the organization and their teams. This has to be realized by the experts and innovators which are both producers and consumers ("prosumers") in cooperation with the governance as enabler and supporter of the SSK approach.

V. EXPERIENCE REPORT

A. Evaluation

The Volkswagen Group IT has instantiated the SSK approach and has been actively using it for more than three years. The governance is established within the ACE [44] and supported by the Quality innovation NETwork (QiNET) [45]. An established internal wiki-like tooling is used as delivery platform for the digital SSK's. To ensure maintenance, SSK teams perform regular updates, a process that is verified by the governance through quality checks. The governance also checks for blind spots in the SSK portfolio and initiate the setup of SSK teams via Community of Practices (CoP) to close the blind spots. An additional point of the governance is to facilitate the integration of the SSKs into established procedures like the integration into trainings of the Group Academy.

The SSK teams are founded in a prosumer fashion. Each team member wanting to share some know-how in the organization can be part of an SSK team which produces the SSK content. Experts for a particular topic typically volunteer to create SSK initiatives and teams. Experts are organized in hierarchy lines like competence centers (example ACE), communities or networks (example QiNET). Both are sources for experts who are willing and able to develop an SSK. The SSK team typically is also the team that handles the updates over the life-cycle of the SSK. The SSK team is supported by the SSK for SSK development. This ensures that SSKs looking "similar" and reduces the work of the SSK team by using the templates and how-to's which are included in the SSK for SSK development. In the case that all relevant information and content for the SSK under development exists (typically a SSK is based on artifacts, which are used by teams for their work and now are "packaged" by the SSK for multiplication into the organization) an new SSK can be built by the SSK team in a few hours. Than the initial application of the new SSK should be done under observation of an SSK team member to see that everything works as intended. Focus of the observation is that the usage is as intended and the time to understand and learn about the application is short. For a fast learning the SSK how-to template is the key to focus on the application and is supported by the offered templates. Most SSKs are ready for a first application by a "new product team" in less than one hour. If everything look good the SSK is ready for publishing. More details about the content of a SSK is shown in [42] and the associated conference presentation which is based on the SSK artifacts an impression gives Figure 2. More about the detailed structure of SSKs is described in [46] which leads to the SSK for SSK development.

All employees of the Volkswagen AG can consume any time any SSK offered by the platform by simple download and use, or by adaptation to the specific context of the product or service offered by the team. Moreover, each consumer can improve any SSK with feedbacks anytime.

Three years ago, the Group IT started with the development of the first SSK. Over time, the iterations of improvement and enhancement of established SSK's -SSK versions up 6 are released -accompanied by the development of new SSK's has led to a holistic SSK approach implementation -the SSK for SSK development. This "meta" SSK is offered to scale the SSK approach itself by its own approach (recursively). This shows that the SSK approach is continuously improved and enhanced. Currently, there is a two-digit amount of SSKs in the portfolio. The trend to more digitalization and blended learning will further propel the SSK approach and produce a bigger portfolio. An important point at the beginning was that the SSK development could be initiated bottom up without big resource allocation and funding. The SSK approach is an agile approach by design: an autonomous team of experts can be the initial spark to enflame an organization by its first SSK.

B. Limitations

The application was conducted in an enterprise with mostly European culture. Other cultures may behave differently. The feedback mechanism for improvement is weakly implemented through voluntary feedbacks. However, the "sound of silence" [47] in this case indicates that there are no significant issues with the implemented approach. Furthermore, the views/downloads figures are weak metrics for the learning impact and application intensity, since not every download leads to a valuable outcome. Moreover, the approach has been developed continuously and improved with the design science approach. However it is difficult to demonstrate explicit effectiveness of SSKs in the agile scaling of the organization because there are many other parameters impacting the scaling. This highly applied and productive context provided a constrained space to change design parameters and observe their impacts. On the other hand, this setting has been facilitating the SSK approach's development and adoption synchronized with the organization's digitalization and agile transition.

VI. CONCLUSION

The presented SSK approach combines different learning and training approaches to a specialized learning approach for agile organizations by focusing on agile values and mindset by design. The SSK approach offers an agile way to scale agile transitions in an organization. It offers a systematic learning by doing and gives the background information for adoption to specific demands of the application domain of its users. This leads to knowledge and experience creation in the teams. Furthermore, the approach values mature agile teams as prosumers who are able to improve not only their teams with established methods like the retrospective. In addition, they can improve the organization with their experience, knowledge sharing and elaboration artifacts for SSK's. This is an essential element for an agile organization that needs to step from self-organization of teams to self-organization of organizations in the long-term. The SSK approach which supports all the three quality dimensions from product, process to the team provides a key lever to achieving this goal.

VII. NEXT STEPS AND FUTURE WORK

Future work will address current blind spots and limitations of the current SSK approach to evolve them further. In a next step, the limitation of the voluntary feedbacks for improvement will be investigated [48]. Also, we want to determine how useful metrics like downloads or views of SSK are to derive the impact of a specific SSK in the organization. Furthermore, metrics for the establishment of the selforganizing organization has to be developed to make the current state of the agile transition transparent and to measure the impact of specific contributions to the transition goal.

Abstract-Organizations are looking for ways of establishing agile and lean process for delivery. Many approaches exist in the form of frameworks, methods and tools to setup an individual composition for a best fit. The challenge is that large organizations are heterogeneous and diverse, and hence there is no "one size fits all" approach. To facilitate a systematic implementation of agile and lean, this article proposes a transition kit based on abstraction. This kit scouts and bundles state of the art methods and tools from the agile and lean community to align them with governance and compliance aspects of the specific enterprise. Coaching of the application of the transition kit ensures an adequate instantiation. The instantiation handles business domain specific aspects and standards. A coaching governance ensures continuous improvement. An example of the systematic application of the transition approach as well as its scaling is demonstrated through its application in the Volkswagen Group IT.

I. INTRODUCTION

HE DIVERSITY of an enterprise's business areas demands individualized implementations of lean and agile. Often the main goal of the agile transition is to gain delivery speed. According to Albert Einstein: "Make everything as simple as possible, but not simpler", we have to find a way to achieve effectively the simple yet complete organizational setting. Furthermore, Conway's law [44] leads us to develop something customizable to build a lean and agile organization for a best fit to the specific products and services, which the organizational unit creates and delivers. These two aspects have to be handled to realize a lasting and sustainable transformation.

T Large established enterprises are built around different business areas with independent business units or divisions in a matrix structure [1]. Most of these business units have the size of a medium-sized enterprise. Furthermore, large enterprises are mostly based on large delivery pipelines oriented on the efficiency paradigm of the Taylorism [45]. Any transition aid for application within such context has to be able to handle this setting. More specifically during our first operational coaching of projects within the Volkswagen Group IT in past transformation initiatives we identified the following aspects an agile transition aid has to address: 1) Identify the target organization for the transition, including its boundaries.

2) Identify the organization's value stream, including interfaces at the boundary to "external" partners.

3) Define and clarify the transition's objectives. 4) Evaluate different approaches to lean and agile for their suitability in the particular organizational context. 5) Implement the selected approaches:

-Train people in the approach.

-Re-organize the workflows according to the approach.

-Align the new setting with the enterprise's governance and compliance structures. 6) Install cyclic checks for transparency and improvement:

-on a local view of the transition for "self-optimization"; -on a global enterprise view to develop the "setting";

-offer an open networking platform to reflect transitions.

7) Support scaling of transitions

This leads to the investigation question: How is it possible to address these demands with an easy to handle approach, which can be applied by a team of coaches in a structured fashion? Our objectives for achieving this are the following:

(O1) A transition kit is needed that is able to handle lean and agile approaches. (O2) Based on the organization's stakeholders' current mindsets a specific set of methods and tools for the workflows has to be implemented. (O3) The organization's specific product setting has to be taken into account appropriately.

II. REALTED WORKS

This section investigates related published work with a focus on a holistic approach to addressing those. There is a huge amount of relevant approaches to organizational development [2], alternative setups like holacracy [3] or transitions [34] starting on grounded theories [32] to practice collections of other enterprises [33]. We are interested in identifying well-known approaches, methods and tools that can be used as a kind of reference in various settings to reduce complexity. Our contribution is to bring together the

Scaling agile on large enterprise level -systematic bundling and application of state of the art approaches for lasting agile transitions

team setting with its cultural and mental history thanks to an adequate set of approaches, methods and tools to realize a effective and sustainable transition. We structured related work according to this scope, rather than elaborating on all kinds of available methods and tools at the time of writing this article.

A. Setting Analysis

The Cynefin [5] and the Stacey-matrix [7] are approaches to classify the product context into a complexity setting and the drivers of the transformation [36]. This are useful approaches to identify the development context of the transitions product environment. The spiral dynamics model [4] and the Group Development Questionnaire (GDQ) [8] classifies the maturity of a group of humans who focusing together on an objective or purpose. As setup point on the teams maturity for transition approaches and methods this is crucial. Value-stream mapping [6] is an approach to optimize processes in a given setting especially for software [35] which come for the production [46] to the software development [47].

B. Lean and Agile Approaches

Scrum [13] and XP [15] are team approaches focusing on agile working. Kanban [14] works in a team and in bigger organizations. SAFe [9], LeSS [10], Nexus [11] and Scrum@Scale [12] are approaches to handle the synchronization of more teams in a bigger organization. Furthermore a lot of variants are existing like Disciplined agile delivery (DAD [48] or Agile modeling (AM) [49].

C. Methods and Tools

Design Thinking (DT) [16] is a method to develop an initial product in an iterative hypothesis based manner. Minimum Viable Product (MVP) [17] and derivations like Simple Lovable and Complete (SLC) [18] are tools to define an initial product version for delivery. Business Model Canvas (BMC) [19] or Lean Canvas [50] and its variants like for organizations internal communication [20] are used to identify the setting of a business to optimize in a later step the value-stream for product and its revenues. The Product Vison Board (PVB) [21] is used to for focusing a team on a product. INVEST [22] is used to systematically identify requirements for a product. Definition of Done (DoD) [23] or derivations like Levels of Done (LoD) are used to ensure that product versions fit quality definitions. To keep the delivery procedure lean and focused Product Quality Risk (PQR) [24] mitigation can guide to the delivery.

D. Organizational culture and team psychology

The culture moves to a more internal lean start up [26] setting also in bigger enterprises. The objective of most digital business models [19] is scaling into the mass-markets [25]. Coaching approaches are reflected to be effective in the setting [27] to address the agile teams.

E. Governance, Risk and Compliance

Governance has to establish standards like ISO 9000 for quality management, standards for risk management like the ISO 31000 and additional domain specific standards. Approaches for agile risk handling exists [31]. For service management, the ISO 20000 is an established anchor. Some concepts for agile governance [28] and [29] exist, however their scope is limited to applying agile or lean principles outside a globally acting [30] enterprise context.

III. TRANSITION PROCESS

Within Volkswagen Group IT, we do not use one given method, model or tool because the organizations' s size demands context adequate approaches. More than 2000 internal employees and a lot of divisions and organizational units indicates the complexity which the transformation has to deal with. Therefore we decided to start with the basis: the team.

A transition kit and process has been developed and maintained by a central team, the Agile Center of Excellence (ACE), which guides and coaches agile transitions. ACE is a department within the Group IT uniting initial agile users from the first agile projects. The transition process consists of three phases: the transition itself, as well as a pre-and post-transition phase to ensure sustainable transitions. ACE supports transitions in the Group IT and other business areas of the Volkswagen AG based on their transition process and kit that has been enhanced over years.

The coaches establish the initial setup and alignment during the coaching phase of the team's external process expectations (figure 1). This is the initial link to process safety and compliance for the teams. The long-term alignment is checked by the project review. In the pre-transition phase, the "readiness check" is conducted to identify the status quo and objectives of the transition. The status quo identifies roles like sponsor of the transition, product/business owner and the team setting. Furthermore, agile artifacts like for the backlog and its items are investigated. Based on the evaluation of the acquired information, a transition can be recommend or not. In case of recommendation, the ACE can support the transition with the transition kit. In case of a non-recommendation to start a transition, the ACE will not support because there is low chance to finish the transition in time successfully. The biggest challenge during this phase is the interlocutor's honesty. All transition aspects are based on it and conveying information honestly and completely is needed to give the transition a chance to be successful. Therefore we decided that we start the transition with motivated and voluntary units supporting the transition and meeting the prerequisites from the outset.

The main purpose of the transition kit is to enable teams to deliver most product benefit within in a continuously changing environment. The ACE coaches help start agile projects and teach the team how to deal with impediments. Additional ACE tasks are:

-first aid in network, -promoting agile methods, -connecting committees, -supporting knowledge transfer, -combining agility practices of brands, -enable leadership to act in an agile way, -sensitize the unit to get an agile mindset, -pay attention to process safety. Every transition phase starts with a contract clarification to get a clear understanding of what will happen. Referring to the Agile Manifesto [39], the contract does not describe the HOW, but rather the WHAT. Depending on the results of the "readiness check" and the needs of a team, product or project, the transition duration will be estimated and a coaching package will be offered (cf. Section V). The contract defines the purpose, deliverables from both sides and the organizational issues like contractor and cost issues. The transition itself has four steps:

1. Preparation (evaluation of team and product setting) 2. Implement the methods and the tooling 3. Stabilization

Consulting

The preparation includes the execution of a kickoff workshop, consulting (project leads, development team) and agile workflow creation. Also includes support, moderation, preparation of the management and creation of Definition of Ready/Definition of Done and initial product backlog with the team. The initiation of the first meetings like refinement, planning, review and retrospective is a task, too. To implement the methods and the tooling the guide is always available for the team. The coaches train the team and the roles inside e.g. Scrum Master, Product Owner etc. to do the job to be done. The guide also moderates the necessary meetings like review, daily, retrospective, planning or refinement. Furthermore the guide assists the change management for motivation, conflict solving and workflow changes. The coaches are instantiating the initial setup and alignment of team external process expectations. This is the initial link to process safety and compliance for the teams. The long-term alignment is checked by the project review of the post-transition phase.

The stabilization step during the coaching (figure 1) is not so intensive for the coaches because the team should do their first steps alone. The coaches are always available for support and assistance, and in special cases will also assume the role of moderators. In this step, their job is to motivate, inspect, adapt and strengthen the change to be sustained. Solving conflicts is also part of it.

The consulting step is demand driven and mostly the end of the transition phase (figure 1). If the customer needs help, the coaches will help and give answers for questions to events, roles and workflow. The guides help the change management manage conflicts and adapt innovations.

The post-transition phase starts with a hold back (capability check in figure 1) of the transition team during the stabilization step and ends with a report. The report reflects the coaching contract objectives and also the agile issues and elements. Furthermore, the team or organization is registered as "agile". This flag will be used for the future agile governance checks (cf. Section VI) to ensure sustainability of the transition and incremental development of the people to stay up to date about the state of the art about agile.

IV. TRANSITION KIT

For the demand of the Volkswagen Group IT to transform classic project management to business agility we developed the transition kit. It contains the methods and tools which are released during the transition process. Within the transition process, we try to find the best choice of approaches, methods and tools to create value faster. The transition kit addresses the implement step of figure 1. The transition kit focusses on the key parts of figure 2. These key parts are the product or service which is the delivery to the customer, the team realizing and supporting the products, as well as the governance ensuring organizational standards. Governance can also be triggered by external demands for example from legislative changes. The transition kit has to support the setup of the demanded skills and capabilities of the team from the outcome view (product/service). Furthermore the governance has to handle the product or service risks by guiding the teams to be able to balance the business value and risks related to the product or services they handle. to discuss issue frankly. Kanban itself is a more "mechanical" approach. Both approaches can be used to develop the teams to higher levels. With higher levels the teams are acting different within the same approach by discovering more opportunities with the higher team trust and openness. Why do we have small "item" like MVP and "big items" like Safe in the table? Depending on the context it is useful to start with small items to support individual transitions of teams. In case of a more top-down demand a big item reduces discussions about how to start because it is like a pre-defined "package" ready for rollout. This is also the reason why the transition kit does not add every approach, method or tool -it selects some (first fit algorithm based) which work in the industrial context and tries to reduce redundancy were it is useful and possible by offering enough variance for the individual coaching of teams. The objective for the transition kit is to offer a practicable way for the transition of a team, without proposing any way possible.

The transition kit does not focus on finance procedures of the enterprise however some programs are using for example MVP based finance planning to manage their annual budgets in an agile fashion. However the approaches, methods and tools can be applied to special functions. For example, the Group IT security organization was an early adapter.

The transition kit is designed to develop culture, team maturity and products/services together. Of course it is possible to enforce some methods or tools on lower leveled teams, but the real opportunities are only realized within the right culture and team context. The application column in table 2 shows a current distribution of the application the line in teams.

V. COACHING ACE offers different volumes of coaching packages [37]. The package size is defined by the amount of time a team gets support from the transition team. The intensity depends on the time the guides (coaches) support the team. The coach sets up the team to address the demands and objectives of the transition by using the transition kit as guidance framework for the transition. The main focus of coaching is on the events, mindset, team performance, roles and their tasks, the used methods and how to inspect and adapt. Therefore the guide will use workshops with the whole team, as well as direct coaching.

Every coaching starts with a collection of information. This is necessary to find out what the transition (e.g. the project or team) really needs. To implement agility, the coach starts creating awareness of agile principles and values. With growing understanding, the flow will be created to support agile behavior. This means that the team can welcome and handle requirement changes having influence on the actors. The coach helps to give the team the power and knowledge they need. This is an ongoing process during all transition phases and may not be finished when the coach leaves the team.

When the transition goal is clear, the coach has to decide on which level to be most effective. If the transition has most effect on teams, the coach will focus on team members. The objective of the coach is to start small and establish the simplest possible set of artifacts from the transition kit to realize the objectives of the transition. For instance, if the coach decides implementing Scrum, he will support the Scrum team including the Scrum Master, the Product Owner and the development team. If the transition requires an organizational change, the coach will spend more time on management level where the responsibility for the portfolio is located. The tools and methods are all based on values and principles. The coach's main task is to make clear what the effects of their actual application are. Furthermore, the coach facilitates the teams with methods and tools for generic product and service development. An example is requirements elicitation and engineering with the product vision board to align the requirements at least with epics and stories oriented with INVEST and PQR (cf. table 1).

VI. GOVERNANCE

Each enterprise needs a governance structure ensuring that fundamental things are done in a deterministic way, and at minimum according to the state of the art. The state of the art is defined by organizational settings or derived from the market standard and regulations. Consequently, also all agile and lean teams have to establish and ensure the state of the art for their products and services. Depending on the product specific aspects, on top of the state of the art additional factors have to be ensured, e.g. market advantages. During the coaching phase aligned with the transition kit this is delivered by a team external coach. The coach has to make the teams sensitive for this governance topic and their team responsibility to stay aligned in the future. After the coaching phase the teams are independent and have to care about the "update" to the developing state of the art on their own. To make it easier for the teams, the governance offers update information about state of the art changes, which can be adopted by the teams. However, the governance has to ensure the alignment with the rail guards and update them to fit the state of the art. Rail guards are typically artifacts ensuring that some basics are done by the teams like for example an approval evidence for a deployment. Furthermore, the governance has to verify the effectiveness of its settings. These effectiveness checks are realized with controls. Different (domain) standards for System and Organization Controls (SOC) like [42] exist, but all have in common that the effectiveness of the established procedures has to be adequately checked, and if needed an alignment action has to be triggered. To ensure alignment with the settings and the agile and lean mindset a project review is established [38]. The project review (see figure 1) checks different aspects of an agile team or organization. Depending on the project or product classification (based on risk etc.) it will be checked in a deterministic way or randomized picked for a review. This ensures a basic transparency of alignment with the state of the art of the current portfolio.

The reviews are conducted by some coaches who have been trained in the evaluation aspects and their rating criteria. This common understanding about the aspects and rating ensures comparable results to derive organizational issues. Furthermore, an objective is not to change existing review aspects to keep the historical results in the dataanalysis pool.

The defined rail guards for the expected artifacts and outcomes for fulfilling external requirements like aspects of the GDPR [43] or quality standards like ISO 9000 are checked in the project review. The results are used on both levels, for the reviewed team as well as the overall organization. Most of the findings have to be addressed by the product teams, however some findings are seen in many teams. This is made by cyclic analysis of the project review results to identify "derivation pattern" which have to be addressed on the organizational level. A derivation pattern is identified if in a significant amount of the cyclic checks similar derivations are observed. This is the trigger to handle it not only on the specific product or service instance and start caring about it on a generic or organizational level. For each identified derivation pattern the governance checks why it does not fit to the product teams and their deliveries. This can lead to actions on the organizational level having a high bandwidth. Finally, there is the educational aspect that leads to inadequate setting -this is addressed by training or coaching offers to establish the things as intended. This may lead to refactoring the rail guards or artifacts to fit better into the project teams and the organizational culture. Figure 2 shows the relation between the product, the team and the governance. The relation "enhance" in figure 2 leads to the learning that as much as possible should be structured as self-service for the teams to reach higher autonomy and better scaling. This initial higher effort to develop the governance outcomes as self-service capability empowers the teams to live their self-organization and responsibility. To give feedback to the teams in a gamification context, the top ranked project review results are posted on an intranet page as a "champions league table" involving the entire organization.

The development and update of the transition kit is an additional important task to assure alignment with current regulations and the developing state of the art over the time. The transition kit has to support the governance artifacts like the rail guards during the team settlement. To do this, external and internal triggers are established. For example, the PQR method from the transition kit directly helps to make transparent why things are done in this way for some governance measures. An objective of the improvement of the transition kit from the governance perspective is to integrate as many measures as possible into the product or service artifacts or their direct production procedures. This integration makes it leaner and easier for the product teams to align their work with the expected outcomes and measures.

The Volkswagen Agile Community (AC) is the chance for everybody to get updates and the information about current development of agile and lean. It is an open community for networking and share knowledge about agile and lean. This includes also topics about the transition kit and agile governance.

DACH30 [41] is a trans-enterprise network to share experience about agile and lean. Trainings and skills are developed together. This ensures that the transition kit is reflected by external experts and is updated to the current insights of other enterprises.

The objective of the governance is to give the teams as much freedom for agility as possible while still demanding sufficient discipline from the teams to fit the compliance framework.

VII. EXPERIENCE REPORT

At Volkswagen AG Group IT, the transition kit development started in 2016 to support the coaches' daily work and has been enhanced continuously by the ACE and the coach guild to address the challenges of migrating to lean and agile methods in a structured way. Currently more than 100 product/service teams and organizational entities have been coached based on the elements of the transition kit. All those elements have been deployed -some more often than others (see table 1, column application). The teams are from the Group IT as well as other areas of the Volkswagen AG like plant production planning or vehicle development organizations, as well as smaller organizations like board member offices. The teams are supported during the transition in different life-cycle phases of their products and service. Some teams started on a green field, some were already established delivery teams. The range of software developed by the coached teams covers a wide range -from standardized ERP systems supporting human resources and production logistics to special software for supporting specific intellectual property of a business area. Also the architecture differs from established 3-tier architectures to cloud native micro-service based systems. The coaching phase differs in time from a few weeks to many monthsdepending on the size of the team or organization. Additionally, within the Volkswagen AG there exist a number of self-service based transitions which are often unknown to the ACE. By using the self-service, the teams have a low entry barrier because they can do it on their own way and speed, but the risk of applying inadequate elements of the transition kit is higher without an experienced coach.

The following parts of the case study reflect the objectives O1 to O3 and the observations of the application of the transition kit in the coaching phase as well as the results of the project reviews to have a long term perspective on the sustainability of the transition.

The lean and agile approaches are mapped to the transition kit artifacts to support the artifact selection. Depending on the approach, more or less options are offered to be chosen by the coaches and teams (O1). There is a trend in smaller teams without an end to end responsibility to use Kanban. This is motivated by the external process dependencies which limit the team's autonomy and freedom. The teams are often part of process driven value chains which drive the cycle time and delivery-dependencies. Hence, sprint commitments are not easy for the team. On the other side there is a trend to SAFe for transitions of multiteam organizations. Both show that the upper maturity levels are often not achieved.

The maturity derived from the spiral dynamics model of the teams is mapped to the transition kit artifacts to support especially lower leveled teams by choosing adequate approaches. With higher maturity levels the transition kit gets less importance because the teams have the capability of improving on their own and develop their appropriate way with supporting methods and tools to address their specific situation best (O2). Many teams have started their transition from the red or blue level Taylorism driven culture. However, some teams are built from scratch and in a greenfield area. Here, a quick move to "higher" levels is possible, because they do not have to learn to forget established habits and culture. The coaches typically can see some progress of one or two levels during their supporting phase. In the project reviews after a longer time a further progress can be observed. But in case of no strict application of agile methods and mindset some teams also go down to their "roots" with Taylorism habits. For these teams a "refreshing" coaching phase is suggested, if they still want to become agile.

The specific product setting with the complexity and value stream is supported by the transition kit, too. The artifacts are mostly generic and fit to the typical product settings in the complex setting (O3). In the future it could be possible to simplify the transition kit more by substituting complexity specific artifacts by generic ones.

The fact that the agile teams investigated in the case study are not permanently co-located does not significantly impact the application of the transition kit because most of the teams have some cyclic common physical meetings like refinements or retrospectives and use in-between communication tools to setup virtual team rooms.

The case study identifies that all phases of the transition are applied and supported as intended by the transition kit as described in section IV. The transition kit makes it easier to for new coaches to deliver transition support in a projectstyle to the teams in a standardized way. The integration of the transition kit in the holistic enterprise environment with a centralized product delivery process compliance helps the coaches and teams to be effective also from a compliance perspective. The controls of the effectiveness work because some transitions were not started because the environment did not fit according to the results of the readiness check. The control project review with its check aspects helps to show the effectiveness of the transition and its sustainability in the teams later on (see Fig. 3). Based on these measurements and metrics for agile projects, agile processes, and agile teams the governance identifies improvement potentials. For example, one related to the agile development process (which is the 2 nd bar in figure 3) effectiveness controls the re-thinking of the Group IT development process for a better alignment with agile and lean approaches and setting of guide lines which can easier integrated into operational excellence by the teams was indicated. Figure 4 shows the results of category agile development process of representative project reviews between 2017 and 2019. The x-axis are checked aspects of the project review which is aligned the teams agile adaption and the governance aspects. A more detailed description of the aspects and their grouping on the x-axis is in [38] described. The y-axis shows the fulfillment of the checked aspect. The bar in the middle shows the 2 nd and 3 rd quartile of values. The trend on derivations to the standardized templates of the development process is visible (every question has low values and almost all also high values -especially question f in figure 4). This derivation has led to the creation of a community of practice as a kind of working group whose mission is to enhance the Group IT development process to be better aligned with the state of the art habits of agile and lean working teams. This is one way of feedback to improve the environment to be more agile.

Often the coaches also identify new approaches, methods or tools which are evaluated as a kind of experiment during a selected team coaching. Results and lessons learned from this experiments are reflected in ACE to improve the transition kit. Furthermore, the case study shows that some transitions are not lasting or sustainable. The effectiveness of the transition is checked by the review with a delay to the coaching phase. By comparing the results achieved during the transition with the results of the progress reviews the progress or back-steps of the teams can be made transparent and thereby used for deriving the appropriate improvement actions. The selection of the reviews was made from feedback applications by randomized picking from the successful team transformation list and high-risk labeled projects/products. The highest frequency is one year for conducting reviews in a team. This is to avoid too many reviews in short time periods by random picking without the chance for the teams to improve in between reviews.

VIII. CONCLUSION

The presented holistic scaling approach demonstrates that a centralized agile governance can help large enterprises scale agile transitions in the product and service teams. This centralized ACEs coach guild and Agile Community are used to manage the agile knowledge and enhance the transition kit. The setup of a self-service driven team governance is a chance for establishing a lean governance approach. Furthermore the lean and agile mindset in governance offers the teams the chance to participate in the future "look and feel" of the governance, such as the development of higher automation of governance tasks and their evidences. This automation objective is a logical consequence of the automation with the everything as code approach [51] of devops. The governance will check the effectiveness of the participation driven development with the controls like the governance initiated reviews to ensure that the enterprise enhance in a positive way aligned with the strategy. A second observation is that the governance develops fast if they live the lean and agile mindset themselves. Their responsibility is to serve the teams in an effective way to be compliant with external and internal requirements.

The evaluation about the effectiveness of coaching with a transition kit is seen on two points:

-At the end of the coaching phase on which the readiness check situation and the current outcomes of the capability check are compared. -At the project review with the distance view (at least 1 year) after the transition coaching. The objective of the ACE is to be effective by the coaching support. This is realized with the transition kit by applying and enhancing the transition kit continuously with the lessons learned from the transitions coaching. The efficiency is seen on the higher team transformation throughput of coaches. The issue is to have a generalized kit which is easy to instantiate in the specific team setting. This trade-off is a current enhancement focus of the transition kit. Furthermore a contribution is that this transition kit explicitly handles the mental team setting by application of the spiral dynamics model to apply adequate approaches and methods during the transformation to support effectivity the progress and sustainability also after the coaching phase.

IX. NEXT STEPS AND FUTURE WORK

Sustainability is a topic that needs more focus. Often the agile project review makes transparent that after the coached transition phase, the teams lose some of the leaned rituals etc. and fall back to pre-transition habits. We need to define or develop external triggers to reflect the team's rituals and progress in the developing of the agile and lean mindset without the coaches. This is a topic for an effective governance of the agile and lean processes.

Furthermore, the amount of skilled coaches does not scale with the demand. We need to enhance the transition kit to a complete self-service approach. Then teams with some "basic" skills can work more autonomously, needing less coaching. This is a governance and training issue. The training aspect is to enable the teams to do mostly everything in a self-service manner by offering a suitable transition kit. But on the other side the governance has to ensure that also self-service transitions have high quality outcomes. Another open point is that the presented approach is only applied in a European enterprise culture. Its effectiveness in other cultural contexts still has to be investigated.

Next steps are the refactoring of the current process governance rail guards for a higher automation degree. The objective of the potential automation offers mature teams the integration into their automated product delivery pipeline (CI/CD chain). Some teams are currently experimenting and evaluating automated governance controls. The challenge is to find a balance between integrated standard tools and the freedom of the agile teams. Is automation an adequate indicator to determinate the product team maturity, especially in team's customized CI/CD chains? Will an individualized CI/CD chain slow down the integration of currently "independent" agile teams in future release trains of SAFe? Another interesting point is to extend the product based focus of the transition kit with a more lean and agile product finance scope like Beyond Budgeting [52].

Figure 4 :Figure 7 :Figure 8 :Figure 9 :

 4789 Figure 1: The Agile QM Triangle -Team, Product/Services, Governance .Figure 2: The EFIS framework for autonomous value streams. .................Figure 3: The tree pillars of quality management in agile organizations. ...Figure 4: Best time to perform aTWQ [AP8]. ............................................Figure 5: aTWQ complementing Scrum and SAFe [AP8]. ........................Figure 6: TTM complements aTWQ with a maturity framework [AP9]. ...Figure 7: Integration of the ideation approach [AP10]. ..............................Figure 8: Domain specific Design Thinking approach [AP10]. .................Figure 9: An example of filled posters from a cloud services [AP10]. ......Figure 10: Schematic picture of a practical LoD-PQR application [AP3].Figure 11: Schematic view of the merge of different LoD layers [AP5]. ...Figure 12: Schematic view of shared responsibility [AP5]. .......................Figure 13: Artefacts of an SSK package and their content [AP14]. ...........

Figure 11 :

 11 Figure 1: The Agile QM Triangle -Team, Product/Services, Governance .Figure 2: The EFIS framework for autonomous value streams. .................Figure 3: The tree pillars of quality management in agile organizations. ...Figure 4: Best time to perform aTWQ [AP8]. ............................................Figure 5: aTWQ complementing Scrum and SAFe [AP8]. ........................Figure 6: TTM complements aTWQ with a maturity framework [AP9]. ...Figure 7: Integration of the ideation approach [AP10]. ..............................Figure 8: Domain specific Design Thinking approach [AP10]. .................Figure 9: An example of filled posters from a cloud services [AP10]. ......Figure 10: Schematic picture of a practical LoD-PQR application [AP3].Figure 11: Schematic view of the merge of different LoD layers [AP5]. ...Figure 12: Schematic view of shared responsibility [AP5]. .......................Figure 13: Artefacts of an SSK package and their content [AP14]. ...........

Figure 1 :

 1 Figure 1: The Agile QM Triangle -Team, Product/Services, Governance

Figure 2 :

 2 Figure 2: The EFIS framework for autonomous value streams.

Figure 3 :

 3 Figure 3: The tree pillars of quality management in agile organizations.

Figure 4 :

 4 Figure 4: Best time to perform aTWQ [AP8].

Figure 5

 5 Figure 5 presents the relations of aTWQ v1.1 with Scrum and SAFe® (solid blue lines). The dotted red lines are new relations in version 1.1. The focus on Coordination of SAFe® in aTWQ v1.1 is more transparent. In the version 1.0, the designer avoided this high amount of relations to the topic Coordination, but the practice shows that especially in aTWQ self-service application, these missing relations can result in misunderstanding parts of the questionnaire. The detailed questionnaire related to the topics is presented in [AP6].

Figure 5 :

 5 Figure 5: aTWQ complementing Scrum and SAFe [AP8].

Figure 6 :

 6 Figure 6: TTM complements aTWQ with a maturity framework [AP9].

Figure 7 :

 7 Figure 7: Integration of the ideation approach [AP10].

Figure 8 :

 8 Figure 8: Domain specific Design Thinking approach [AP10].

Figure 9 :

 9 Figure 9: An example of filled posters from a cloud services [AP10].

Figure 10 :

 10 Figure 10: Schematic picture of a practical LoD-PQR application [AP3].

Figure 11 :

 11 Figure 11: Schematic view of the merge of different LoD layers [AP5].

Figure 12 :

 12 Figure 12: Schematic view of shared responsibility [AP5].

Figure 13 :

 13 Figure 13: Artefacts of an SSK package and their content [AP14].

Fig. 1 .

 1 Fig. 1. The EFIS framework for autonomous value streams within an enterprise.

Fig. 2 .

 2 Fig. 2. A domain-specific LoD and its product instantiation.

Fig. 3 .

 3 Fig. 3. Mapping of the EFIS practices to a Spotify model oriented organization.

Fig. 1 .

 1 Fig. 1. Schematic picture of a practical LoD-PQR method application scenario.

Fig. 2 .

 2 Fig. 2. LoD compliance process and involved stakeholders.

Figure 1 :

 1 Figure 1: Schematic view of accountability and shared responsibility for compliance

Table 2 :

 2 The controls of the ISO/IEC 27001:2013 for IT systems development4.1.2 Derivation of the ISO 27000 LoD layerThe ISO 27000 standard requires three layers for our example with the customer-(user-)driven development organization. The review of the security requirements with all stakeholders (14.1.1) leads to a handover of the refined and reviewed requirements to the development organization. Authorized users accept changes before operation (14.2.2). All other external/independent reviews could be modeled as handover, however, not all outcomes have to be reviewed in this case. Therefore, the explicit formal modeling of a level is not useful. This makes it possible to have the option to realize all ISO 27000 aspects in three LoD levels. The requirements 14.1.1 and the related refinements of 8, 9, 10 and 12 are assigned to the first level for the handover.As the final act of the development, the formal authorization of the change (release/version) is made (14.2.2) in the third level. All other identified aspects are mapped to the second level for the development.

©

  2021 The Authors. IET Software published by John Wiley & Sons Ltd on behalf of The Institution of Engineering and Technology. IET Soft. 2021;1-10. wileyonlinelibrary.com/journal/sfw2 -1

F I G U R E 1

 1 Interaction of the team with deliverables and the enterprise governance 2 -POTH ET AL.

F I G U R E 2

 2 The three pillars of quality in agile organisations and their relationships POTH ET AL.

F I G U R E 3

 3 Visualization of the related indicators of Scrum and SAFe® to agile Teamwork Quality (aTWQ)

F I G U R E 4

 4 Best time to perform agile Teamwork Quality (aTWQ) POTH ET AL.

Fig. 1 :

 1 Fig. 1: Value chain of SSK delivery approach by one governance, n SSK's and n*m outcomes.

ScopeFig. 2 :

 2 Fig. 2: Overview page of the SSK for SSK development.

Fig. 1 :

 1 Fig. 1: Coaching to team autonomy with integrated compliance check

Fig. 2 :

 2 Fig. 2: Transition's key parts and their relationships

  864PREPROCEEDINGS OF THE FEDCSIS. LEIPZIG, 2019

Fig. 3 :

 3 Fig. 3: Anonymized review results of the categories shows spreads and potentials (1 is most left bar -6 most right bar)

Fig. 4 :

 4 Fig. 4: Maturity of the agile development process (1 is most left bar -6 most right bar)

  866PREPROCEEDINGS OF THE FEDCSIS. LEIPZIG, 2019

Table 1 :

 1 Coverage of the Agile QM Triangle by EFIS elements. ...............

Table 2 :

 2 Comparison of different agile approaches in enterprise contexts.

Table 3 :

 3 Decision-table for selection type of compliance check [AP4]. ....

Table 4 :

 4

Example for a specific company's transition tool kit [AP16]. .....

Table 2 : Comparison of different agile approaches in enterprise contexts.

 2

	Aspect	EFIS	DA	SAFe® Less Nexus™ Scrum Spotify
	Shared re-
	sponsibil-ity/account-ability of	+ [51]	+ [30]
	governance
	Usable as overlay framework	+ [48]		+
	Scales from one team to tion level organiza-	+ [58] [57]		+
	Explicit in-
	tegrated quality manage-	+ [48] [56]		(+) [66]
	ment
	Regulation	+
	/ compli-ance-ori-	[49] [50]	+
	ented	[51]
	Team-spe-cific adap-sign tion by de-	+ [52] [55] [54] [53]	+	+
	Domain-specific design adaption by	+ [51] [48]		+
	Offers rollout op-tions	+ [48]	+ [29]

  • 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

  The Disciplined Agile Enterprise (DAE) -https://www.pmi.org/disciplined-agile/process/dae. Last request: 23.04.2021 30. The Disciplined Agile -Legal. https://www.pmi.org/disciplined-agile/process/legal. Last request: 23.04.2021 31. The Disciplined Agile -Governance. https://www.pmi.org/disciplined-agile/process/governance. Last request: 23.04.2021 32. The Disciplined Agile Quality. https://www.pmi.org/disciplined-agile/construction-goals/improve-quality. Last request#: 23.04.2021 33. Scrum -https://www.scrumguides.org/; Last request: 09.03.2021 34. Huang, C.C. and Kusiak, A., 1996. Overview of kanban systems. Pp. 169-189. 35. Reis, E., 2011. The lean startup. New York: Crown Business, 27.

	26. Recipes https://www.cprime.com/wp-content/uploads/woocommerce_up-for Agile Governance in the Enterprise Ref. AP3 Ref. AP6 Ref. AP9 Contribution Design of the BSea method based on the Integration of the Ref. AP15 Publication Poth, A., Schubert N. and Riel A., 2020. Sustainability Effi-Appendix A -Overview of Published Thesis Articles Publication Poth, A., Jacobsen, J. and Riel, A., 2020. A systematic ap-Publication Poth, A., Kottke, M. and Riel, A., 2020. Evaluation of agile Publication Poth, A., Kottke, M., Mahr, T. and Riel, A., 2021. Teamwork PQR approach with a Blockchain technology specific eval-Publication Poth, A., Kottke, M. and Riel, A., 2019. Scaling agile on ciency Challenges of Modern IT Architectures -A Quality	-
	loads/2013/07/RAGE-Final-cPrime1.pdf; Last Request: 23.04.2021 proach to agile development in highly regulated environ-team work quality. In International Conference on Agile quality in technology-driven product teams in large-scale ag-uation delivered as Self-Service Kit (SSK). large enterprise level-systematic bundling and application Model for Serverless Energy Footprint. In: Yilmaz M., Nie-
	27. Scaling Agile in Regulated Environments: https://www.youtube.com/ watch?v=w3ZBbyAwee8; Last Request: 23.04.2021 28. Recipes for Agile Governance in the Enterprise -https://www.cprime.com/resources/blog/category/agile-articles/ Last re-Ref. ments. In International Conference on Agile Software De-Software Development (pp. 101-110). Springer, Cham. ile organizations. Journal of Software: Evolution and Pro-Literature Guidance frameworks for Distributed Ledger Technologies of state of the art approaches for lasting agile transitions. In mann J., Clarke P., Messnarz R. (eds) Systems, Software and AP1 Publication velopment (pp. 111-119). Springer, Cham. Contribution Design of the aTWQ approach to measure agile Team Work cess. E2388. https://doi.org/10.1002/smr.2388 (DLT) and Blockchains. 2019 Federated Conference on Computer Science and Infor-Services Process Improvement. EuroSPI 2020. Communica-Poth A., Kottke M., Heimann C., Riel A., 2021. The EFIS Contribution The Level of Done (LoD) approach to address regulatory as-Quality. Contribution Refinement of the generic aTWQ approach with a generic Validation Successful BSea application in two automotive DLT use mation Systems (FedCSIS) (pp. 851-860). IEEE. tions in Computer and Information Science, vol 1251. Framework for Leveraging Agile Organizations Within Large Enterprises. In: Gregory P., Kruchten P. (eds) Agile pects in agile quality management. Literature technology maturity approach. cases applied to different Blockchain technologies. Contribution Design of a method for selecting agile and lean methods and Springer, Cham. Approaches to measuring and improving teamwork quality. quest: 23.04.2021 Processes in Software Engineering and Extreme Program-ming -Workshops. XP 2021. Lecture Notes in Business In-formation Processing, vol 426. Springer, Cham. https://doi.org/10.1007/978-3-030-88583-0_5 Contribution The EFIS framework and its pillars, as well as its combina-tion with the Spotify model as a case study showing how to EFIS can be combined with other agile frameworks/models. Explanation how EFIS has been composed from the other contributions listed here. Literature Comparable agile frameworks taking governance into ac-count explicitly. Validation Successful EFIS deployment in financial and automotive or-ganizations. Ref. AP2 Publication Poth, A.1007/978-3-030-85521-5_7 Literature Key challenges in large-scale agile environments with re-spect to regulatory compliance integration. Validation Successful LoD application in the Volkswagen Financial Services AG. Ref. AP4 Publication Poth, A., Jacobsen, J. and Riel, A., 2020. Systematic agile development in regulated environments. In European Con-ference on Software Process Improvement (pp. 191-202). Springer, Cham. Contribution Extension of the Level of Done (LoD) approach with team maturity demands for smaller sample size and different eval-uation times of product related outcomes. Literature Challenges and success factors for large-scale agile transfor-mation. Validation Successful instantiation in a financial organization. Ref. AP5 Publication Poth, A.27(8), pp. 868-893. Contribution Design of a product domain specific LoD layer method to Validation Proof of concepts (PoC) in different settings of the Volkswagen Group IT, at the scale of teams within an organ-izational unit. Ref. AP7 Publication Poth, A.Springer, Cham. Contribution Adaptation of the aTWQ team work quality measurement approach to a particular agile transformation context. Literature The role of team size and performance in agile transfor-mation. Validation Adaptation and application to a specific product develop-ment team. Ref. AP8 Publication Poth, A., Kottke, M. and Riel, A., 2021. Measuring team work quality in large-scale agile organizations. IET Soft-ware; https://doi.org/10.1049/sfw2.12036 Contribution Extension of the aTWQ approach to form the third quality Literature tools aligned with the team maturity for fostering the effec-Contribution Analysis of electric power consumption of serverless com-Technology capability development in teams. Validation Application of the TTM approach in different legal entities and teams. Ref. AP10 Publication Poth, A., and Riel, A., 2020. Quality requirements elicitation by ideation of product quality risks with design thinking. In 2020 IEEE 28th International Requirements Engineering Conference (RE), pp. 238-249. IEEE. Contribution Design of a method for systematically identifying Product Quality Risks (PQR) in an agile context and based on Design Thinking. Literature Systematic Ideation methods, Design Thinking and derived methods. Validation Successful PQR method application in 32 projects in differ-ent business domains. Ref. AP11 Publication Poth, A., Meyer, B., Schlicht, P. and Riel, A., 2020. Quality Assurance for Machine Learning -an approach to function and system safeguarding, IEEE 20th International Confer-ence on Software Quality, Reliability and Security (QRS), pp. 22-29, IEEE. Contribution Design of the evAIa method based on the integration of the Ref. AP13 Publication Poth, A., Kottke, M. and Riel, A., 2020. Scaling agile on large enterprise level with self-service kits to support auton-omous teams. In 2020 15th Conference on Computer Sci-ence and Information Systems (FedCSIS) (pp. 731-737). IEEE. Contribution Design of the Self Service Kit (SSK) method for autono-mous knowledge sharing between agile teams for spreading knowledge about products, processes and teams within large-scale organizations. Literature Knowledge sharing methods supporting team autonomy and large scaling. Validation Overview of more than 10 active SSKs in the Volkswagen Group IT, and analysis of their scaling effects. Award Best Paper Award of 4 th International Conference on Lean and Agile Software Development (LASD'20) with the 15 th conference on Computer Science and Information Systems (FedCSIS 2020) Ref. AP14 Publication Poth, A., Kottke, M. and Riel, A., 2020. The implementation of a digital service approach to fostering team autonomy, distant collaboration, and knowledge scaling in large enter-tiveness of agile transition. Literature Lean agile development methods. Validation Successful application of the transition-kit methods in more than 100 teams and organizational entities. Award Best Paper Award of 3 rd International Conference on Lean and Agile Software Development (LASD'20) with the 14 th Federated conference on Computer Science and Information Systems (FedCSIS'19) Ref. AP16 Publication Poth, A., Kottke, M., and Riel, A., 2019. Scaling Agile-A Large Enterprise View on Delivering and Ensuring Sustain-able Transitions. In: Advances in Agile and User-Centered Software Engineering, pp. 1-18, Springer, Cham. Contribution Design of a life-cycle approach to supporting agile transi-tions of teams and organizations by readiness checks, agile maturity models and agile project reviews. Literature Agile maturity models and their roles in agile transition. Validation Application in the context of a rollout sequence from readi-ness check to maturity check and project review applied at the Volkswagen Group IT over more than four years. Ref. AP17 puting based on a life-cycle stage model and proposal of as-pects for a more sustainable cloud-based serverless service design. Literature Serverless computing approaches and impact analyses. Validation Measurements based on openFaaS, an open source server-less computing service, to validate the hypothesis. Ref. AP19 Publication Oyelami O.A., Poth A., Hintsch J. and Riel A., 2019. Quality Assurance and Traceability in Containerized Continuous Delivery Process. In: Walker A., O'Connor R., Messnarz R. (eds) Systems, Software and Services Process Improvement. EuroSPI 2019. Communications in Computer and Infor-mation Science, vol 1060. Springer, Cham. Contribution Design of an approach for continuous quality and compli-ance checks during the containerization process of applica-tions. Literature Establishing traceability in cloud-based application design. Validation Structured traceability validation of containerized continu-ous delivery at the Volkswagen Group IT. Ref. AP20 Publication Poth, A., Beck Q. and Riel A., 2019. Artificial Intelligence 29. Systems Design. Procedia CIRP, 84, 1015-1022. 40. Breitschuh, J., Albers, A., Seyb, P., Hohler, S., Benz, J., Reiß, N., and Bur-sac, N., 2018. Scaling agile practices on different time scopes for complex problem solving. DS 91: Proceedings of NordDesign 2018, Linköping, Sweden, 14th-17th August 2018. 41. Macher, G., Brenner, E., Messnarz, R., Ekert, D., and Feloy, M., 2019. Transferable competence frameworks for automotive industry. In European Conference on Software Process Improvement (pp. 151-162). Springer, Contribution Detailed description of the EFIS framework and its building blocks. Literature Analysis of relevant agile frameworks and evaluation of their capabilities. Validation Evaluation against research questions in enterprise environ-ment. address accountability appropriately in an agile context. Literature Lean governance approaches to addressing responsibility and accountability demands. Validation Successful evaluation in a specific software development context confronted with data privacy and IT security require-ments. pillar with team quality, complementing the two established pillars product and process quality. Literature Team quality models and their roles in agile transformation. Validation Application as part of the established agile project review within several product teams leading to a continuous aTWQ application feedback. PQR approach with a ML technology specific evaluation de-livered as Self-Service Kit (SSK). Literature Guidance frameworks for Machine Learning algorithms. Validation Successful evAIa application in different brands and do-mains of the Volkswagen Group. Ref. AP12 Publication Poth, A., Pukall, M., Zuehlke, Y. and Riel, A., 2021. Quality Assurance for Block-chain-based Services. A Systematic Guidance Framework. -Unpublished draft. prises. Human Systems Management, vol. 39, nr. 4 (pp.573-588). IOSPress. IOContribu-tion Definition of the life-cycle for self-service kits (SSK) and design of blue-prints for SSK building and delivery. Literature Organizational learning frameworks, their deployment and effectiveness over time. Validation Investigation of ten SSKs of all three quality domains (prod-uct, process and team) Publication Helps Making Quality Assurance Processes Leaner. In: Poth, A., Urban, H. and Riel, A., 2021. Make product and Walker A., O'Connor R., Messnarz R. (eds) Systems, Soft-service requirements shippable -from the cloud service vi-ware and Services Process Improvement. EuroSPI 2019. sion to a continuous value stream which satisfies current and Communications in Computer and Information Science, vol future user needs. Springer -in print. 1060. Springer, Cham. Contribution Design of a life-cycle for cloud services based on phases and Contribution Design of a Machine Learning (ML) approach to support their specific quality focus. Literature system testing with test case prioritization (TCP). Agile requirements engineering for cloud-based services. Validation Literature Test case prioritization methods, risk-based test case selec-Successful implementation in the Volkswagen Group IT's tion. Testing as a Service (TaaS). Validation Effective application to three projects from different busi-Cham. Ref. AP18 ness domains of the Volkswagen AG.

36. Steghöfer, J.P., Knauss, E., Horkoff, J. and Wohlrab, R., 2019. Challenges of scaled agile for safety-critical systems. In International Conference on Product-Focused Software Process Improvement (pp. 350-366). Springer, Cham. 37. IEC 61508-1:2010 -https://www.vde-verlag.de/iec-normen/previewpdf/info_iec61508-1%7Bed2.0%7Db.pdf; Last request: 09.03.2021 38. Albers, A., Hahn, C., Niever, M., Heimicke, J., Marthaler, F., & Spadinger, M., 2020. Forcing Creativity in Agile Innovation Processes through ASD-Innovation Coaching. In Proceedings of the Sixth International Conference on Design Creativity (ICDC 2020) (pp. 231-238). 39. Albers, A., Heimicke, J., Spadinger, M., Reiss, N., Breitschuh, J., Richter, T., Bursac, N. and Marthaler, F., 2019. A systematic approach to situation-adequate mechatronic system development by ASD-Agile , Kottke, M. and Riel, A., 2021. Orchestrating agile IT quality management for complex solution development through topic-specific partnerships in large enterprises -an example on the EFIS framework. In: Yilmaz M., Clarke P., Messnarz R., Reiner M. (eds) Systems, Software and Services Process Improvement. EuroSPI 2021. Communications in Computer and Information Science, vol 1442. Springer, Cham. https://doi.org/10., Kottke, M., Middelhauve, K., Mahr, T. and Riel, A., 2021. Lean integration of IT security and data privacy governance aspects into product development in agile organizations. Journal of Universal Computer Science (J.UCS). , Kottke M. and Riel A., 2020. Agile Team Work Quality in the Context of Agile Transformations -A Case Study in Large-Scaling Environments. In: Yilmaz M., Niemann J., Clarke P., Messnarz R. (eds) Systems, Software and Services Process Improvement. EuroSPI 2020. Communications in Computer and Information Science, vol 1251.

Table 3 : Decision-table for selection type of compliance check [AP4]. Product Qual- ity Risks Team accountability Team maturity Sample size Check time

 3

	mid, high	low	low	high (like	preventive
				100%)
	mid, high	low	mid	mid (like 75%) detective
	mid, high	mid	low	mid (like 75%) detective
	low	low	low	low (like 10%) detective
	low, mid, high low, mid, high high	low (like 10%) detective

Table 4 : Example for a specific company's transition tool kit [AP16]. Method / Tool Spiral dynamic model team maturity Stacey mapping of prod- uct/ service context

 4

	Retrospective	Purple or higher	All
	Design Thinking	Blue or higher	All
	Minimum Viable Prod-	Orange or higher	Complex & compli-
	uct (MVP)		cated
	Simple Lovable and	Blue or higher	Complex & compli-
	Complete (SLC)		cated
	Business Model Canvas	Purple or higher	Complex & compli-
	(BMC)		cated
	Product Vison Board	Purple or higher	Complex & compli-
	(PVB)		cated
	INVEST	Purple or higher	Complex & compli-
			cated
	Definition of Ready	Blue or higher	All
	(DoR)
	Definition of Done	Blue or higher	All
	(DoD)
	Levels of Done (LoD)	Blue or higher	Complex & compli-
			cated
	Product Quality Risk	Ref or higher	Complex & compli-
	(PQR)		cated
	Scrum	Purple or higher	Complex & compli-
			cated
	Extreme Programming Green or higher	Complex & compli-
			cated
	KANBAN	Beige or higher	Complex & compli-
			cated
	SAFe	Red or higher	Complex & compli-
			cated
	LeSS	Blue or higher	Complex & compli-
			cated
	Nexus	Orange or higher	Complex & compli-
			cated
	Scrum@Scale	Orange or higher	Complex & compli-
			cated

  20. Poth, A., Kottke, M., Riel, A.: The implementation of a digital service approach to fostering team autonomy, distant collaboration, and knowledge scaling in large enterprises. J. Hum. Syst. Manag. 39(4), 573-588 (2020). https://doi.org/10.3233/HSM-201049 21. Festinger, L.: A theory of social comparison processes. Hum. Relat. 7(2), 117-140 (1954) 22. SAFe®. Achieving Regulatory and Industry Standards Compliance with SAFe. https://www. scaledagileframework.com/achieving-regulatory-and-industry-standards-compliance-withsafe/. Accessed 14 July 2021 23. Kellogg, M., Schäf, M., Tasiran, S., Ernst, M.D.: Continuous compliance. In: 2020 35th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 511-523. IEEE (2020)

Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

  17. Poth, A., Riel, A.: Quality requirements elicitation by ideation of product quality risks with design thinking. In: Proceedings of the 28th IEEE International Requirements Engineering Conference (RE 2020), Vienna (2020, in print) 18. BAIT. https://www.bafin.de/SharedDocs/Downloads/EN/Rundschreiben/dl_rs_1710_ba_ BAIT_en.pdf?__blob=publicationFile&v=6. Accessed 11 June 2020 19. INVEST. https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/. Accessed 11 June 2020 Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

	1	Introduction
	Many business domains have established ways to address regulations like the General
	Data Protection Regulation (GDPR) [GDPR, 21] for privacy in the European Union,
	and standards like the ISO 27000 series for IT Security Management Systems (ISMS)
	[ISO27000

Table 3

 3 Software Bill of Material (SBOM), which includes a listing of the reputable sources. The assets registry/lists have to be maintained and reviewed.

	Customer level Development level	Approval level
	Perform an	Principles.	Obtaining
	information	Development of software and systems is	formal approval
	security	based on established rules of the organization	and acceptance
	requirements	(14.2.1) by e.g. secure coding guidelines,	of the change
	analysis and	security in the development methodology,	(release) by
	specification	security requirements in the design phase,	authorized users
	(14.1.1)	security checks within milestones (like	or customers to

presents an LoD layer for the ISO 27000 that has been established according to the logic explained above. Each line of the table addresses a topic. Some pillars have to handle more topics than others.

Table 3 :

 3 LoD layer for ISO 27000 for in-house software development in an agile organization

Table 1 .

 1 aTWQ questionnaire with specific indicators for Scrum and SAFe® and team development level.

	Topic	Question (Base Practices)	Scrum	SAFe®	Level
	Participative	Do we have a "we are in it			IV
	safety	together" attitude driven
		by the ability and
		willingness to help and
		support each other in
		carrying out their tasks?
		Do people keep each other	Daily Scrum	Program, team	I
		informed about work-		backlog
		related issues in the team
		supported by a frequent
		communication?
		Do people feel understood			III
		and accepted by one
		another?
		Are there real attempts to	Daily Scrum,	Portfolio	(I) III
		share information	Retrospective	Kanban, Inspect
		throughout the team driven		& Adapt
		by openness of the
		information exchange?
		Is there a lot of give and		Innovation and	IV
		take by the team members'		Planning
		motivation to maintain the		Iteration
		team?
		Do we keep in touch with		Pairing/frequent	III
		one another as a team by		review
		accepting that team goals
		are more important than
		individual goals?
				(continued)

Table 1 .

 1 (continued)

			Evaluation of Agile Team Work Quality
	Topic	Question (Base Practices)	Scrum	SAFe®	Level
	Task	Do your team colleagues		Pairing/frequent	IV
	orientation	provide useful ideas and		review
		practical help to enable
		you to do the job to the
		best of your abilities?
		Are team members	Daily Scrum,		IV
		prepared to question the	Refinement
		basis of what the team is
		doing?
		Does the team critically	Refinement,		II
		appraise potential	Retrospective
		weaknesses in what it is
		doing in order to achieve
		the best possible outcome?
		Do members of the team	Refinement,		(I) IV
		build on one another's	Retrospective
		ideas in order to achieve
		the highest possible
		standards of performance?
	Coordination	Is there a common	Backlog,	Roadmap,	III
		understanding when	Stories	Portfolio, ART,
		working on parallel		Iteration plan,
		subtasks, and agreement		Stories
		on common work
		breakdown structures,
		schedules, budgets and
		deliverables?

TABLE I .

 I DIFFERENTIATION OF SSK TYPES ABOUT PRODUCT/PROCESS/TEAM-QUALITY

	Aspect	Product	Process	Team
	Scope of the	Technology	Workflows	Behavior
	SSK		and activities
	Outcomes	Questions and	Questions	Questions and
	of the SSK	checklists	and methods	indicators
	Evidences	Objective	Evidences	Impressions
	of (correct)	evidences often	depending on	often subjective
	usage of the	persistent	implementati	(no/weak
	SSK in the		on and often	evidences) in a
	final		temporary	specific setting -
	instantiation			non
				deterministic
				behavior
	Bloom's	Evaluation of	Evaluation of	Evaluation of
	taxonomy	product	adequate	adequate
	cognitive	characteristics	sequences of	improvement
	domain		activities	action for the
				team
	Bloom's	Organizing of	Organizing	Organizing the
	taxonomy	usage, features,	of workflows	behavior and
	affective	capabilities of	and activities	knowledge of
	domain	products	for a specific	the team to
			purpose	identify improvements
	Bloom's	Origination of	Origination	Adaptation of
	taxonomy	usage, features,	of workflows	interacting/work
	psychomoto	capabilities of	and activities	ing methods to
	r domain	products	for a specific	fit team
			purpose	potentials
	Problem-	Problems on	Problems are	Problems are
	based	tangible objects	mostly	often related to
	learning	are good to	visible on	behavior and
		measure and	their	their actions -
		improve	interface of activity outcomes and	outcomes can be used as indicators
			interactions

TABLE II .

 II MATURITY LEVELS OF THE SPIRAL DYNAMICS MODEL[4]

	Name	Structure	Motives	Characteristics
	Beige	Loose	Survival	Archaic, instinctive,
		bands		basic, automatic
	Purple	Tribes	Magic, Safety	Animistic, Tribalistic,
				Magical, Mystical
	Red	Empires	Power,	Egocentric,
			Dominance	Explorative,
				Impulsive, Rebellious
	Blue	Pyramidal	Order, right &	Absolutistic,
			wrong	Obedient, Purposeful,
				Authoritarian
	Orange	Delegative	Autonomy,	Materalistic,
			achievement	Strategic, Ambitious,
				Individualistic
	Green	Egalitarian	Approval,	Relativistic,
			Equality,	Personalistic,
			Community	Sensitive, Pluralistic
	Yellow	Interactive	Adaptability,	Systemic, Conceptual,
			Integration	Ecological, Flexible
	Tortoise	Global	Compassion,	Holistic, Global
			Harmony

© The Author(s) 2020 M. Paasivaara and P. Kruchten (Eds.): XP 2020 Workshops, LNBIP 396, pp. 111-119, 2020. https://doi.org/10.1007/978-3-030-58858-8_12

A.Poth et al.

A.Poth et al.

Poth A., Kottke M., Middelhauve K., Mahr T., Riel A.: Lean integration of ...

© The Author(s) 2020 M. Paasivaara and P. Kruchten (Eds.): XP 2020 Workshops, LNBIP 396, pp. 101-110, 2020. https://doi.org/10.1007/978-3-030-58858-8_11

A.Poth et al.

A.Poth et al.

-POTH ET AL.

-POTH ET AL.

PREPROCEEDINGS OF THE FEDCSIS. SOFIA, 2020

PREPROCEEDINGS OF THE FEDCSIS. LEIPZIG, 2019

Acknowledgements

Thank you Andreas for making this thesis possible with your patience with me and your creative ideas for handling all the organizational challenges and constraints. Additional thank goes to all persons supporting and contributing with their feedbacks and ideas to this work -the co-authors and uncountable reviews of the peer-reviewed publications, the valuable advices of the annual thesis progress review committee and last but not least the defense committee. Furthermore, it made me happy to work in the open and constructive setup of the Grenoble INP G-SCOP laboratory and the Volkswagen AG, that created the opportunity for this work.

DATA AVAILABILITY STATEMENT

Research data are not shared.

Appendix C -An Agile Journey through the EFIS Building Blocks

In this appendix, I picked the visual representations of some key EFIS building blocks as listed in Table 1, in order to provide a visual overview of the framework and its consistency across it elements. All these visuals have been taken from my own publications as listed in Appendix A. The IDs next to the figures' legends refer to these papers' sequence numbers in that very annex. Please note that this visual guide cannot and does not want to replace the careful study of each paper in order to understand well the rationale, design, application, and validation of each building block.

Appendix D -Own Thesis-Related Articles in full Length

49

Indented reduced to open publications in this version; the full list of references is given in Appendix A.

All three parts interact and need a holistic handling by the transition kit to realize a comprehensive product or service from the customer view who is using the product/service. The tool selection of the transition kit (table 1) is initially based on a first fit for purpose. This first fit was realized by a literature review [40] to identify artifacts for the initial transition kit. The transition kit contains approaches, methods and tools which helps the coach and team to go in an effective way into the right direction during the transition. Over the life cycle the transition kit will be enhanced by adding and changing artifacts to better fit the current organizational culture, for an easier integration into the coaching or simpler use in a self-service approach for teams without coaches. The enhancement is triggered by feedbacks. While everybody can suggest new artifacts for the transition kit, the ACE will evaluate and integrate relevant suggestions during their cyclic inspections. The objective is not to have a maximum of possible elements in the transition kit, but rather to have a lean transition kit that can be trained easily and is effective in most organizational settings. To make it easy to find the right artifacts the transition kit is aligned with the product complexity, team maturity and the agile approaches.

To identify the projects the ACE supports with coaches we use the Stacey matrix. It is an easy to use way to identify if agile is helpful or not.

The assignment of tools to phases is based on experience during the supported transitions. The determination of the appropriate transition kit artifacts is done according to the following procedure: To start in a value-driven way, the initial focus of the transition is the product or service. The product is located on the Stacey-matrix. Over the product life-cycle, the complexity location is more or less stable in emerging markets -with a trend to reduction of complexity in mature markets or at the end of a product life-cycle. The current state is identified and the future result or objective will be considered to advance in the right direction. In a second step, the relevant governance guidelines are identified. Based on the product and governance demands, the current team skills and capabilities are focused on. The product team setting is located in the spiral dynamics model (table 2) color levels. This location is important because often organizations coined by Taylorism established over years, act on the "red level". These teams have to make their mindset leaner to achieve the "blue level". Agile teams typically act on levels of blue and higher. Each team has to grow level by level in their maturity. This leads to the adaptation of the used artifacts over the maturity journey of a team. Based on the team's maturity and their product environment complexity, the appropriate agile approach will be selected mostly based on the suggestions of table 2, however the guide and the team can make adjustments if they think another artifact would fit better. The artifacts help the team to progress in the transition, but most of the transition effort is to enable and coach the team to deliver a product. Some examples about the experience-based labeling of the table: Why is Kanban applicable in beige teams? Kanban does not define a set on rituals like retrospectives from Scrum which demands a minimum level of trust in the team