Den folgenden Beitrag habe ich zusammen mit Martin Milcke (CIO Mercedes-Benz Vertrieb Deutschland) auf dem Insights Blog von ThoughtWorks veröffentlicht.

Im ersten Teil des Berichts 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. 

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

Skin in the Game

Die Erstellung von digitalen Produkten erfordert viel Aufmerksamkeit von Führungskräften im Allgemeinen und Produktmanagern im Besonderen. Denn wie wollen wir ein inspirierendes, innovatives Produkt entwickeln, wenn wir die Verantwortung hierfür abgeben und andere die Arbeit machen lassen? Wie Nassim Nicholas Taleb in Skin in the Game [16] darlegt, benötigen wir Führungspersönlichkeiten, die mit Haut und Haar bei der Sache sind.

Konkret bedeutet dies für die Entwicklung von digitalen Produkten und Transformationen:

• Projektmitarbeiter des Auftraggebers können ein solches Projekt nicht mit ein paar Stunden pro Woche realisieren, sondern benötigen die volle Aufmerksamkeit, d. h. mindestens 80 Prozent ihrer Arbeitszeit fokussierte Arbeit im Projekt.  
• Auftraggeber können ihr Risiko nicht per Festpreisvertrag an einen Zulieferer übergeben. 
• IT-Organisation und Fachbereiche müssen zusammenarbeiten (mehr hierzu unter [6]). 
• Als Anwender sehen wir Produkte oder Services in ihrer Gesamtheit. Daher sollten Teams auch eine End-to-End-Verantwortlichkeit erhalten und müssen eine Kollaboration zwischen unterschiedlichen Organisationseinheiten organisieren.
• Bedingt durch das Gesetz zur Arbeitnehmerüberlassung (s. [37]) wurden in deutschen Unternehmen klare Leitlinien vorgegeben, wie die Zusammenarbeit zwischen Auftraggebern und Zulieferern zu erfolgen hat. Dies gilt u. a. für die Beschäftigung von IT-Fachkräften. Wie ein Urteil aus dem Jahr 2003 zeigt, sind hierzu insbesondere die Erteilung von Anweisungen ausschlaggebend (s. [38]). Da eine enge Zusammenarbeit zwischen Produktteams und den zugeordneten Product Ownern wichtig für den Erfolg von digitalen Produkten ist und oftmals die entsprechenden Rollen von Mitarbeitern unterschiedlicher Firmen gestellt werden, entsteht hier ein Spannungsfeld. Es gilt also agile Arbeitsformen zu etablieren, die einerseits Kollaboration fördern und andererseits rechtliche Risiken für Auftraggeber, Zulieferer und Mitarbeiter minimieren.           
• Insbesondere in Transformationen werden couragierte Führungskräfte gebraucht, die nicht auf sicher spielen, sondern die den Mut besitzen, eigene Verhaltensweisen umzulernen und umsetzungsstark dabei zu helfen, die Änderungen im Unternehmen anzugehen und voranzutreiben (siehe u.a. [50] zum Begriff Courageous Leadership). 
  

In unserem OTR Projekt hatten wir das Glück, Projektmanager zu finden, die sich involviert haben und den Mut aufgebracht haben, die Paradigmenwechsel anzugehen. In diesem Zusammenhang haben folgende Praktiken geholfen, eine vertrauensvolle Zusammenarbeit zu etablieren und uns auf eine Vision einzuschwören: 

• In einem Visionsworkshop haben wir gemeinsam mit allen Projektbeteiligten eine klare Vision unseres digitalen Produkts erstellt. Es war aufwendig, alle Stakeholder für einen halben Tag mit dieser Aufgabe zu betreuen. Dadurch haben wir nun das Buy-in aller Beteiligten. So fällt es uns leichter, in täglichen Diskussionen, z. B. über die richtige Priorisierung von User Stories, eine gemeinsame Position zu finden. 
• Ausgehend von dieser Vision haben wir einen Lean Value Tree erstellt, der ableitend von globalen Zielen Hypothesen definiert, die mithilfe von Initiativen entweder verifiziert oder falsifiziert werden. Auch wenn man anstelle von Hypothese auch von Teilzielen sprechen könnte, macht dies einen enormen Unterschied. Mithilfe einer Hypothese bekommen wir – wenn vielleicht auch nur psychologisch gesehen – die Möglichkeit, irren zu können. Besser noch, je höher die Wahrscheinlichkeit, dass die Hypothese falsch ist, desto mehr Informationsgewinn kann aus ihr gezogen werden (vergleiche hierzu Reinertsen [1]).
• Insbesondere aus Führungspositionen heraus versuchen wir eine Arbeitsumgebung zu etablieren, die Teammitgliedern Sicherheit vermittelt, Möglichkeiten gibt, kalkulierte Risiken einzugehen und dabei auch Fehler zu machen, und ermuntern dissente, konstruktive Diskussion – wissend, dass bessere Lösungen sich oft aus unterschiedlichen Meinungen entwickeln. 

Cross-funktionale Produktteams

Wie bei jedem unserer Projekte bei ThoughtWorks arbeiten wir auch bei Daimler in cross-funktionalen Produktteams. Diese bestehen üblicherweise aus zwei bis drei Entwicklerpaaren (Entwickler), einem Business Analyst (BA), einem Quality Analyst (QA) und einem User Experience Designer (XD). Pro zwei bis drei Produktteams wird ein Projektmanager eingesetzt. 

Die cross-funktionalen Produktteams sollten selbstorganisierend sein. Nach Lektüre über agile Entwicklungsmethoden scheint dies offensichtlich (siehe z.B. [44], Kapitel What makes an agile team tick). Das folgende Beispiel soll zeigen, wie Selbstorganisation ganz konkret aussehen kann: Nachdem in der Aufbauphase ein Team auf eine Größe von 15 Personen angewachsen war, wurde allen Beteiligten klar, dass eine Aufteilung in zwei separate Teams notwendig war. Nach dem Stand-Up haben wir zwei Flipcharts aufgestellt und das Team gebeten, sich auf zwei Teams aufzuteilen. Die Namen der Teammitglieder wurden auf Stickies geschrieben und mit ein wenig unterstützender Moderation durch die beteiligten Business Analysten hatte das Team nach 15 Minuten eine erste Aufteilung der Personen auf die beiden zukünftigen Teams erreicht. Ein kurzes Review zeigte, dass die Aufteilung noch nicht perfekt war und nach weiteren 15 Minuten hatten wir ein Ergebnis, an dem alle mitgewirkt hatten. Das Buy-in war dementsprechend hoch. Interessant ist, dass sich damit auch die Aufgaben der Führungskräfte verschieben und u. a. mehr Freiraum für kreative Arbeit entsteht (In [35] beschreibt F. Laloux eindrucksvoll wie weitgehend sich Führungsrollen durch selbstorganisierende Teams verändern können.). 

Die cross-funktionalen Produktteams arbeiten autark an dedizierten Business-Funktionalitäten wie z. B. der Fahrzeugkonfiguration. Um die Verteilung von Initiativen auf die Produktteams, die Vorbereitung von Research-Aktivitäten und die Zusammenarbeit der Produktteams sowie das Management von Abhängigkeiten zu koordinieren, haben wir ein sogenanntes Produktstrategie-Team aufgestellt. Die Größe und Besetzung dieses Teams haben wir über die Zeit den unterschiedlichen Phasen und Herausforderungen angepasst. Beispielsweise haben wir für fünf Entwicklungsteams ein Produktstrategie-Team. Dieses Team besteht aus einem Vollzeit Programm Business Analyst, einem Vollzeit User Experience Designer und einem/einer flexibel hinzu gezogenen Chef-EntwicklerIn. Zu den Aufgaben der Produktstrategie-Teams gehörten beispielsweise: 

• Definition der Produkt-Vision gemeinsam mit Product Ownern.
• Aufstellung und Pflege des Lean Value Trees (s. [45] für eine Definition).
• Entwicklung der Produkt-Roadmap.
• Verteilung der Initiativen auf die Produktteams.
• Vorbereitung der Initiativen, u. a. Koordinierung und Durchführung von User Research Aktivitäten.
• Navigation des Spannungsfeldes zwischen Feature Parity und neuen Funktionalitäten.

Diversity als Treiber für Innovation

Eine Studie der North Carolina State University zeigt, dass ein kausaler Zusammenhang zwischen der Diversität der Mitarbeiterschaft (gemessen an Gender, Race und Sexual Orientation) und der Fähigkeit, neue, innovative Produkte und Services zu entwickeln, existiert (s. [33]). Wir können dies am Beispiel des OTR Projekts gut nachvollziehen. Die folgenden Daten geben einen Eindruck von der Zusammensetzung der Teams: 

• 41 Prozent weiblich oder divers
• Mindestens zwölf unterschiedliche Nationalitäten
• Offenheit gegenüber Mitarbeitern aus der LGBTIQ Community
• Drei Hunde (s. [35] über die positiven Effekte wenn Hunde Teil der Arbeitskultur werden)

In unserer täglichen Arbeit erleben wir, dass viele unterschiedliche Lebenserfahrungen und persönliche Hintergründe unserer Teammitglieder zu vielen inhaltlich interessanten Diskursen führen. Das, gepaart mit einer Kultur der Offenheit, die alle unabhängig ihrer Herkunft oder Titel motiviert, Ideen einzubringen und bekannte Verfahren infrage zu stellen, führt zu einer durchaus anstrengenden Diskussionskultur, die jedoch zu innovativen Lösungen führt: So wurden wir von Daimler für die Arbeit an OTR China mit dem Supplier Award in der Kategorie Innovation ausgezeichnet (s. [34]).

Einen weiteren Hinweis zur Schaffung einer Arbeitsumgebung, die Kreativität, Produktivität und Kollaboration fördert liefert D. Pink in [53]. Er beschreibt die positiven Einflüsse von Spaß bei der Arbeit, Lachen, Spielen, Freude und Humor. Das Video zur Vorstellung des Berliner ThoughtWorks Büro gibt einen guten Einblick in die Umsetzung dieser Erkenntnisse (s. [52]). Die regelmäßig stattfindenden Hackathons liefern weitere Ideen, erhöhen den Spaß bei der Arbeit und stärken den Zusammenhalt der Teams.    

Verteilte Agile Entwicklung

Um Entwicklungskapazitäten besser skalieren zu können und Kosten geringer zu halten, haben wir uns frühzeitig entschieden, Entwicklungsteams aus Indien einzubinden. Dabei hat es sich bewährt, zunächst die Onshore-Teams zu etablieren, grundlegende Arbeitsabläufe und Zusammenarbeitsformen einzuüben. Nach rund fünf Monaten sind wir die zusätzlichen Herausforderungen, die die verteilte agile Entwicklungsweise mit sich bringt, wie z. B. Kommunikation, Sprache, unterschiedliche Zeitzone, angegangen.  

Oft sind wir auf Offshoring-Ansätze gestoßen, die nach dem Prinzip der verlängerten Werkbank (s. [11]) organisiert sind. D. h. es werden einfache, standardisierte Aufgaben an die Offshore-Teams vergeben. Wir waren überzeugt, dass wir einen grundlegend anderen Ansatz benötigten, um verteilte agile Softwareentwicklung wirklich effektiv durchzuführen. Von Anfang an haben wir darauf geachtet, unsere Offshore-Teams und die individuellen Projektmitglieder auf Augenhöhe zu betrachten und ihnen die Voraussetzungen mitzugeben, die eine solche Arbeitsform ermöglichen. 

Um eine Arbeit auf echter Augenhöhe gewährleisten zu können, ist eine Investition in Reisetätigkeiten notwendig. Gerade zu Beginn der verteilten Arbeit haben wir darauf geachtet, persönliche Beziehungen zwischen den an der Entwicklung beteiligten Personen, insbesondere Product Owner, Technology Lead und User Experience Designer herzustellen. Dazu führten wir regelmäßige Face-to-Face Workshops im Inception-Format durch (s. hierzu [10]).  

Die Zuordnung von Initiativen zu den Produktteams, insbesondere aus Sicht der Teams, die im Offshore Delivery Center arbeiten, erfolgte durch das Produktstrategie-Team, unter folgenden Kriterien: 

• Verfügbare Kapazität von Produktteams.
• Größe von Arbeitspaketen. Größere Arbeitspakete haben wir eher an die Offshore-Teams vergeben, da dies eine längere, ununterbrochene Arbeit an einem Thema ermöglichte und damit der Bedarf nach vor-Ort Inceptions verringerte (s. Sunil Mundra [10]).
• Tiefe des fachlichen Verständnisses. Bei Themen, die einen häufigen Austausch der Entwicklungsteams mit den Product Ownern und den Anwendern benötigten, haben wir uns aus Überlegungen zur Geschwindigkeit eher für die Onshore-Teams entschieden. 
• Verfügbarkeit von Product Ownern für bestimmte Themen und Zeiträume. 

Die Komplexität von fachlichen Themen haben wir bewusst nicht als Kriterium verwendet. 

Cadence ist wichtig: Die Zeremonien

In [1] beschreibt D. Reinertsen, wie kürzere, regelmäßig geplante, in gleichbleibenden Intervallen stattfindende Abstimmungen die Batch Größe verringern können, was wiederum zu kürzeren Wartezeiten (durch kleinere Queues) und damit schnelleren Durchlaufzeiten führt. Wir setzen dieses Prinzip um, in dem wir uns von Beginn an auf bestimmte – wir nennen es – Zeremonien einigen und diese zu den immer gleichen Zeiten stattfinden lassen. Dies reduziert den Overhead von vielen kürzeren Meetings. 

Täglicher Standup am Kanban Board

Dabei hilft uns auch, dass wir in den meisten Fällen alle am gleichen Ort sind (Face-to-Face, co-located). Falls jemand physisch nicht auf der Projektfläche sein kann, wählt sich die Person per Video-Konferenz ein. 

Tech Huddle im Berliner Event Space, zugeschaltet sind die Entwickler aus dem indischen Delivery Center

Name	Wie oft	Teilnehmer	Ziel
Standup	Täglich, morgens	Alle Teammitglieder, optional der Product Owner und weitere Interessierte	Synchronisierung, Info über den Arbeitsstand und Fortschritt, Identifikation von Problemen und Abhängigkeiten, Visualisierung des Fortschritts am Kanban Board
Signup	Täglich, direkt nach dem Stand-up	Entwickler des Teams	Festlegung, wer an welcher User Story für diesen Tag arbeitet
Retrospektive	Alle 2 Wochen	Alle Teammitglieder	Identifikation von Verbesserungsmöglichkeiten und Zuweisung von Aktionen
Showcase	Alle 2 Wochen	Alle Projektmitglieder und Gäste	Vorstellung des Arbeitsfortschrittes anhand von laufender Software, Vorstellung von wechselnden Fachthemen
Tech Huddle	wöchentlich	Alle Entwickler im Projekt	Diskussion von technischen Details, Möglichkeiten zum Refactoring, Diskussion zum Einsatz von neuen Tools
Projekt Mgmt. Catch Up	wöchentlich	Projektmanager von Daimler und ThoughtWorks	Diskussion von kommerziellen und Projektmanagement Themen
ThoughtWorks Leadership	wöchentlich	Teilnehmer des Client Leadership Teams	Identifikation von Risiken und Möglichkeiten, Team- und Kundenzufriedenheit zu verbessern
Daimler M&G	Täglich, 15 Minuten	Daimler Projektteam	aktuelle Themen, Entscheidungen (Vortag, heute, ggfs. zukünftig)
Gilden-Treffen	wöchentlich oder 2-wöchentlich	Abhängig von der Gilde, z.B. Security-Gilde, QA-Gilde, BA-Gilde, Designer-Gilde	Weiterentwicklung von technischen Fähigkeiten, Alignment über Teams, z. B. zur Etablierung eines einheitlichen  Designs

Die wichtigsten Zeremonien in OTR Projekt

Neben den oben genannten Zeremonien setzen wir agile und leichtgewichtige Ansätze u. a. im PMO-Bereich (Project Management Office) um, zum Beispiel:

• Start small. Wenn wir klein anfangen, ergeben sich Vorteile: Die Kommunikationskanäle sind überschaubar. Mit einem MVP (Minimal Viable Product oder Minimal Viable Prototype) können wir die Komplexität zunächst begrenzen. 
• Die Projektfläche. Wir haben die Entwicklungsteams, Product Owner der IT- und Business-Seite auf einer Projektfläche co-lokiert zusammengezogen und damit eine Umgebung geschaffen, die kurze Wege ermöglicht und auf ideale Weise die Umsetzung von agilen Prinzipien unterstützt (s. [19] zu den Prinzipien “Business people and developers must work together daily throughout the project” und “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”). 
• Laufende Software ist der beste Statusbericht. Alle zwei Wochen laden wir Projektmitglieder und alle vom Fortschritt des Projekts betroffenen Personen zum Showcase ein. Dort präsentieren wir die Arbeit der letzten beiden Wochen. Mittlerweile hat sich dieses Format etabliert und herumgesprochen, sodass wir immer wieder auch interessierte Gäste begrüßen können. Hierdurch konnten wir den Projektstatusbericht auf monatlich zwei Seiten beschränken. 
• Does it make us better or quicker? Die ständige Priorisierung von Initiativen, Epics und User Stories in einem komplexen Umfeld ist eine Herausforderung. Wir nutzen neben unserer Vision, dem Lean Value Tree oder der Roadmap auch die Frage, ob wir schneller oder besser werden können als weiteres Kriterium zur Einschätzung von Prioritäten. 

Umfassende Kundenzentrierung

Auch im Bereich Kundenzentrierung haben wir es mit einem Paradigmenwechsel zu tun. Viele der Product Owner, die wir für OTR gewinnen konnten, haben langjährige Erfahrungen im Verkaufsprozess. Allerdings haben auch einige schon länger nicht mehr mit den zukünftigen Anwendern des Produkts gesprochen oder sogar Kunden von Mercedes-Benz über die Erwartungen und Erfahrungen im Verkaufsprozess gehört. Wird Kundenzentrierung wirklich ernst genommen, müssen Kunden und Anwender von den digitalen Produkten, die wir erstellen, regelmäßig einbezogen und oder besser noch, deren Anwendungsverhalten studiert werden. Dazu müssen Fachexperten und Product Owner jedoch zunächst gelernte Praktiken entlernen und eine neue Demut gegenüber dem Kundenverhalten entwickeln. Product Manager und Product Owner geben nicht mehr alleine das Design und Verhalten der Anwendung vor, sondern nutzen regelmäßig Methoden wie Prototypen, qualitative Interviews oder Beobachtungen (Fly-on-the-wall, s. [22]), um das Anwenderverhalten zu untersuchen. Gerade in der sich mittlerweile immer schneller ändernden Welt der Kundenbedürfnisse ist dies wichtig. 

Interview mit Verkäufern in einer Niederlassung

Dies hat bei unserem OTR Projekts gerade zu Beginn zu vielen Diskussionen geführt und wir konnten auf beiden Seiten dazu lernen. Eine sichere Arbeitsumgebung mit Raum zum Experimentieren und Möglichkeiten, auch Fehler zu machen, hat hierbei geholfen. 

So haben wir beispielsweise damit experimentiert, Beobachtungen von Nutzerverhalten in den Niederlassungen per Videokonferenz in die Entwicklerteams zu streamen. Damit unsere Teamkollegen aus Indien daran teilnehmen konnten, haben wir teilweise mit Simultanübersetzern gearbeitet. Aktuell kommunizieren wir aktiv mit unseren Nutzern über das Daimler Retail Portal, nehmen von dort Verbesserungsvorschläge auf oder geben Feedback zur Nutzung der Anwendung.  

Echtzeitanalyse des Nutzerverhaltens (hier ein Beispiel aus der Testumgebung). Auf der Projektfläche haben wir Monitore mit diesen und weiteren Echtzeitdaten aufgestellt.  

Bereits jetzt, vor dem eigentlichen Rollout der Anwendung, konnten wir datengestützt mithilfe der Monitoring-Systeme das Anwenderverhalten analysieren. Beispielsweise sehen wir, wie häufig neue Features (z. B. die neu geschaffene Möglichkeit, einen frisch konfigurierten Neuwagen mit dem letzten Fahrzeug des Kunden zu vergleichen) genutzt werden. Dies ist ein Bereich, den wir mit dem deutschlandweiten Rollout der Anwendung weiter ausbauen wollen. Dabei ist uns wichtig, auch Business-Metriken zu erfassen und diese den Nutzern und betroffenen Business-Kollegen zugänglich zu machen.    

Aufbau eines Feedback-Ökosystems

Neben der Ablösung des Altsystems ist eines unserer Hauptziele, OTR möglichst flexibel zu gestalten, um auf neue oder sich ändernde Anforderungen der Anwender oder des Marktes reagieren zu können. Darüber hinaus möchten wir vom Anwenderverhalten wie oben beschrieben lernen. Durch die konsequente Umsetzung von Continuous Integration und Continuous Delivery (CI/CD, s. [32]) sind wir nun ständig bereit, Änderungen automatisiert in die Produktionsumgebung zu migrieren. So aktualisieren wir OTR mit durchschnittlich etwa 20 Softwareänderungen täglich. Auch hier spielen wieder mehrere Fähigkeiten zusammen: Methoden des Design Thinkings helfen dabei, innovative Ideen zu erzeugen und bilden die Grundlage, mehrere Alternativen durchspielen zu können (s. [22]). Agile Softwareentwicklung unterstützt ausdrücklich die späte Änderung von Anforderungen und Testautomatisierung und Continuous Delivery erlauben die zügige Umsetzung in wertbringende Software (s. [19] zum Prinzip “Welcome changing requirements, even late in the development. Agile processes harness change for the customer’s competitive advantage)”). 

Weitere Schritte

Mittlerweile offenbaren sich Muster in der Einführung von agilen Methoden und digitalen Transformationen. Ein Vergleich mit Agile Adoption Patterns (s. [8]) zeigt, dass wir uns im OTR Projekt mitten in dieser Transformation befinden. Während wir bereits viele Hürden genommen haben, stehen weitere Schritte, wie die Umstellung auf eine produktzentrierte Organisation, die Einführung von agilen Portfolio Management Methoden (s. Lean and Agile Portfolio Management [40]), die weitere Integration von IT und Business, etc. noch aus. Die bereits erzielten Erfolge ermutigen uns jedoch auf dem eingeschlagenen Weg fortzufahren.  

Referenzen

1. Donald G. Reinertsen: “The Principles of Product Development Flow: Second Generation Lean Product Development”, Celeritas Publishing, Redondo Beach, 2009
2. Nicole Forsgren, Jez Humble und Gene Kim: “Accelerate”, IT Revolution, Portland, 2018 
3. Martin Fowler: “Microservices Prerequisites”, https://martinfowler.com/bliki/MicroservicePrerequisites.html, 2014
4. Eric Ries: “The Lean Startup: How today’s Entrepreneuers use Continuous Innovation”, Crown Business Publishing, New York, 2011
5. Sriram Narayan: “Agile IT Organisation Design – For Digital Transformation and Continuous Delivery”, Addison-Wesley, New York, 2015
6. Mark Schwartz: “A Seat at the Table: IT Leadership in the Age of Agility”, IT Revolution, Portland, 2017
7. Jonny Schneider: “Understanding Design Thinking, Lean, and Agile”, O’Reilly Media, 2017
8. Danny Smith: “Agile Adoption Patterns”, Medium,  https://medium.com/rootpath/agile-adoption-patterns-724fb921945f, 2016
9. Steve Denning: “Understanding Fake Agile”, Forbes Media, https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/#35870f914bbe, 2019
10. Sunil Mundra: “Distributed Development Enablers Part 2: Process”, ThoughtWorks Insights Article, https://www.thoughtworks.com/de/insights/blog/distributed-development-enablers-part-2-process, 2016
11. Wikipedia: “Verlängerte Werkbank” in “Fertigungsbetrieb”, https://de.wikipedia.org/wiki/Fertigungsbetrieb#Verl%C3%A4ngerte_Werkbank
12. McKinsey: “How to create an agile Organisation”, Survey, https://www.mckinsey.com/business-functions/organization/our-insights/how-to-create-an-agile-organization, 2017
13. – gelöscht –
14. 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
15. 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
16. Nassim Nicholas Taleb: “Skin in the Game, Hidden Asymmetries in Daily Life”, Random House, New York, 2018 
17. Martin Fowler: “The State of Agile Software in 2018”, https://martinfowler.com/articles/agile-aus-2018.html, 2018
18. Ron Jeffries: “Dark Scrum”, https://ronjeffries.com/articles/016-09ff/defense/, 2016
19. Agile Manifesto: “Principles behind the Agile Manifesto”, https://agilemanifesto.org/principles.html, 2001
20. Sam Newman: “Building Microservices”, O’Reilly Media, Sebastopol, CA., 2015
21. Torben Stephan, Ludger Schmitz “Interview mit  Vlado Koljibabic, Leiter CASE IT bei Daimler”, Data Center Insider, https://www.datacenter-insider.de/wir-kennen-die-vorteile-von-open-source-a-708188/, 2018
22. Dark Horse Innovation: “Digital Innovation Playbook”, Murmann Publishers, Hamburg, 2017
23. 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
24. ThoughtWorks: “Innovative software development for the sales experience of the future”, https://www.thoughtworks.com/clients/daimler, 2017
25. Wikipedia: “ITIL”, https://en.wikipedia.org/wiki/ITIL
26. Prof. Dr. Roland Eckert: “Warum Daimler auf die Schwarm Organisation setzt”, Springer Professional, https://www.springerprofessional.de/organisationsentwicklung/innovationsmanagement/warum-daimler-auf-die-schwarm-organisation-setzt/12000092, 2017
27. Daniel Kahnemann: “Thinking Fast and Slow”, Farrar, Strauss and Giroux, New York, 2011
28. Wikipedia: “Planning Fallacy”, https://en.wikipedia.org/wiki/Planning_fallacy
29. 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
30. Hermann Vocke: “The practical Test Pyramid”, MartinFowler.com, https://martinfowler.com/articles/practical-test-pyramid.html, 2018
31. Scrum alliance: “Certified Scrum Master”, https://www.scrumalliance.org/get-certified/scrum-master-track/certified-scrummaster?gclid=EAIaIQobChMIuOPj87fh4wIVS7TtCh0xCQV-EAAYBCAAEgJSD_D_BwE
32. Jez Humble and David Farley “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison Wesley, 2011
33. Richard Warr, Matt Shipmann, “Study finds Diversity boosts Innovation in US Companies”, https://news.ncsu.edu/2018/01/diversity-boosts-innovation-2018/, 2018
34. ThoughtWorks, “ThoughtWorks recognized with Daimler Supplier Award 2017”, https://www.thoughtworks.com/news/daimler-suppliers-award17, 2017
35. Frederic Laloux: “Reinventing Organizations, An Illustrated Invitation to Join the Conversations on Next-Stage Organizations”, Nelson Parker, 2016
36. 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
37. Wikipedia: “Arbeitnehmerüberlassungsgesetz”, https://de.wikipedia.org/wiki/Arbeitnehmer%C3%BCberlassungsgesetz
38. Werner Kurzlechner: “Die Lehren aus dem Daimler Urteil”, CIO.de, https://www.cio.de/a/die-lehren-aus-dem-daimler-urteil,2928650, 2013
39. Neil Ford, Rebecca Parsons, Patrick Kua: “Building Evolutionary Architectures: Support Constant Change”, O’Reilly, 2018
40. Dr. Martin Kramer: “Lean and Agile Portfolio Management”, dr-martin-kramer.com,  https://dr-martin-kramer.com/?p=163, 2016
41. Henrik Kniberg: “Spotify Engineering Culture, Part 1”, Crip’s Blog,  https://blog.crisp.se/2014/03/27/henrikkniberg/spotify-engineering-culture-part-1, 2014
42. Kasandra Fcong “Transform Meetings with a Great Information Radiator”, ThoughtWorks,  https://www.thoughtworks.com/de/insights/blog/transform-meetings-great-information-radiator, 2016
43. Jesse Russel Morgan: “Beginner’s Mind in UX Design”, https://uxdesign.cc/beginners-mind-in-ux-design-with-shunryu-suzuki-11a00787c8a9?gi=f923553c2102, 2018
44. Jonathan Rasmusson: “The Agile Samurai: How Agile Masters Deliver Great Software”, The Pragmatic Programmers, 2010
45. Jim Highsmith, Linda Luu, David Robinson: “EDGE Value-Driven Digital Transformation”, Addison-Wesley, 2019 
46. 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
47. Wouter Aghina, Aaron De Smet, Gerald Lackey, Michael Lurie, Monica Murarca, Christopher Handscomp: “The Five Trademarks of Agile Organisations”, McKinsey&Company, https://www.mckinsey.com/business-functions/organization/our-insights/the-five-trademarks-of-agile-organizations, 2018
48. Wikipedia: “Organisational Change Fatigue”, https://en.wikipedia.org/wiki/Organizational_change_fatigue
49. David J. Anderson: “Kanban, Successful Evolutionary Change for Your Technology Business”, Sequim, Washington, 2010
50. Susan Tardanico: “10 Traits of Courageous Leaders”, Forbes, https://www.forbes.com/sites/susantardanico/2013/01/15/10-traits-of-courageous-leaders/#4ed8c9574fc0, 2013
51. Pete Hodgson: ”Feature Toggles (aka Feature Flags)”,  https://www.martinfowler.com/articles/feature-toggles.html, 2017
52. ThoughtWorks: “Das ist unser Office in Berlin”, 2019 https://www.thoughtworks.com/de/locations/berlin
53. Daniel Pink: “A whole new mind: Why right-Brainers will rule the future”, Penguin, New York, 2005
54. Wikipedia: “Cargo Cult Science”, https://en.wikipedia.org/wiki/Cargo_cult_science