Digitale Transformation meistern: Ein Fallbeispiel (Teil 1)

Der Streit über Methoden in der Softwareentwicklung ist entschieden. Die agile Organisation steht kurz davor, sich als die dominante Organisationsform zu entwickeln. Die aktuelle Literatur speziell zur agilen Softwareentwicklung zeigt das eindrucksvoll, sowohl in empirischer Untersuchung wie auch in der Theorie. (In [1] liefern Forsgren, Humble, und Kim fundierte Belege für den Zusammenhang zwischen agilen/DevOps-Methoden sowie Geschäftserfolg. In [2] präsentiert D. Reinertsen die zugrunde liegenden Prinzipien.) Und doch hilft auch dieses Wissen nicht, wenn es darum geht, Unternehmen agil oder digital zu transformieren. 

In unserer zweiteiligen Artikelserie zeigen wir auf, wie wir mit agilen Methoden und Arbeitsweisen in einem konkreten Kundenprojekt (“One Touch Retail” - OTR) die digitale Transformation des Automobilherstellers Daimler vorantreiben. Wir wollen Mut machen, sich den Herausforderungen der digitalen Transformation zu stellen, denn die Ergebnisse lohnen sich. Neben einigen Schwierigkeiten und Hindernissen werden durch die Transformation erhoffte neue Fähigkeiten entwickelt und Werte geschaffen. Und wenn man einmal die neue, agile Arbeitsweise gelebt hat, kann man eigentlich nicht mehr zurück.

Überblick

In dem mehrjährigen Transformationsprojekt bei Daimler haben wir gelernt, dass wir mehrere Paradigmenwechsel gleichzeitig angehen mussten (Stichworte: Agile Softwareentwicklung, DevOps, Design Thinking). Dazu benötigten wir besondere Unterstützung vom Management. Wir haben unsere Projektstruktur in vielen Bereichen anders aufgestellt und haben moderne Infrastruktur- und Steuerungswerkzeuge genutzt (Stichworte: Cloud oder Lean PMO). Letztendlich entwickelten wir damit eine Feedback-zentrierte Umgebung, die es uns erlaubt, extrem schnell auf neue Anforderungen zu reagieren und dabei ein Produkt zu entwickeln, das unsere Anwender lieben werden. 

Unsere wichtigsten Erkenntnisse aus dem Transformationsprojekt sind: 

• Gelerntes zu entlernen und die tägliche Arbeitsweise grundlegend zu verändern, benötigt eine gehörige Portion Mut – von allen Beteiligten. 
• Klein anfangen. Wir haben schnell und ganz klein angefangen und dann skaliert. 
• Bei der digitalen Transformation steht die Anwendung von agilen Prinzipien im Vordergrund, nicht das sture Befolgen einer speziellen Methode.
• Die Nutzung von Commodity-Infrastrukturen macht uns schneller.
• Sich selbstorganisierende, cross-funktionale Produktteams stehen im Mittelpunkt.
• Wir erreichen höhere Effektivität durch Offshore-Teams auf Augenhöhe.

Paradigmenwelchsel

Digitalisierung ist nicht nur eine technische Transformation. Sie erfordert weitreichende, multiple Paradigmenwechsel bzw. ein Umdenken in vielen Bereichen. Darüber hinaus ist dies keine einmalige Aktivität oder Lernerfahrung, sondern eine fortlaufende Änderung von tiefgehenden Denkmustern und täglichen Verhaltensweisen. Wir sehen dabei fünf verschiedene Paradigmenwechsel: 

1. Von Wasserfall-Methodik zu Agiler Softwareentwicklung
2. Von Projekt zum Produkt 
3. Von Entwicklung und Betrieb zu DevOps
4. Von Anforderungsanalyse zu Design Thinking
5. Von IT Service Management zu Fokus auf Business Value 

Für uns macht es Sinn, diese einzelnen Paradigmenwechsel gleichzeitig anzugehen (auch wenn dies aus der Perspektive des Change Managements paradox erscheinen mag: Es ist bekannt, dass zu viele gleichzeitige Änderungen im Unternehmen zum Zustand Organisational Change Fatigue führen kann, s. [3]). Denn viele der von den Paradigmen auf der rechten Seite genutzten Praktiken und Architekturen ergänzen und unterstützen sich gegenseitig. Grundsätzlich erfordern diese Paradigmenwechsel eine Kultur der Offenheit, des Vertrauens, des Teilens (z. B. von Verantwortung), der Demut (z. B. als Subject-Matter-Expert nicht alles wissen zu müssen und können) und der Inklusion.

“One Touch Retail”

Beim OTR Projekt handelt es um eine mehrjährige digitale Transformation im Rahmen der Daimler Best Customer Experience Initiative, s. [4]. Daimler hat uns beauftragt, gemeinsam einen innovativen und intuitiv zu bedienenden digitalen Assistenten für VerkäuferInnen zu entwickeln, mit dem Ziel, das Altsystem abzulösen. Der Verkaufsprozess soll dadurch attraktiver gestaltet werden. Gleichzeitig können sich VerkäuferInnen bei Daimler noch gezielter auf ihre KundenInnen fokussieren. Weiterhin soll die neu zu erstellende Plattform OTR flexibel sein, um sich den ändernden Anforderungen des Automobilmarktes zu stellen.     

Ein globales Team, verteilt auf die Standorte Deutschland, Indien und China, arbeitet an dem neuen Verkaufsassistenten. Das deutsche Team entwickelt das System für den deutschen Markt und arbeitet dazu eng mit den KollegInnen in den indischen Entwicklungszentren zusammen. Gleichzeitig entwickelt das chinesische Team einen ähnlichen Assistenten, der perfekt auf den chinesischen Markt zugeschnitten ist (s. [5]).

Änderungen des Status Quo

Mit OTR setzen wir die IT-Strategie des Daimler Konzerns in vielen Bereichen um. So erhöhten wir die Frequenz von neuen Software Releases von einem Deployment pro Monat zu mehreren Deployments pro Tag in die Produktionsumgebung und damit zu einem kontinuierlichen Prozess (Continuous Delivery). Die IT-Architektur wurde von einem n-tier-Ansatz auf eine Microservice-Architektur umgestellt, die Infrastruktur hat sich von einer lokalen Installation zur Nutzung von Cloud-basierten Komponenten gewandelt. Bisherige manuelle Tests wurden durch vollständig automatisierte Tests ersetzt und ermöglichten letztendlich erst einen kontinuierlichen Deployment-Prozess. So wurde eine Kehrtwende von der Wasserfall-Methodik hin zur agilen Software-Entwicklung mit Anwendung von DevOps-Methoden vollzogen. Wir nutzen nun freie und quelloffene Software (Free and Open Source Software, FOSS) anstelle von proprietären Lösungen. Anstatt einer klaren Trennung von Business- und IT-Funktionen setzen wir auf eine möglichst enge Integration im Rahmen von cross-funktionalen Produktteams.

Daimler im Umbruch

Einer der wichtigsten und zugleich auch schwierigsten Aspekte einer digitalen Transformation ist die Etablierung einer neuen Arbeitskultur. Aktuell befindet sich Daimler in der Transformation vom Automobilhersteller zum Anbieter von Mobilitätsdienstleistungen. Dies hat natürlich auch konkrete Auswirkungen auf unsere Arbeit im OTR Projekt. Forderungen nach höherer Geschwindigkeit, schnellerem Lernen und Agilität, Stichwort “#TwiceAsFast” ([6] und [7]) rücken in den Fokus. Dahinter steht auch die Erkenntnis, dass in der Automobilindustrie der Kundennutzen, insbesondere im Bereich Mobility as a Service (MaaS), durch digitale Produkte entscheidend verbessert werden kann. Die Qualität der Produkte wird jedoch durch die Fähigkeit und Geschwindigkeit bestimmt, sich an neue Kundenbedürfnisse anpassen zu können und vom Kundenverhalten zu lernen.

Moderne Software-Technologie sehen wir hier als einen Treiber für Innovation. Mit Technologie den Entwicklungsprozess zu beschleunigen sowie Feedback-Zyklen zu verkürzen und zu bewerten, steht dabei bei uns im Vordergrund. Genau diese Fähigkeit ist die Grundlage für Innovation im Kleinen (in [8] zeigt D. Newman Vorteile von Micro-Innovationen gegenüber Macro-Innovationen).

Auch hier sehen wir einen Paradigmenwechsel: Während wir zu Beginn des OTR Projekts häufig die Einstellung “Wir kennen die Bedürfnisse von unseren Anwendern genau, wir machen das schon seit 20 Jahren” sahen, übernahmen wir vermehrt Methoden des Design Thinking. Wir begannen regelmäßige Anwender- und Kundenbefragungen (Research) durchzuführen und entwickelten eine neue Offenheit und die Erkenntnis, eben nicht alle Bedürfnisse kennen zu können (siehe [9] zum Begriff Shoshin oder Beginner’s Mind, der im Design Thinking genutzt wird).

Die 4 Katalysatoren der Daimler ITS Strategie

Unterstützt wird dieser Paradigmenwechsel des Design Thinkings durch den Einsatz von vier identifizierten Katalysatoren:

1. Eine radikale Prozessvereinfachung reduziert die Komplexität und die Dopplung von Tätigkeiten, um einfachere Prozesse stärker zu automatisieren.
2. Der Fokus soll sich weg vom Projekt zum eigentlichen Produkt verschieben. Ziel ist es, Daten dazu zu verwenden, Kosten zu sparen, Umsatz zu steigern und eigene Intellectual Property und eine eigene User Base aufzubauen.
3. Geschwindigkeit als strategischen Vorteil nutzen, um beispielsweise durch Continuous Delivery zeitnah Kundenbedürfnisse in den eigenen Produkten umzusetzen.
4. Die Organisation soll furchtlos bestehende Regeln und Prozesse infrage stellen und aus Fehlern und Feedback aktiv lernen.

Mit der Verschiebung der Gewichtung vom Projekt hin zu digitalen Produkten verändert sich auch das Selbstverständnis der IT-Organisation. Weg vom Servicedienstleister im Sinne des IT Service Managements ITSM (vergleiche ITIL [10]), hin zu einer Zusammenarbeit auf Augenhöhe (s. [11]). Im OTR Projekt erleben wir dies in der täglichen Arbeit in cross-funktionalen Teams. Beispielsweise arbeiten Business Product Owner gemeinsam mit IT Product Ownern an Initiativen und bringen dabei gleichberechtigt ihre Sichtweisen und Fähigkeiten ein.

Darüber hinaus setzen wir im OTR Projekt weitere Elemente der Daimler Strategie konsequent um:

• Einsatz von Free and Open Source Software 
• Cloud-basierter Betrieb, der DevOps ermöglicht
• Implementierung von Microservices, die per API erreichbar sind
• Arbeit in dynamischen Schwärmen
• Verwendung von Daimler Standard Security Providern

All diese Bestandteile des Projekts zahlen direkt auf die Daimler IT-Strategie ein.

Im OTR Projekt setzen wir die Daimler IT-Strategie konsequent um. 

Ways of Working

Von Beginn an haben wir es uns zum Ziel gesetzt, eine Arbeitsumgebung für alle Teammitglieder zu schaffen, die es jedem erlaubt, kontrolliert Fehler zu begehen und daraus zu lernen (siehe [12] für eine fundierte Erklärung der Kaizen Kultur). Diese Offenheit gegenüber Fehlern wirkt auf zwei Ebenen: Zum einen fördern wir hiermit den Erkenntnisgewinn und die Innovation. Zum anderen ist es einfacher, neue (z. B. mit agilen) Praktiken einzuführen, in dem wir experimentieren, d. h. Hypothesen aufstellen, Experimente hierzu durchführen und den Erfolg oder Misserfolg messen und dann eventuell umschwenken. Auch hier nutzen wir das Prinzip der kleinen Batch-Größe, das heißt wir führen regelmäßig viele kleine Änderungen an der Arbeitsweise durch, anstatt zunächst eine neue Arbeitsweise bis ins Detail zu entwerfen, abzustimmen und dann mit Change Management Aktivitäten einzuführen. Prinzipien der agilen Arbeitsweise lassen sich damit auch für die Umsetzung der Paradigmenwechsel heranziehen. 

Grundlegende Werte und Arbeitsweisen infrage zu stellen und Praktiken zu entlernen, erfordert enorme Kraftanstrengungen. Dabei haben uns die folgenden Gegebenheiten geholfen, die Transformation anzugehen: 

• Die Automobilbranche befindet sich in einem fundamentalen Wandel (s. hierzu z. B. [13]). Die dahinterstehenden gesellschaftlichen, technischen und ökonomischen Umwälzungen sind mittlerweile so präsent im öffentlichen Diskurs, dass Handlungsbedarf offensichtlich ist. Während der Wandel auf der einen Seite eine Herausforderung oder sogar Bedrohung darstellt, ermöglicht er jedoch auf der anderen Seite, Kräfte für solche Änderungsvorhaben zu mobilisieren.
• Zu Beginn des OTR Projekts haben wir eine große Offenheit gegenüber agilen Methoden und der bereits genannten Paradigmenwechsel vorgefunden. Schon in der initialen zweiwöchigen Inception-Phase haben wir immer wieder das Motto “Trust the Process” gehört. Dies zeigt den Vertrauensvorschuss, den uns Projektmitarbeiter aufseiten von Daimler, die bislang wenig mit agilen Methoden in Kontakt gekommen sind, gegeben haben. 

Offenheit, Transparenz, regelmäßige Retrospektiven und die Möglichkeit, auch schwierige Themen auf den Tisch zu bringen helfen uns, dieses Vertrauen zu erhalten, auszubauen sowie das Momentum der Änderung beizubehalten. 

Retrospektive

Team-Setup und Fähigkeiten

Die Entwicklung von digitalen Produkten basiert auf einer ganzen Reihe von Fähigkeiten, die Teams oder Organisationseinheiten beherrschen müssen. Um agile Methoden in der Softwareentwicklung wirklich erfolgreich umsetzen zu können, reicht die Einführung von Scrum bei Weitem nicht aus. Neben den bekannten Praktiken der agilen Entwicklung werden u. a. Testautomatisierung, Continuous Delivery, Microservices, Infrastructure as Code benötigt. Hinzu kommen Ansätze wie Design Thinking oder DevOps. Um uns einen Überblick über diese Fähigkeiten innerhalb des Teams verschaffen zu können, haben wir diese in die Kategorien Organisationsdesign, Produktdesign, Technologie, Strategie und Kultur strukturiert (in [14] schlägt D. Frese hierzu Technologie, Organisationsdesign, Produktdesign, Strategie und Kultur (TOPS) vor, in [1] finden wir eine Klassifizierung in Continuous Delivery, Architektur, Produkt und Prozess, Lean Management und Monitoring sowie Kultur). Die folgende Abbildung zeigt eine Auswahl der wichtigsten Fähigkeiten. Viele Fähigkeiten unterstützen sich dabei gegenseitig oder verstärken die positive Wirkung der anderen. (In [15] merkt Martin Fowler hierzu an: “all of this stuff flows together, The most important thing about Extreme Programming is that the individual practices of Extreme Programming reinforce each other”).

Einige Thesen sollen diese Beziehungen verdeutlichen: 

• Wenn Teams autonom arbeiten sollen, müssen die benötigten Fähigkeiten und damit Personen im Team vorhanden sein. Dies führt zwangsläufig zu cross-funktionalen Teams. 
• Die Skalierung von agilen Produktteams bedingt die Reduzierung von Abhängigkeiten zwischen den Teams. Microservices können helfen, die Autonomie der Teams zu stärken. 
• Die Einführung und der Betrieb einer Microservice-Architektur setzt die Beherrschung von Fähigkeiten wie die Nutzung von automatisierten Deployment-Pipelines (CI/CD), Infrastruktur-Automatisierung, Monitoring, etc. (s. M. Fowler [16]). 
• Hypothesengetriebene Entwicklung basiert auf der Möglichkeit, sich irren zu können. Dazu ist eine sichere Arbeitsumgebung notwendig. 
• Design Thinking benötigt Kreativität, welche wiederum von Diversität profitieren kann.
• Die Umsetzung von agilen Prinzipien benötigt Testautomatisierung, denn mit manuellen Tests sind die häufigen Deployments nicht zu erreichen. Diese wird durch die Implementierung einer Testpyramide unterstützt (Details hierzu s. Hermann Vocke [17]). 

Übersicht von sich-gegenseitig unterstützenden Fähigkeiten

Im OTR Projekt nutzen wir das Zusammenspiel dieser Fähigkeiten und haben fast alle der in oben stehenden Abbildung vorgestellten Fähigkeiten implementiert. 

Die agile Softwareentwicklung ist daher nur ein kleiner Teil des Fähigkeiten-Spektrums, das von aktuell führenden Software-fokussierten Unternehmen eingesetzt wird. Organisationen, die am Anfang ihrer digitalen Transformation stehen, benötigen daher Unterstützung von außen. Für uns steht dabei nicht ein Training oder ein Coaching im Vordergrund. Unsere Erfahrung hat uns gezeigt, dass Paradigmenwechsel schneller und wertbringender durch die Arbeit in realen Projekten umgesetzt werden können. Wichtig ist dabei, Projektmitarbeiter einzubeziehen, die diese Prinzipien und Fähigkeiten bereits leben. 

Agilität leben

Nach einer Umfrage von McKinsey [18] gehört agile Softwareentwicklung mittlerweile zum Stand der Technik. Martin Fowler [15], Thoughtworks Chief Scientist, unterstützt diese These und berichtet gleichzeitig über ein Phänomen, das er Faux-Agile nennt. Andere Autoren nennen dies Fake Agile (s. [19]) oder Cargo Cult Agile (s. [20]). Die Autoren erleben oft Situationen, in denen Teams stolz behaupten, sie würden nach agilen Methoden arbeiten. Oft ist dies – im positiven Sinn – noch weit davon entfernt, was Ron Jeffries als Dark Scrum (s. [21]) beschreibt. Wir möchten daher betonen: Rollen nach Scrum zu vergeben, eine Backlog zu führen, tägliche Standups zur organisieren und mit Stickies zu arbeiten, ist nur der Start. Wir glauben, dass es wichtiger ist, die agilen Prinzipien (s. [22]) in den Vordergrund zu stellen, als Methoden wie Scrum, Kanban oder noch schlimmer SaFE stringent zu befolgen. Wir meinen damit Prinzipien mit dem Fokus auf Wertschöpfung für Kunden und selbstorganisierende, cross-funktionale, autonome Teams, die regelmäßig, in kurzen Abständen laufende Software liefern. 

Ein grundlegendes Prinzip ist einzelnen Teams die Freiheit zu geben, selbst über konkrete Arbeitsweisen, Tools oder sogar Programmierumgebungen innerhalb von bestimmten Leitplanken bestimmen zu können. Diese Möglichkeit wird insbesondere durch die Microservice-Architektur (s. [23]) erleichtert. Bei unseren OTR Projekt nutzen einige Teams bspw. Clojure, andere hingegen Kotlin als Programmiersprache im Backend. Einige Teams arbeiten mit zweiwöchigen Sprints, andere nach Continuous Delivery Prinzipien oder Kanban. Manche Teams schätzen die Größe von User Stories mit Story Points, andere Teams verfolgen einen NoEstimates Ansatz.

Wir sind überzeugt, dass die Entwicklungsgeschwindigkeit mit dieser Freiheit erhöht werden kann. Positiv wirkt sich hierbei auch Daimlers Ansatz aus, freie und quelloffene Software (FOSS) verstärkt einzusetzen (s. [24]).

Ein weiteres Prinzip ist die ständige Anpassung und Weiterentwicklung der Arbeitsweise. Wir können dies z. B. an folgender Beobachtung festmachen: Wir demonstrieren regelmäßig unsere Arbeitsweise interessierten Kollegen von Daimler. Von Woche zu Woche sehen wir dabei Änderungen an unseren Büro-Wänden, d. h. die Struktur des Kanban Boards hat sich geändert, die Roadmap hat den Lean Value Tree verdrängt, die Skill Matrix war letzte Woche noch nicht da, etc. (Anmerkung: Wir nutzen unsere Bürowände als sogenannte Information Radiator, d.h. große Flächen um Informationen visuell und interaktiv darzustellen, s. hierzu auch [25]).

Ein Resultat der grundlegend geänderten Vorgehensweise ist beispielsweise der Go-Live oder wie wir es nennen, das Handover. Viele von uns kennen diesen Vorgang noch als nervenaufreibendes Event, das regelmäßig an Wochenenden oder über Nacht stattfindet, um die dabei benötigte Downtime in Zeiten zu legen, in denen die Anwendung nur wenig genutzt wird.

In unserem OTR Projekt haben die Übergabe der Anwendung als No-Event durchgeführt. Dabei haben wir den Nutzern die Anwendung freigeschaltet und sie per E-Mail darüber informiert. Das ist möglich, weil die Anwendung durch den Continuous Delivery Ansatz (s. [26]) praktisch immer in der Produktionsumgebung verfügbar ist. Auch die Übergabe weiterer Funktionalität geschieht entsprechend: Hierzu schalten wir mithilfe von sogenannten Feature-Toggles (s. [27]) neue Komponenten frei und informieren dann die Nutzer hierüber. 

Zusammenfassung und Ausblick

Im ersten Teil des Artikels haben wir die Paradigmenwechsel einer digitalen Transformationen identifiziert, das Fallbeispiel, unser Projekt One Touch Retail (OTR) erläutert, vorgestellt, wie Daimler den Umbruch angeht, agile Arbeitsweise am Fallbeispiel diskutiert und untersucht, wie wir Faux Agile (Fake Agile oder Cargo Cult Agile) vermeiden können. 

Im zweiten Teil wollen wir tiefer einsteigen, u. a. die Rolle des Managements klären, Beispiele für Arbeit in cross-funktionalen Teams vorstellen, uns mit Zeremonien beschäftigen, den Beitrag von Diversity bei der Suche von kreativen Lösungen diskutieren, einen weiteren Paradigmenwechsel im Bereich Kundenzentrierung kennenlernen und einen Ausblick zum weiteren Verlauf der digitalen Transformation geben.

Referenzen

[1] Nicole Forsgren, Jez Humble und Gene Kim: “Accelerate”, IT Revolution, Portland, 2018
[2] Donald G. Reinertsen: “The Principles of Product Development Flow: Second Generation Lean Product Development”, Celeritas Publishing, Redondo Beach, 2009
[3] Wikipedia: “Organizational Change Fatigue”, https://en.wikipedia.org/wiki/Organizational_change_fatigue
[4] Daimler: “Best Customer Experience 4.0" – Press Presentation in The Hague: Kick-Off for the luxury experience 4.0: Mercedes-Benz presents the next chapter of the global sales strategy "Best Customer Experience”, https://media.daimler.com/marsMediaSite/ko/en/43937825, 2019
[5] Thoughtworks: “Innovative software development for the sales experience of the future”, https://www.thoughtworks.com/clients/daimler, 2017
[6] Jan Brecht: “My top three IT priorities at Mercedes-Benz to focus on in 2018”, LinkedIn, https://www.linkedin.com/pulse/my-top-three-priorities-mercedes-benz-focus-2018-jan-brecht/, 2018
[7] Jan Brecht: “#TwiceAsFast: How to build a learning based culture”, LinkedIn, https://www.linkedin.com/pulse/twiceasfast-how-implement-learning-based-culture-jan-brecht/, 2019
[8] Daniel Newman: “Why Micro-Innovation should be at the Core of your Digital Transformation”, Forbes, https://www.forbes.com/sites/danielnewman/2016/02/02/why-micro-innovation-should-be-at-the-core-of-your-digital-transformation/#5405b0837684, 2016
[9] Jesse Russel Morgan: “Beginner’s Mind in UX Design”, https://uxdesign.cc/beginners-mind-in-ux-design-with-shunryu-suzuki-11a00787c8a9?gi=f923553c2102, 2018
[10] Wikipedia: “ITIL”, https://en.wikipedia.org/wiki/ITIL
[11] Mark Schwartz: “A Seat at the Table: IT Leadership in the Age of Agility”, IT Revolution, Portland, 2017
[12] David J. Anderson: “Kanban, Successful Evolutionary Change for Your Technology Business”, Sequim, Washington, 2010
[13] McKinsey: “Automotive Revolution - Perspective towards 2030”, https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/disruptive-trends-that-will-transform-the-auto-industry/de-de, 2016
[14] Dino Frese: “How modern IT is like Tetris and how TOPS makes sense of everything”, Thoughtworks, https://www.thoughtworks.com/insights/blog/how-modern-it-tetris-how-tops-makes-sense-everything, 2018
[15] Martin Fowler: “The State of Agile Software in 2018”, https://martinfowler.com/articles/agile-aus-2018.html, 2018
[16] Martin Fowler: “Microservices Prerequisites”, https://martinfowler.com/bliki/MicroservicePrerequisites.html, 2014
[17] Hermann Vocke: “The Practical Test Pyramid”, MartinFowler.com, https://martinfowler.com/articles/practical-test-pyramid.html, 2018
[18] McKinsey: “How to create an agile organization”, Survey, https://www.mckinsey.com/business-functions/organization/our-insights/how-to-create-an-agile-organization, 2017
[19] Steve Denning: “Understanding Fake Agile”, Forbes Media, https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/#35870f914bbe, 2019
[20] Wikipedia: “Cargo Cult Science”, https://en.wikipedia.org/wiki/Cargo_cult_science
[21] Ron Jeffries: “Dark Scrum”, https://ronjeffries.com/articles/016-09ff/defense/, 2016
[22] Agile Manifesto: “Principles behind the Agile Manifesto”, https://agilemanifesto.org/principles.html, 2001
[23] Sam Newman: “Building Microservices”, O’Reilly Media, Sebastopol, CA., 2015
[24] Torben Stephan, Ludger Schmitz “Interview with Vlado Koljibabic, Head of CASE IT at Daimler”, Data Center Insider, https://www.datacenter-insider.de/wir-kennen-die-vorteile-von-open-source-a-708188/, 2018
[25] Kasandra Fcong “Transform Meetings with a Great Information Radiator”, Thoughtworks,  https://www.thoughtworks.com/de/insights/blog/transform-meetings-great-information-radiator, 2016
[26] Jez Humble and David Farley “Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation”, Addison Wesley, 2011
[27] Pete Hodgson: “Feature Toggles (aka Feature Flags)”,  https://www.martinfowler.com/articles/feature-toggles.html, 2017