Let’s say you have a difficult challenge and need some great, innovative ideas to get through this. Wouldn’t it be nice if you could just snip with your fingers and there you have it, these great new ideas?
This video is about taking creativity from some mysterious magic to a (somehow) predictable process. I will introduce you to the work of Edward de Bono on Lateral Thinking. This helps us to understand better how our brain works and understand why we can become trapped in our own successful thinking.
With the help of a metaphor I will explain different methods on how break out of these thinking prisons. In the end I take these concepts and apply them to brainstorming and provide concrete tips and tricks how to conduct much better brainstorming sessions which will give you more and better ideas.
Jeff Gothelf (siehe u.a. Lean UX), meine Kollegin Sylvia Le Hong und ich erklären in einem Webinar, wie Personal Growth, Cultivation und Digitale Transformation zusammen hängen. Das Webinar (in englisch) wurde von Sabrina Mach moderiert.
Hier geht es zur Aufzeichnung des Webinars auf der ThoughtWorks Seite.
Gerade in der heutigen Zeit kommt es darauf an, schnell auf Veränderungen und neue Chancen reagieren zu können. Ein bewährtes Mittel hierzu ist ein agiles Mindset. Doch wo fängt man an?
Nico Ackermann (Daimler), Sven Dittmer (Daimler) und ich haben in einem Webinar anhand des One Touch Retail Projekts (OTR) aufgezeigt, wie Daimler seine digitale Transformation vorantreibt und welche Paradigmenwechsel hierzu nötig sind.
Wir haben das Webinar aufgezeichnet und stellen es auf der ThoughtWorks Seite zur Verfügung.
Wir hatten mehre hundert Teilnehmer und haben sehr viel positives Feedback hierzu erhalten.
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
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 Anforderungenund 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
Donald G. Reinertsen: “The Principles of Product Development Flow: Second Generation Lean Product Development”, Celeritas Publishing, Redondo Beach, 2009
Nicole Forsgren, Jez Humble und Gene Kim: “Accelerate”, IT Revolution, Portland, 2018
Dark Horse Innovation: “Digital Innovation Playbook”, Murmann Publishers, Hamburg, 2017
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
Den folgenden Beitrag habe ich zusammen mit Martin Milcke (CIO Mercedes-Benz Vertrieb Deutschland) auf dem Insights Blog von ThoughtWorks veröffentlicht.
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:
Von Wasserfall-Methodik zu Agiler Softwareentwicklung
Von Projekt zum Produkt
Von Entwicklung und Betrieb zu DevOps
Von Anforderungsanalyse zu Design Thinking
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
Oiner 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:
Eine radikale Prozessvereinfachung reduziert die Komplexität und die Dopplung von Tätigkeiten, um einfachere Prozesse stärker zu automatisieren.
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.
Geschwindigkeit als strategischen Vorteil nutzen, um beispielsweise durch Continuous Delivery zeitnah Kundenbedürfnisse in den eigenen Produkten umzusetzen.
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
Fon 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. Der zweite Teil erscheint Mitte März.
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, 2017go
Nach meiner Kindheit habe ich aufgehört zu zeichnen. Vor einigen Jahren habe ich mich dann mit Präsentiontechnik beschäftigt: Wie kann man wegkommen von den immer gleichen, langweiligen, überfüllten Powerpoint Slides. Dabei habe ich immer wieder von Visualisierung, von Sketchen gelesen und mir gedacht: „das kann doch nicht, das muss ich doch auch lernen können“. Ich habe dann viele Bücher über Visualisierung gelesen und bin dann zu UZMO gekommen. Ein genialer Name. Geben Sie den doch mal bei Google ein. Oder schauen Sie sich dieses Video des Autors Martin Haussmann an.
Ich habe dann angefangen nach der UZMO-Methode zu visualisieren und bin dann mit etwas Übung am Flipchart, und täglichen Sketchnotes recht schnell zu dem Einäugigen unter den Blinden geworden. Viele meiner Ergebnisse habe ich eingescannt und über die Zeit gesammelt, um sie z.B. schnell in Powerpoint nutzen zu können. Denn nicht immer habe ich die Möglichkeit am Flipchart zu arbeiten. Insbesondere wenn viel remote gearbeitet wird greife ich gerne auf die gesammelten Zeichnungen zurück. Und gerne biete ich Ihnen hier ein Teil meiner Sammlung zum Download und der eigenen Nutzung an. Viel Freude damit!
Traditional portfolio management does not work. Or, let’s say, at least „…any more“. I believe the traditional approach, i.e.
to plan a multiyear roadmap of projects, initiatives or actions
then apply for budget, get the approval and then to commit to the roadmap
then to implement the portfolio
has serious issues in today’s fast paced environment.
In this presentation I will explain my problems with the traditional approach and offer an alternative: Lean and agile portfolio management. For that we taken proven concept from agile software development and apply them to IT program and portfolio management.
I have successfully implemented this approach which allows a portfolio manager to more agile his/her portfolio of IT projects. Moreover, effort for overhead activities is reduced and the process to select potential project ideas becomes leaner.
At the end of the presentation I will also discuss challenges to implement this approach and ideas on how to move ahead.
Ich freue mich, verkünden zu können, dass ich ab Anfang Januar 2017 für ThoughtWorks arbeiten werde. Meine Aufgabe wird sein, als Client Principal das deutsche und speziell Berliner Geschäft weiter zu entwickeln.
In den vergangenen Wochen habe ich mich intensiv mit ThoughtWorks auseinander gesetzt und hatte viele Gespräche und Interviews mit meinen neuen Kollegen. Dabei haben sie mich mit ihrer Leidenschaft für Technologie und Anspruch, die Industrie weiter zu entwickeln begeistert. Daher war ich geehrt und musste nicht lange überlegen, als ich das Angebot von ThoughtWorks erhalten habe.
Ich freue mich nun auf die Feiertage und auf den Start bei ThoughtWorks im Januar.
English Version:
I am very happy to announce that I will be starting to work for ThoughtWorks from beginning of January 2017. As client principal it will be my task to further develop the German and especially Berlin market.
Over the past weeks I have been in contact with ThoughtWorks and they impressed me very much with their passion for technology and their ambition to develop the IT industry. I was therefore honored when I received an offer and quickly accepted it.
Now, I am looking forward to the Christmas break and the start with ThoughtWorks in January.
Haben Sie mal darüber nachgedacht, einen Podcast nicht nur für Werbezwecke also z.B. mehr Traffic auf Ihrer Web-Site zu nutzen sondern einen Podcast für Ihre Mitarbeiter zu erstellen? In diesem Podcast möchte Ihnen nun erklären,
warum das eine lohnende Sache sein kann,
wann so ein interner Podcast sinnvoll ist und
wie man einen solchen Podcast erstellt.
Dafür habe ich selbst das Format eines Podcasts gewählt. Ich habe Erfahrung damit, einen firmeninternen Podcast zu erstellen. Und gerne helfe Ihnen dabei selbst einen solche Podcast zu erstellen. Wenn dies für Sie interessant ist kontaktieren Sie mich.
Ein Podcast hat interessante Eigenschaften, die ihn ideal für einen neuen, kosteneffizienten internen Kommunikationskanal machen. In diesem Podcast erkläre ich Ihnen und stelle Ihnen en Detail vor, wie Sie ihren eigenen Podcast für Ihre Mitarbeiter planen, produzieren und verteilen.
Inhalt
Intro
Was sind die Vorteile eines firmeninternen Podcasts?
Wie bereite ich einen Podcast vor?
Welches technisches Equipment benötige ich?
Wie führe ich das Interview?
Welche Software benötige ich für die Nachbereitung?
Welche Filter und Kompressoren benötige ich und in welcher Reihenfolge werden diese geschaltet?
Wie publiziere ich den internen Podcast?
Notizen und Links
Im Podcast stelle ich weitere Podcasts und technisches Equipment vor. Hier finden Sie die Links hierzu:
Meine Dissertation habe ich zum Thema „Integrated Simulation“ geschrieben. Mit Dr. Ingo Meents zusammen habe ich die erste Gemeinschaftsdissertation der TU Clausthal verfasst.
Die Dissertation wurde mit dem Förderpreis Freunde der TU Clausthal ausgezeichnet. Die Laudation hielt Ekkehard Schulz (seinerzeit Vorstandsvorsitzender der ThyssenKrupp AG).
Hier finden Sie weitere Informationen zu EPOS und der Dissertation:
Die Analyse von Warteschlangenmodellen zur Beantwortung von Fragen der taktischen Produktionsplanung für große und komplexe
Fertigungssysteme ist nicht ohne unterstützende IT Systeme
möglich. Die bekannten mathematischen Modelle liefern
Approximationen der Leistungsgrößen wie z. B. Auslastung, Bestände und Durchlaufzeiten. Das Erstellen und Warten der benötigten Warteschlangenmodelle für hunderte von Arbeitsstationen, tausende von Arbeitsfolgen, die durch komplexe Prozessflüsse verbunden werden, stellt jedoch eine Herausforderung dar. Das Modell der Integrierten Simulation ist der theoretische Hintergrund für die Erstellung von Software-Systemen, die eine effiziente Erstellung und Wartung von großen Modellen mit Hilfe von verteilten Verantwortlichkeiten ermöglichen. Integrierte Simulation beschreibt den Import von Daten aus Liniensteuerungssystemen und die automatische Erstellung von Warteschlangenmodellen aus Datenbanken, die alle zur Planung relevanten Daten enthalten. Die Automatisierung der Informationsbeschaffung, die Analyse der Warteschlangenmodelle und ein automatisiertes Berichtswesen ermöglichen die fortlaufende Unterstützung der Planungsprozesse – selbst in sich ständig ändernden Produktionsumgebungen.
Simulation und analytische Leistungsbewertung erlauben die
Untersuchung von a priori definierten Szenarien. Um verbesserte
oder sogar optimale Parametersätze finden zu können, werden
Optimierungsmethoden, die automatisch generierte Modelle nutzen können, vorgestellt. Drei unterschiedliche Probleme und die
zugehörigen Lösungsansätze werden untersucht. Zunächst wird das
Problem des optimalen Produkt-Mixes um die Anforderungen der
Integrierten Simulation erweitert. Weiterhin wird ein quadratisches Programm zur Bestimmung der optimalen Routing-Wahrscheinlichkeiten, die bei der Modellgenerierung nicht
bestimmt werden, formal hergeleitet. Schließlich werden
evolutionäre Algorithmen, die die Leistungsgrößen der
Warteschlangenmodelle als Einschränkungen oder Zielgrößen
verwenden, entwickelt.
Wenn Simulation als fortlaufender Prozess in der Produktionsplanung angewendet wird, erlaubt die Integration mit vorhandenen Liniensteuerungssystemen die Erstellung von operationalen Plänen, Problemerkennungssystemen und eine systematische Validierung der verwendeten Simulationsmodelle. Anwendungen entstehen aus dem Vergleich von gemessenen Leistungsgrößen und den aus der Simulation abgeleiteten Produktionszielen. Dabei müssen statistische Tests, die sich durch Qualitätsregelkarten visualisieren lassen, verwendet werden. Probleme ergeben sich aus der Autokorrelation in den betrachteten logistischen Prozessen sowie der Anzahl der möglichen Karten. Als weitere Anwendung der Integration mit Liniensteuerungssytemen wird eine Vorwärtspropagierung der aktuellen Bestände auf Basis der approximierten Restdurchlaufzeiten vorgestellt.
Um die Anwendbarkeit der vorgeschlagenen Architektur und
Algorithmen in der Praxis zu untersuchen, wurde ein System, das
mittlerweile zur Simulation von fünf Produktionslinien der IBM
Deutschland Speichersysteme GmbH an drei internationalen
Lokationen verwendet wird, entwickelt. Es hat sich gezeigt, dass
erst der vorgeschlagene ganzheitliche Ansatz, d.h. die Integration
aller benötigten Prozesse, eine erfolgreiche Anwendung der
analytischen Leistungsbewertung bei realen Problemstellungen
ermöglicht.
Meine Dissertation habe ich zum Thema „Integrated Simulation“ geschrieben. Mit Dr. Ingo Meents zusammen habe ich die erste Gemeinschaftsdissertation der TU Clausthal verfasst.