Let’s rock IThttp://creativecommons.org/licenses/by-sa/4.0/Björn Schotte - bjoern.schotte@mayflower.de

Denkwerkzeuge für moderne Organisation & IT

Willkommen zum Talk Let’s Rock IT - wie die IT vom Supporter zum Enabler wird.

Ich möchte aufzeigen, warum in Zeiten hoher Dynamik Unternehmens-Strukturen kaputt sind und wie Unternehmen auf der Online-Welle reiten können, um auch Morgen noch eine Rolle zu spielen.

„Digitale Transformation“ ist das - meist inhaltsleere - Buzzword. Hier erfahrt Ihr, was eine moderne IT/Software-Entwicklung ausmacht. Wie Ihr Silos vermeidet und zu einer guten Zusammenarbeit mit anderen Unternehmensbereichen kommt. Und welche Denkwerkzeuge nützlich sein können, um Eure Organisation zu modernisieren.

Natürlich erhebe ich in diesem Talk keinen Anspruch auf Vollständigkeit. Praktischerweise werden die Folien regelmäßig erweitert werden. ;-) Die Folien stehen unter Creative Commons License, das PDF könnt Ihr Euch gerne downloaden und weiter verteilen.

Und nun: Anschnallen & los geht’s!

Hallo, ich bin Björn. #agile #software #delivery #consulting #discovery #leanstartup #coaching

Wir lösen harte IT-Probleme.

https://mayflower.de/

Hallo, ich bin Björn Schotte. Geschäftsführer und Señor Consultant bei MAYFLOWER. Mit unseren cross-funktionalen Teams realisieren wir digitale Produkte und lösen harte IT-Probleme für unsere Kunden. Meine Themen sind dabei Agile Software Delivery, Consulting, Product/Feature Discovery, Lean Startup für Enterprises und Agiles (Management) Coaching.

Was treibt Euch Manager um?

Wann wird unsere IT endlich schneller?

Wieso machen die Entwickler nicht das

was ich will?

Auf welchem Kanal finde ich nun

meine Kunden?

Was will mein Kunde?

Wie halten wir die Konkurrenz auf

Abstand?

Die Zusammenarbeit

mit den Abteilungen klappt nicht!

80% unseres Budgets geht auf

„Run the Business“

„Change the Business“ WTF?

In der Vorbereitung für diesen Talk bin ich all die Gespräche durchgegangen, die ich mit zahlreichen Managern und C-level Executives geführt habe. Die wichtigsten Fragestellungen, die das Management umtreibt, versuche ich hier zu destillieren. Besonderes Augenmerk legen Manager darauf, wieviel Prozent des IT-Budgets für „run the business“ drauf geht und wieviel Prozent des Budgets für echte Innovationen, also „Change the Business“, übrig bleibt. Leider ist dies häufig in einem ungünstigen Verhältnis - der größte Teil des IT-Budgets geht für „Run the Business“ drauf.

Was treibt Euch Developer um?

Alle reden von Continuous

Deployment :-(

Diese tausend PDF-Dokumente mit

versteckten Anforderungen

Kann die Agentur das Design

mal pünktlich liefern?

Warum muss $manager sich

immer einmischen?

Wieso müssen wir hier unsinnige Dinge

tun?

Würde gerne mal technical debt

verringern

Diese blöde Maintenance von

altem Code

Die Leute aus dem Marketing verstehen uns

nicht

Auch Entwickler haben eine ganze Menge Fragen in Zeiten hoher Dynamik. Da ist zum Einen der Eindruck, das Management mische sich zu häufig ein. Manchmal findet sich auch der Eindruck wieder, die Entwickler müssten Dinge tun, die aus ihrer Sicht total unsinnig sind. Wie so häufig haben wir hier ein Kommunikationsproblem. Technisch spannend wird es, wenn weitere Dienstleister wie zB Design-Zulieferer eingebunden sind. Arbeitet das Entwicklungs-Team nach agilen Prinzipien & Praktiken, so ist es schwierig, dies mit der „tayloristischen“ Zerteilung der Arbeitspakete durch das Management zu vereinbaren - und so sind Design-Agenturen abgekoppelt von den Sprints und geliefert wird dann meist etwas, was nicht mehr benötigt wird oder so viel Änderung erfährt (iterativ), dass ein permanentes „Mitlaufen“ der Designer in den Sprints angebrachter gewesen wäre. Viel nerviger ist es für Entwickler, wenn keine vernünftige Continuous Deployment/Delivery Infrastruktur zur Verfügung steht oder gar von Product Owner oder Stakeholder Seite nicht gewünscht wird. Liebe Manager, Euch entgeht hiermit die Infrastruktur für frühzeitige Lern-Möglichkeiten in Eurem Markt!

Managers Antwort „Lasst uns Agil

arbeiten!“

Sicher, auch wir Manager besuchen Konferenzen oder lesen schlaue Bücher. Daher sind wir der Meinung, dass es doch super praktisch ist, wenn wir jetzt alle Agil arbeiten. Schließlich bedeutet das doch, dass wir die Dinge schneller und zu kleineren Kosten bekommen, nicht wahr?

Scrum funktioniert nicht.(Die Organisation ist im Weg)

Ich stelle die Behauptung auf, dass Scrum nicht funktioniert. Warum ich das mache? Weil ich durch die vielen Gespräche und Einblicke in Unternehmen den Eindruck habe, dass die Organisation in ihrer Summe aus Kultur und DNA einem erfolgreichen Anwenden von Agilen Prinzipien und Praktiken im Wege steht. Oder anders ausgedrückt: um das volle Potenzial heben zu können, benötigt es eine andere Geisteshaltung.

Alle reden von Komplexität und

Dynamik?

In vielen Vorträgen hört man immer wieder von Komplexität und hoher Dynamik. Ich will keine weitere Erklärungsschleife drehen, sondern eher ergründen, wie es denn zu dieser hohen Komplexität und dieser hohen Dynamik gekommen ist …

3 Gründe für hohe (Markt-)Dynamik

… also lasst uns ergründen, warum es eine hohe Dynamik insgesamt und an den Märkten, an denen Ihr tätig seid, gibt. Ach, und bevor Ihr jetzt sagt „Also bei uns nicht, wir sind doch (B2B | whatever)! *abwink*“, möchte ich mit Steve Jobs antworten: „You cannot connect the dots forward, you can only connect them backwards“.

#1 5,5 Mrd. Menschen

haben ein Smartphone Prognose 2020, 8 Mrd. Weltbevölkerung

http://ben-evans.com/benedictevans/2016/3/29/presentation-mobile-ate-the-world

Einer der wichtigsten Gründe ist die Tatsache, dass das Internet so richtig abhebt. 1994, als ich mit dem Internet begonnen habe, da gab es nur das popelige 19,2kBit Modem. Nach Ende des DotCom Crashs ist jedoch die Zahl der Menschen, die einen Internet-Zugang haben, stark gestiegen. In den vergangenen Jahren haben wir es mit einem exponentiellen Anstieg zu tun. Dieser wurde ausgelöst durch die Revolution des Smartphones.

Von Benedict Evans, Partner bei Andreessen Horowitz (Marc Andreessen erfand den ersten Internet-Browser Netscape), gibt es eine schöne Prognose zur mobile Nutzung in der Weltbevölkerung. Sein Fazit: „Mobile ate the world“ (angelehnt an Marcs Bonmot „Software is eating the world“). Im Jahr 2020 werden bei einer Gesamtbevölkerung von 8 Mrd. Menschen etwa 5,5 Mrd. Menschen über ein internet-fähiges Smartphone verfügen.

Phew!

#2 Konsumenten sind mündig, fluide im Kanal und lassen

sich nicht mehr beeinflussen

Der zweite Grund liegt an uns, den Konsumenten: wir treffen heutzutage souverän Einkaufsentscheidungen und nutzen das Internet aktiv, um Kaufentscheidungen vorzubereiten. Schon seit 1999, als das Cluetrain Manifest veröffentlicht wurde, war klar, dass Konsumenten sich nicht mehr steuern oder gar beeinflussen lassen (wollen). Das wiederum ist ein Grund, warum wir Unternehmen umdenken müssen und platte PR schon seit langem nicht mehr so gut funktioniert.

Gleichzeitig agiert der Kunde „kanalübergreifend“. Wenn ich mich selbst aus der Rolle des Konsumenten betrachte, dann muss ich Euch sagen, dass es für mich gar keine „Kanäle“ gibt. Ich achte da nicht drauf. Wenn ich irgendwo unterwegs bin und Zeit habe, dann öffne ich auf meinem Smartphone vielleicht die Amazon-App und packe dort einen Artikel in den Warenkorb. Komme ich ins Büro, öffne ich amazon.de im Browser und shoppe weiter meinen Warenkorb voll. Und Abends, auf der Couch, nehme ich mein Tablet zur Hand, wahlweise mal mit dem Browser oder mit der App, shoppe kurz weiter und mache schlussendlich den Checkout.

Und wer weiß, vielleicht bestellt der Konsument morgen schon über Apps, die in den Facebook Messenger integriert sind?

#3 Softwareentwicklung ist

komplex(no Cynefin attached)

Viele Manager denken, Softwareentwicklung sei doch ganz einfach. Wenn wir im Cynefin System-Modell denken, dann findet Softwareentwicklung jedoch im Bereich der „unordered domain“ statt, also meist im komplexen oder chaotischen Feld („chaotisch“ hat hier nichts mit der landläufigen Meinung von „unüberlegt = doof“ zu tun).

Ich will das hier nicht weiter ausführen, schließlich ist dies ein „Advanced“ Talk, und das Cynefin Diagramm wird schon zu genüge in praktisch jedem agilen Talk aufgelegt ;-) Lasst es uns einfach als gegeben hinnehmen …

Liebe Unternehmen, Eure Organisations-Strukturen sind kaputt.

All dies sagt mir, liebe Unternehmen, dass Eure Organisations-Strukturen kaputt sind. Weil sie nicht zu dem passen, wie die Welt da draussen schon seit einiger Zeit ist. Wir haben hohe Marktdynamiken, eine massive Verlagerung von Themen in das Internet, nicht mehr steuerbare Kunden und Anforderungen an Software, die dadurch immer komplexer wird. Die Strukturen, die Ihr in Eurer Organisation habt, passen dazu nicht mehr. Deswegen fällt es Euch vielleicht auch schwer, diesen ganzen modernen „heißen Schei*“ wie Scrum gut zu nutzen - viele haben das Gefühl „das ist doof, weil bei uns hat das nicht funktioniert“.

Mein Denkanstoß an Euch: vielleicht funktioniert die Anwendung nicht, weil Euer System nicht (mehr) dazu passt.

Denkwerkzeuge

Ich habe für Euch keine „einzige, einmalige Lösung“ parat. Das geht auch nicht, weil jede Organisation anders tickt. In den Workshops und Consultings, die ich mit Organisationen durchführe, kommt es mehr auf die Beobachtung an. Und auf passende „Denkwerkzeuge“, die helfen können, das (Organisations-)System zu besser zu beobachten, zu verstehen und Veränderung zu ermöglichen.

Einige dieser Denkwerkzeuge habe ich Euch mitgebracht. Lasst uns mal reinschauen, was so alles drin ist.

IT = UnterstützungCore

Schauen wir uns einmal an, was häufig im BWL-Umfeld gelehrt wird, nach Porter: dort wird die IT (Technologie-Entwicklung) bei den Unterstützungsaktivitäten eingeordnet, hingegen Logistik, Produktion, Marketing & Vertrieb sowie als Service als Primäraktivitäten, die letzten Endes zur Marge beitragen.

Heutzutage ist es aber tatsächlich umgekehrt: wenn der Konsument überwiegend Online-„Kanäle“ dazu nutzt, um sich zu informieren, Einkaufsentscheidungen zu treffen und Einzukaufen, dann ist die Software und damit die IT ein primäres Merkmal dessen, was entscheidend dazu beiträgt, dass gekauft wird.

Mit anderen Worten: die bisherige, vorherrschende Ansicht, dass IT nur eine unterstützende Aktivität ist (und damit auch eher ein „Cost Center“), ist völlig überholt.

Unternehmen, die so denken, werden in der Marktdynamik und den Anforderungen der Konsumenten nicht bestehen können. Es braucht also eine Abkehr der Kosten-Denke in Bezug auf IT als „unterstützende Aktivität“, hin zu IT als zentrale Aktivität.

Im E-Commerce Umfeld kennt man das ganz klar von den Online Pure Playern, die den etablierten Anbietern das Wasser abgraben. Warum ist das so? Weil IT ein Kern ihrer DNA in der Organisation ist, und sie nicht so denken, wie hier zur Schau gestellt.

Ich sage immer salopp: „Amazon ist eigentlich ein IT-Unternehmen, das nebenbei noch ein paar Millionen Produkte verkauft“

Bimodale IT

Ein weiteres Denkwerkzeug, nämlich als Anti-Pattern, ist die sogenannte „Bimodale IT“, die uns Gartner seit einigen Jahren einreden will. Ich sage dazu nur: „Bimodale IT sind die Stützrädchen im Argumentationskasten des CIOs“, damit er eine Denkrichtung hat, um sowohl die schwerfälligen internen IT-Systeme zu rechtfertigen als auch eine Möglichkeit im Unternehmen zu haben, an einigen Stellen „schneller“ und „agiler“ zu arbeiten. Forrester hat das mittlerweile als Anti-Pattern erkannt und versucht nun, uns das - zum Glück - wieder auszureden.

Mein Gedankengang, und damit das Denkwerkzeug, ist jedoch ein anderer: wenn wir anerkennen, dass Agilität viel mehr eine Geisteshaltung (Prinzipien und Praktiken) ist und weniger der „Kauf“ von Methoden wie Scrum, dann verhindern wir die Etablierung dieser Geisteshaltung durch das Offenhalten der „bimodalen IT“. Schließlich ist doch nicht einzusehen, warum der „langsamere Teil“ in der Bimodalen IT nicht auch von agiler Geisteshaltung profitieren könnte. Oder?

Alle Firmen werden zu Software-Firmen

www.cio.de/a/digitale-transformation-laesst-keinen-stein-auf-dem-anderen,3231493

Ihr erinnert Euch noch an mein saloppes „Amazon ist eigentlich ein IT-Unternehmen, das nebenher Waren verkauft“? Im Zuge des Oberbegriffs der digitalen Transformation hat das CIO Magazin ein Statement gebracht, das ich bezeichnend finde: alle Firmen werden zu Software-Firmen.

„Und was daran ist das Denkwerkzeug“? Mein Denkwerkzeug ist die logische Herleitung aus all dem, was wir in den vergangenen Folien gesehen haben. Wir wissen, dass Märkte an Dynamik hinzugewinnen. Dass kein Stein mehr auf dem anderen bleibt. Wir wissen, dass der Konsument flexibler und anspruchsvoller geworden ist - schließlich ist DEIN Mitbewerb für den Konsumenten oftmals nur wenige Mausklicks entfernt.

Als Organisation müssen wir darauf also eine Antwort haben. Unsere Ankerpunkte, ausgedrückt durch den berechenbaren Konsumenten und das in den Markt gedrückte Angebot, gibt es in dieser Form nicht mehr. Stattdessen gibt es die „wave of uncertainty“, die wir reiten müssen.

Am besten gelingt dies uns als Organisation in Form von Digitalem Brennstoff, denn Software können wir flexibel anpassen. Unsere Produkte mögen heute noch zB Hardware sein, doch das befriedigt den Kunden nicht mehr. Für viele Unternehmen ist zusätzliche Software als „digitaler Service“ ein Unterscheidungsmerkmal, um im Geschäft bleiben zu können. Andere - die „Pure Player“ - setzen gleich direkt auf digitale Produkte.

Daher wächst der Anteil an Software in der „Fertigung“, um mal mit dem klassischen Produktions-Sprech zu antworten. Der Sog entsteht dabei durch den Konsumenten und die „Infrastruktur“ des Marktes, die global ist. Wer morgen noch mitspielen möchte, muss darauf eine Antwort haben. Online Pure Player haben eine „digitale Fertigungstiefe“ von 100%.

Daher werden alle Firmen zu Software-Firmen. Endgame. Jetzt ist es an der Zeit, gut aufgestellt zu sein. Und das bedeutet, dass deine Organisations-DNA in der Lage sein muss, Software zu produzieren (oder produzieren zu lassen). Und vor allem: Verständnis dafür zu entwickeln, wie das Software-Business funktioniert.

Tight social cohesion vs

Innovationsfähigkeit

Wo wir gerade bei Innovationsfähigkeit waren: die „social cohesion“ eines Systems, also der soziale Zusammenhalt zB in einer Organisation, hat eine gewisse „Enge“. Man kann feststellen, dass Systeme, die einen sehr engen sozialen Zusammenhalt haben, über eine geringe Innovationsfähigkeit verfügen. Eine hohe Enge erkennt man zB daran, dass es im sozialen System strenge (implizite) Aufnahmekriterien gibt. Oder dass es explizite Bezeichnungen für die Mitarbeiter gibt, die man vielleicht sogar sein ganzes Leben lang behält, selbst wenn man dort nicht mehr arbeitet.

Eine zu starke „social cohesion“ ist also eher schädlich für die Innovationsfähigkeit einer Organisation. Ist sie extrem, so entsteht ein Kult.

Conway’s Law

Conway’s Law stammt von einem Informatiker und besagt im Wesentlichen: Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.

Das bedeutet also für Eure Software-Entwicklung, dass Kommunikationsstrukturen Eurer Organisation sich in der Software wiederfinden, die Ihr baut. Ihr dürft jetzt gerne selber darüber nachdenken, wie das zB in einer hierarchischen Organisation mit starren Entscheidungswegen so läuft und was das für Vor- und Nachteile auf die Software hat. ;-)

Mein Denkwerkzeug an dieser Stelle ist: wenn ich Conway’s Law als gegeben hinnehme, wie muss ich dann die (Kommunikations-/Entscheidungs-)Struktur in meiner Organisation verändern, um eine gute Software bauen zu können - vielleicht sogar agil, durch kleine, inhaltlich autonom arbeitende Teams?

Oder anders gesagt: wie gut kann ich Agile Prinzipien (cross-funktionales Produkt-Team, PO der das „Was“ bestimmt, Devteam dass sich eigenständig um das „Wie“ kümmert) überhaupt in meiner Organisation anwenden, wenn ich diese durch „Conways Brille“ betrachte?

Inspect & Adapt Good Enough

BWLer so: §$!“$!!!

Im Agilen Umfeld gibt es zwei Leitbilder, die BWLern und Controllern grauslig und schwer verständlich vorkommen, jedoch ein gutes Denkwerkzeug sind, um Software sinnvoll zu entwickeln: Inspect & Adapt geht einher mit der Erkenntnis, dass wir uns in der „unordered domain“ von komplex befinden und Prinzipien benötigen, um diese unordered domain handhaben zu können. Wenn wir also schrittweise arbeiten, dabei beobachten und uns immer wieder anpassen, werden wir am Ende erfolgreicher sein, als alles vorherzubestimmen - um dann am Ende als BWLer enttäuscht zu werden, weil der große Plan nicht passte.

„good enough“ bedeutet, dass ich akzeptiere dass es auf dem Weg Veränderung geben wird. Ich also nicht in einer hohen Detail-Tiefe alles vorab planen will, weil sich das nicht lohnt. Daher will ich den sweet spot finden - und dafür ist das Leitbild „good enough“ hilfreich.

Wieviel „good enough“ bei dir, in deiner Organisation oder deinem Software-Team bedeutet? Tja, das kannst du nur für dich selbst herausfinden. Und wirst es vermutlich gemäß „Inspect & Adapt“ immer wieder anpassen :-)

Yeah! Wasserfall!

Konzept Design Implementation

Wir arbeiten nach Agil

Wir arbeiten nach Agil

Wir arbeiten nach Agil

Als Dienstleister, sowohl in Umsetzung als auch Beratung tätig, kommen wir viel herum. Blöderweise begegnet uns dabei diese gezeigte „Realität“ oft genug. Eine Initiative/Projekt wird, ganz in tayloristischer Manier, in einzelne Bestandteile zerlegt. Für die Konzeption wird ein Spezialist eingekauft, für Design noch ein anderer, und das Ergebnis des Designs wird dann an den Dienstleister, der für die Implementation zuständig ist, weiter gegeben.

Das Management, das die Initiative/Projekt verantwortet, geht dabei aus, dass alles agil abläuft. Schließlich arbeiten die einzelnen Dienstleister ja für die Teilbereiche agil. Super Sache!

Du siehst den Fehler? Durch die „Gewaltenteilung“ entsteht ein Scrummerfall: einzelne Teilbereiche, die in sich angeblich agil (nach Scrum) abgearbeitet werden, bei der Betrachtung durch die Makro-Brille aber eher wie ein Wasserfall erscheinen.

Dein Denkwerkzeug ist also, genau hinzusehen und mit etwas Abstand auf die Vorgehensweise zu schauen. Wenn du wirklich nach agilen Prinzipien arbeiten willst, dann sind alle drei Bereiche ineinander integriert, Design vielleicht gar nicht mehr notwendig (weil du Devs hast, die CSS3/HTML5 können und im Team einen UXer haben), und das Team arbeitet als echtes cross-funktionales Team, das alle Fähigkeiten und Fertigkeiten enthält, um von Konzeption bis hin zur Implementation und Betrieb alles abzudecken.

Du kennst den Amazon-Leitspruch? „You build it, you run it.“ …

DevProductSupportSecBizOpsSilos einreissen

Und was ist mit Marketing?

A propos „You build it, you run it“… wo wir gerade beim Einreissen von Silos sind. Deswegen gibt es die DevOps Kultur, weil die früher Trennung zwischen „Development wirft den Ops was über den Zaun und die kümmern sich darum“ als veraltet und überholt gilt.

Das Denkwerkzeug an dieser Stelle ist: du willst im Team alle Fähigkeiten und Fertigkeiten haben, um das (Teil-)Produkt eigenständig entwickeln zu können. Und das bedeutet, dass du neben Entwicklung auch Product, Support, Security, Business Analyse, Ops etc. als Fähigkeiten & Fertigkeiten im Team hast.

Und bei größeren Produkten helfen Dir zB Microservices, um dennoch kleine autonome Teams zu ermöglichen und trotzdem in der Technik ohne Abhängigkeiten arbeiten zu können.

5 Phasen nach Tuckman

https://mercureaace2013.files.wordpress.com/2013/01/groupstages.png

Wir haben jetzt schon einiges über Teams gehört. Mir begegnen oftmals Organisationen, die Teams regelmäßig zusammenstellen und nach Projektende wieder auseinander reissen. Vor einigen Jahren war das sogar mal ein ganzer Trend, der in der BWL-Controller-orientierten Welt en vogue war („für ein Projekt die Experten zusammenstellen, die es für diese Aufgabe braucht“).

Das Problem im komplexen Umfeld der Software-Entwicklung dabei ist, dass Teams, die regelmäßig neu zusammengestellt werden, Schwierigkeiten haben, zu echter Performance zu finden.

Das Denkwerkzeug, das Dir dabei helfen könnte, sind die 5 Teamphasen nach Tuckman. Danach durchläuft ein Team verschiedene Phasen, bis es zu echter Performance findet. Reisst du ein „Team“ jedoch nach Projektende auseinander und stellst für ein neues Projekt ein neues Team zusammen, so fängt dies jedes Mal wieder in den Phasen von vorne an, insbesondere wenn die Team-Mitglieder noch nie so richtig zusammen gearbeitet haben. Haben sie zuvor zusammengearbeitet, ist es vermutlich einfacher, jedoch wird es immer kurzfristig zu Einbußen kommen. Das passiert auch, wenn du ein Team punktuell um weitere Leute ergänzt, die möglicherweise nicht dauerhaft im Team verbleiben. Bei Erweiterung muss sehr genau abgewogen werden, wie du vorgehst.

Was ist also effektiver? Die Arbeit durch ein bestehendes Team durchfließen zu lassen. Damit gibst du dem Team die Möglichkeit, eine Teamkultur zu entwickeln und zu echter Performance zu finden.

Doch das heisst nicht, dass alles optimal läuft …

Stabile Teams VS

Group Think Effect

… denn ein stabiles Team kann auch Nachteile bekommen, und damit sind wir schon beim nächsten Denkwerkzeug.

In der Psychologie gibt es den Group Think Effect. In Wikipedia lesen wir: „Gruppendenken ist ein Prozess, bei dem eine Gruppe von an sich kompetenten Personen schlechtere oder realitätsfernere Entscheidungen als möglich trifft, weil jede beteiligte Person ihre eigene Meinung an die erwartete Gruppenmeinung anpasst. Daraus können Situationen entstehen, bei denen die Gruppe Handlungen oder Kompromissen zustimmt, die jedes einzelne Gruppenmitglied unter normalen Umständen ablehnen würde.“

Darüber hinaus ist manches Team, das über einen starken Zusammenhalt verfügt, „blind“ für an sich gute Ideen und Impulse von außen.

Was kann hier getan werden? Manchmal hilft hier nur eine gezielte Intervention, um das Team darauf aufmerksam zu machen, dass es dem Group Think Effect unterliegt. Dies kann eher von außen passieren, da das Team von innen gar kein Bewußtsein darüber hat, dass es diesem Group Think Effect unterliegt.

Die Folgen davon: Irrationalität, Dogma, fehlendes kritisches, hinterfragendes Denken.

Flexibilität & Speed VS

Zentralität

Wer kennt sie nicht, die zentrale IT? Die vielleicht sogar einen Katalog herausgibt von Technologien, die „zertifiziert“ sind und eingesetzt werden dürfen?

Mein Denkwerkzeug hierbei: Zentralität kommt nur zu einem Preis. Der Preis ist der der fehlenden Flexibilität und Geschwindigkeit. Dieses steht im Widerspruch zu dem, wie der Markt da draussen mittlerweile funktioniert, denn er ist zum Taktgeber geworden. Überall dort, wo du diesen Sog hast, aber dennoch zentrale Entscheidungen hast, wirst du an Flexibilität und Geschwindigkeit verlieren. Dies kann dich deine Innovationskraft kosten, da du nicht dem mit dem Takt des Marktes mitgehen kannst.

Lässt sich beides vereinen? Lass uns mal schauen …

Makro-Architektur

… ein Ausweg könnte eine „Makro-Architektur“ in Form von Prinzipien sein. Repräsentanten aus einzelnen Teams treffen sich regelmäßig, zum Beispiel in einer „Community of Practice“, und besprechen Makro-Prinzipien, wie die Architektur im Produkt oder den Produkten sein sollte. Das könnte zum Beispiel so etwas wie „ReSTful Services, self-contained systems, freie Wahl der Programmiersprache, freie Wahl der Datenbank“ etc. sein. Diese Makro-Architektur bewegt sich regelmäßig und wird aktualisiert.

„Und wo ist nun die zentrale IT, die mitredet?“ - tja …

;-)

Was möchtest Du: lieber die rote Softwarepille oder lieber die blaue? Du brauchst keine Sorge zu haben, dass mit einer Flexibilisierung im Einsatz vom Technologien Nachteile einhergehen. Wenn du das Prinzip des „you build it, you run it“ beherzigst, also viel Know-how inkl „Betrieb“ im Produktentwicklungs-Team ist und damit auch eine Verantwortung im Team, dann wirst du die Welle des Marktes sehr gut mitreiten können, und damit auch Morgen noch eine Rolle im Business spielen.

Lake Wobegon Effect

Ein weiteres Denkwerkzeug ist der sogenannte Lake Wobegon Effect. Der geht in etwa so: wenn du in einem Raum voller Software-Entwickler fragst, wer sich für einen überdurchschnittlich kompetenten Entwickler hält, werden etwa 80% der Leute sich melden. :-)

Natürlich wissen wir, dass das vermutlich eher nicht der Fall sein wird. Jedoch das Bewusstsein darüber, dass es diesen Effekt gibt, hilft uns schon für die Einordnung im Selbst- und Fremdbild.

Señor Developer IT Architect

Lead Developer Head of BlahBlah

Wir bei Mayflower haben die Positionen nach innen so ziemlich aufgegeben. Schließlich ist nicht einzusehen, warum die Software-Architektur ausschließlich vom Architekten im Team kommen sollte. Wie wir wissen, entsteht die beste Architektur einer Software emergent aus dem ganzen Team heraus.

Und auch der „Junior“ Developer hat sicherlich auch gute Ideen, die vielleicht ein Señor Developer nicht hat. Stell dir vor, jemand hat die Position des Architekten: das Team wird unbewusst immer dem Architekten folgen, auch wenn es selbst eigene Ideen hat.

Daher denkt lieber in Rollen. Die können auch mal wechseln. Wenn mehrere Projekte durch das Team nacheinander fliessen, dann wird es je nach Projekt auch unterschiedlich benötigte Rollen geben. Somit hast Du also viel flexiblere Entwicklungsmöglichkeiten für die Menschen im Produkt-Team. Und ja, natürlich kann es Spezial-Ausprägungen bei einzelnen Personen im Team geben. Es gibt also sicherlich den Einen, der mehr Know-how im Bereich Architektur hat als andere im Team. Er wird jedoch mehr die Rolle eines Coachs und Mentors einnehmen als die Rolle desjenigen, der alleine die Architektur festlegt.

TDamit das alles gut funktioniert, benötigst du als Denkwerkzeug den Begriff „T-shaped“. T-shaped bezeichnet eine Einordnung von Kompetenzen eines Developers (oder allgemein eines Wissensarbeiters) auf zwei Achsen:

Auf der vertikalen Achse sind 1-2 Kernkompetenzen zu finden, also beispielsweise eine Programmiersprache wie JavaScript und/oder PHP. Auf der horizontalen Achse sammelt die Person über die Zeit weitere Kompetenzen an, wie zB NodeJS, HTML5/CSS3, das Schreiben von guten Texten oder Projektmanagement-Kompetenz. Die Person wird damit also zum flexiblen Wissensarbeiter, und ist damit viel viel besser in einem Team einsetzbar als ein einsamer Spezialist es wäre. Denn am Ende kommt es bei echter Teamarbeit auf die Effektivität des Gesamt-Teams an, und weniger auf die Einzel-Expertise einzelner Personen.

FAIL-Kultur First Attempt In Learning

Damit alles gut klappt, braucht es die berühmt-berüchtigte Fehler-Kultur, von der immer Alle sprechen.

Vielleicht hilft Dir als Denkwerkzeug, wenn Du Dir „FAIL“ als Akronym für „First Attempt In Learning“ vorstellst: ein Fehler ist die erste Gelegenheit, um hinzuzulernen, und manchmal sogar die beste Möglichkeit, um zu Lernen. Wichtig dabei ist nur, dass danach „echtes Lernen“ stattfindet, um den gleichen Fehler nicht nochmal zu machen. Schließlich wäre es ebenfalls ein Anti-Pattern, wenn unter dem Deckmantel von „Fehler sind erlaubt“ keine passenden Lern-Schleifen existieren.

Achte also bei Deinen Beobachtungen insbesondere darauf, ob es Raum und Möglichkeiten gibt, Lern-Schleifen in der Organisation zu haben. Diese sind ein wichtiger Bestandteil, um mit Fehlern umgehen zu können.

Cost of Delay

Cost of Delay ist ein Begriff, den Donald Reinertsen geprägt hat. Vereinfacht gesagt kannst Du für jedes Work Item, das durch Dein System (also zB Dein Team) geht, eine Cost of Delay bestimmen. Nämlich die Kosten, die entstehen, wenn Du dieses Work Item nicht abarbeitest (Verzögerungskosten).

Wenn Du die Kosten auf einem Graphen darstellst, bei der auf der x-Achse die Zeit notiert ist, dann bekommst Du eine schöne Shape-Darstellung der Cost of Delay für ein einzelnes Work Item oder eine Kategorie von Arbeitsaufgaben.

Diese Betrachtung der Cost of Delay kann Dir helfen einzuplanen, wann ein guter Zeitpunkt ist, ein Work Item zu erledigen. Es hilft Dir auch einzuschätzen, ab welchem Zeitpunkt die Verzögerungskosten ansteigen (und wenn ja, wie, zB linear oder exponentiell).

Little’s LawWIP

Throughput= Avg Cycle Time

Dazu passt Little’s Law. Im Durchfluss von Arbeit durch ein System sind zwei Metriken wichtig: die Cycle Time und die Lead Time. Während die Lead Time darüber Auskunft gibt, wie lange ein Work Item von zum Beispiel „Idee wurde geboren“ bis „Done“ braucht, gibt Dir die Cycle Time Auskunft über die Zeit von „Idee geht in Produktion“ bis „Idee ist auf Done, wurde also realisiert und ist in Produktion gekommen“.

Für die Berechnung der durchschnittlichen Cycle Time empfiehlt sich Little’s Law: der Quotient aus der Menge an Arbeit, die gleichzeitig „in Erledigung“ ist (Work In Progress) geteilt durch den „Durchsatz“, den das System liefern kann in einer bestimmten Zeiteinheit. Das ergibt die durchschnittliche (!) Cycle Time deines Systems.

Lead Time und Cycle Time sind zwei wichtige Metriken, um den Fluss von Arbeit durch ein System - also zB in einem Team - zu betrachten.

MVP vs MMPLernfähigkeit Vermarktbarkeit

Wir alle kennen den Begriff des „MVP“, denn er ist uns im Kontext des Lean Startup begegnet. Roman Pichler hat zudem noch den Begriff des MMP geprägt. „MVP“ steht für „Minimum Viable Product“, „MMP für Minimum Marketable Product“.

Die Unterscheidung der beiden Begriffe hilft Dir, eine gute Einordnung für den Release-Fahrplan Deiner Software zu treffen: das MVP liefert Dir die Lernfähigkeit. Es ist die minimale Variante Deines Produkts, die Du an Deinen Markt online stellst (zB mit Beta-/Key-Usern). Das MVP wird Dir die erste Möglichkeit zum Lernen liefern, anhand dessen Du weitere Funktionen in der Software realisierst.

Das MMP hingegen ist die minimale Variante des Produkts, die „echt vermarktbar“ ist. Sie ist also durchaus „mehr“, als das MVP bietet. Und findet zu einem späteren Zeitpunkt statt.

Wenn Du so willst, dann ist MVP in der alten Sprache gesprochen der „erste Meilenstein“. Mit dem Vorteil, dass Du Lernen kannst. Um dann zu einem späteren, jetzt noch unbekannten „Meilenstein“ die erste „echte“ Vermarktbarkeit zu bekommen.

Frei-Zeit vs

~100% Utilisation

Wir sind alle getrieben von Produktivität, nicht erst seit es lifehacker.org gibt ;-) Mit diesem Denkwerkzeug biete ich Dir eine Unterscheidung, die Dir hilft, bessere Software zu entwickeln.

Wenn Du als Unternehmen heute innovationsfähig sein willst, dann müssen Innovationen entstehen können. Der Kristallisationspunkt einer Innovation entsteht aus vielen Dingen, die mal mehr und viel weniger geplant gemacht werden.

Für diese vielen Dinge benötigt es Frei-Räume. Wenn Du jedoch in Deiner Organisation dem Gedankenmodell anhängst, dass nur „100% Auslastung“ (oder nahe 100%) echte Produktivität bedeuten, dann beraubst Du Dich deiner Innovationskraft. Denn wenn durch die Produktivitäts-Auslastung kein Platz mehr für „freie Radikale“ ist - woher soll dann die Innovation bitteschön kommen?

Wir bei Mayflower haben seit über vier Jahren eine sogenannte Slacktime. Weil bei uns alles etwas anders ist als in anderen Unternehmen, haben wir diese Slacktime „Mayday“ getauft. Ich habe darüber auf https://www.impulse.de/management/unternehmensfuehrung/slacktime/2178126.html berichtet. Jeden zweiten Freitag nehmen wir uns „frei“ von der kundenfinanzierten Utilisation. Wir geben auch keinen gesonderten Rahmen vor, ausser einer zeitlichen Struktur (die die Crew immer wieder anpasst) und dem Prinzip, dass etwas sinnvolles für das Unternehmen getan wird.

Was, das bleibt den Leuten überlassen.

Ich muss zugeben, dass ich zu Beginn bei der Einführung sehr skeptisch war und anzweifelte, ob das funktioniert. Ein halbes Jahr später wurde mir bewusst, dass dies eine sehr sehr gute Entscheidung war, dass sie uns als Organisation Innovation beschert, die Erneuerung von Wissen auch außerhalb von Kundenprojekten sowie zur Steigerung der Mitarbeiter-Zufriedenheit beiträgt.

Fitness Metrics

• Delivery Time

• Quality

• Predictability

• Safety (i.e. regulatory reasons)

• Employee / Customer satisfaction

Wie kannst du also feststellen, ob ein System „fit“ ist? Frei nach David J. Anderson aus dem Lean Kanban Systems Thinking Denkmodell gibt es fünf wichtige Kern-Metriken, nach denen Du Dein System beobachten solltest: wie gut ist deine Lieferfähigkeit/-zeit? Wie hoch ist die Qualität Deiner Software? Wie vorhersagbar ist die Lieferung durch dieses Team? Wie „sicher“ arbeitet es (zB in Bezug auf regulative Vorgaben)? Und wie hoch ist die Kunden und Mitarbeiter Zufriedenheit?

Doch Vorsicht vor der Anwendung dieses Denkwerkzeugs: es bringt Dir nichts, wenn Du dich nur auf eine Metrik stützt. Wenn Du also zum Beispiel feststellst, dass Team A eine deutlich bessere Lieferzeit hat als Team B, dann heißt das noch lange nicht, dass Team A das bessere Team ist. Denn die Qualität könnte niedriger sein, ebenso die Kundenzufriedenheit. Du solltest also immer alle Metriken im Gesamtzusammenhang anschauen.

Damit das gut funktioniert, hilft Dir zum Beispiel ein Spider-Diagramm, auf dem Du alle Metriken an den Spider-Achsen aufzeichnen kannst und Dir dann ein Gesamtbild machen kannst.

J-curve Effect

http://de.slideshare.net/DavidHawks1/deliver-double-the-value-in-half-the-time-43600722/34

Du hast jetzt also eine ganze Menge an Ideen an der Hand, um Veränderungen in Deinem System durchzuführen. Doch ganz so einfach ist es nicht: Willkommen beim J-curve Effect.

Dieser wurde geprägt von Virginia Satir im Umfeld der Familientherapie. Als Denkwerkzeug auf die Organisation, die Software-Entwicklung zum Beispiel anders als bisher angehen möchte, sei wie folgt erklärt:

Der J-curve Effect besagt, dass mit Beginn der Induzierung einer Veränderung - also weg vom Status Quo), zunächst einmal ein negativer Effekt eintritt. Dieser wird zu Resistenz bei den Personen (denn wer will schon gerne verändert werden?) und möglicherweise auch zu Chaos führen. In dieser Phase ist eine Begleitung sehr wichtig, denn das System (zB das Team) wird erst über einen mitunter sehr langen Zeitraum neue Praktiken akzeptieren/erlernen und kann diese entsprechend integrieren. Daher die langsam ansteigende Kurve, die dann irgendwann bis hin in den neuen Status Quo führt.

Die Zeiträume für „Resistance and Chaos“ und „Integration and Practice“ können mitunter sehr lange sein - nicht nur einige Wochen, oftmals viele Monate, manchmal Jahre. Sie setzen also eine hohe Geduld auf Management-Ebene voraus. Denn bricht das Management den Change vorzeitig ab oder induziert weitere Changes, die den vorherigen überlagern, so fangt Ihr wieder von vorne an.

Vielleicht hilft Dir dieses Denkwerkzeug, bei Veränderungen im Team - zum Beispiel Etablierung agiler Praktiken - mehr Geduld zu haben und gleichzeitig durch eine Begleitung sicherzustellen, dass das Team irgendwann den neuen Status Quo erreichen kann.

Was solltet Ihr tun? (no silver bullet)

Lass mich also zusammen fassen, was Ihr tun solltet oder könntet, um im Software-Umfeld den Anforderungen an dynamische Welten gerecht zu werden, und was das für Eure Organisation insgesamt bedeutet …

#1 Goal Schnelle, regelmäßige

Lieferfähigkeit(Continuous Deployment / Delivery)

Eines der wichtigsten Ziele, wenn nicht gar das wichtigste, sollte die Herstellung einer schnellen, und regelmäßigen Lieferbarkeit lauten. Im technischen Sinne sind hier die Stichwörter Continuous Deployment bzw. Continuous Delivery gemeint. Auf der „Menschenseite“ verbuchen wir Team-Praktiken sowie echte, bessere Zusammen-Arbeit als Ziel.

Aufstellung der IT-Teams verändern

• kleine, unabhängige Teams als Schnellboote (Alignment vs. Autonomie)

• Flexibilität einbauen: jeder kann alles umsetzen, breite + tiefe Fähigkeiten

• DevProductSupportNetSecBizOps (+ BA, Marketing, Frontend/UX)

• Microservices to the rescue?! (Conway’s Law)

• schneller liefern um früher lernen zu können (Kanban, Scrum, oder andere iterativ-inkrementelle Arbeitsmethoden)

Es geht also darum, die Aufstellung des Software-Teams anzupassen: weg von Einzel-Experten, hinzu den generalisierten Spezialisten ;-), so dass jeder alles umsetzen kann und über breite und tiefe Fähigkeiten verfügt. Schneide kleine, unabhängige Teams als Schnellboote, die über Themen wie Makro-Architektur im Gesamt-Produkt/-Ziel aligned sind. Über Microservices als Taktik ermöglichst Du, dass die menschliche Autonomie, die Du dem Team zugestehst, auch in der Software abbildest (stellt Dir vor, was passiert, wenn Deine Teams zwar autonom sind, aber im Gesamt-Produkt technische Abhängigkeiten/Zusammenschlüsse zwischen den Teams existieren).

Breite und tiefe Fähigkeiten gehen damit einher, dass das Team „cross-funktional“ aufgestellt ist. Das Produkt wird also nicht durch einzelne Abteilungen bedient, sondern Marketing+Development(QA)+Security+Ops etc. sind in einem Team vorhanden. Idealerweise kann jeder alles umsetzen. Dann spürst Du keine Einbußen bei Krankheit und Urlaub :-)

Und denke daran: Du willst schneller liefern, damit Du früher lernen kannst.

Zusammenarbeit zwischen Bereichen verändern

• kürzere Kommunikationswege schaffen: notwendige Disziplinen als Gesamtteam etablieren, räumlich zusammen sitzend

• 3Cs schaffen Klarheit (Methoden zB Story Mapping)

• Stakeholder integrieren und mit in die Verantwortung nehmen (Methoden zB Weighted Decision Matrix)

Verändere die Zusammenarbeit zwischen einzelnen Bereichen. Lass die Leute räumlich zusammen sitzen. Du kennst das? Entwicklung sitzt im 2. Stock, Produktmanagement im 3. Stock, Marketing im anderen Gebäude … ;-)

Denk beim Schreiben von Anforderungen (User Stories) daran, dass es im Wesentlichen um Eines geht: ein Gespräch zwischen allen Beteiligten, um Klarheit zu schaffen!

Der Budget-Inhaber mit den vielen Steaks hat nie Zeit und das Produktmanagement möchte sich nicht mit Euch beschäftigen? Integriert Eure Stakeholder, und nehmt sie mit in die Verantwortung, indem sie aktiv im Prozess beteiligt werden. Gute Entscheidungen kannst Du über Instrumente wie Weighted Decision Matrix facilitieren, denn dort werden die Kriterien aller gegen die Lösungsvorschläge bewertet, um eine Empfehlung heraus zu bekommen.

Endanwender stärker einbinden

• Feature-Wünsche abfragen zB uservoice.com

• tiefergehende Analytics zB hotjar.com

• Feature-Flags: bestimmte Funktionen nur für bestimmte Anwender-Kohorten verfügbar

• Fake-Features: Abfragen, ob Nutzer bestimmte Features haben wollen würden

• Analytics auf Funktionen / Buttons

Bindet Eure Endanwender - uns Konsumenten - ein. Zu „Fake Features“ möchte ich ein Wort verlieren, denn „Fake“ ist ja so ein negativ besetzter Begriff: es geht hierbei nicht darum, die Anwender zu ärgern. Sondern gezielt bei Feature-Ideen zu prüfen, ob die Anwender dies haben wollen. Was liegt da manchmal näher, als eine Funktion anzudeuten und im gleichen Atemzug den Anwender zu fragen, wie sehr er solch eine Funktion vermissen würde. Arbeitet sparsam mit dieser Form!

Bei allen Varianten, die hier vorgestellt werden, geht es um Eines: um eine Lern-Möglichkeit, die Dir die Anwender liefern, um bessere Entscheidungen für die Realisierung von Features in Deinem Produkt zu treffen.

Frei-Räume für Innovation und Wissensaustausch schaffen

• Wiki #workoutloud #microblogs

• Slacktime

• Firmeninterne Barcamps

• Lightning Talks / Brownbag Sessions / Random Lunch

• Entwickler hospitieren in anderen Unternehmens-Bereichen

• Work Expo (Management 3.0)

Schaffe Frei-Räume für Wissensaustausch, Kommunikationsmöglichkeiten und Innovation in Deiner Organisation. Ganz klasse sind firmeninterne, mehrtägige Barcamps ohne vorgegebene Agenda, mit Mitarbeitern aus unterschiedlichen Bereichen.

Lightning Talks, also kurze, fünfzehnminütige Spontan-Vorträge, liefern punktuelle Impulse zu Themen, die bei Bedarf vertieft werden können.

Und lass Deine Entwickler in anderen Bereichen (zB Buchhaltung) hospitieren, und dort Arbeit erledigen. So bekommt der Entwickler ein besseres Bild von dem, was er da gerade baut. Und wenn möglich, mach es auch umgekehrt. Damit die Stakeholder und „Bedarfsmelder“ besser verstehen, wie die Entwicklung arbeitet.

Warum Scrum nicht funktioniert?!

So, und warum funktioniert Scrum jetzt nicht, lieber Björn?

Nun, das wird Gegenstand eines weiteren, längeren Talks sein. Ich gebe Dir aber einen kleinen Sneak-Peak meiner Gedankenwelt zu diesem Thema …

Achtung: Nachdenken!

… doch Achtung: Nachdenken & Mitdenken ist in den folgenden Slides gefragt! Da sind ein paar provozierende Gedanken dabei, die Unruhe in Deinem Kopf stiften wollen.

Aneinanderreihung von Mini-Wasserfällen

Also: Scrum ist der Retter, weil das mit den großen Wasserfall-Projekten nicht funktioniert.

Ist Dir schon mal der Gedanke gekommen, dass Scrum oftmals von Unternehmen als eine Aneinanderreihung von Mini-Wasserfällen (im 14-Tage-Rhythmus) praktiziert wird? ;-) Also alter Wein in neuen Schläuchen?

Planbarkeit des Sprints vs

Flow + Liefern

Viele Organisationen optimieren in der Anwendung von Scrum auf die Plan- und Vorhersagbarkeit eines Sprints hin.

Aber geht es nicht eigentlich um etwas Anderes? Nämlich dass ein Team permanent lieferfähig ist, weil es „im Flow“ ist, und nicht nur alle 14 Tage etwas abliefert, was vorher umständlich mit Hilfe von Planning Poker / Magic Estimation in ein 14-Tage-Kasterl eingepfercht wurde?

;-)

Optimierung auf Velocity

Business Value?

Ich kenne viele Unternehmen, in denen die Velocity des Teams „optimiert“ wird. Jetzt, wo das Management nix mehr zu tun hat, weil das Dev-Team ja schon alles übernimmt und entscheidet, wird den Managern langweilig. Also steuern und optimieren wir doch am besten die Velocity. Ist ja klar: die Velocity muss rauf!

Ach so… ja klar, viele Unternehmen kennen die „Business Value“ Metrik nicht. Oder meinen, die liegt immer bei „30kEUR“ und ist damit supersuperwichtig. Bei jedem Work Item. Alles auf Prio 1!

Alles schon gesehen …

Gesehen: Optimierung auf Einzel-Velocity

Alte Denke …

… a propos alles schon gesehen: es gibt auch Unternehmen, die Optimieren auf Velocity einzelner Team-Mitglieder.

Spätestens hier ist klar, dass mit alter Denke operiert und gehandelt wird. Obwohl es hier doch um das Gesamt-Team geht.

Kultur + Handlungsweisen +

Haltung != Scrum

Scrum funktioniert also nicht. Und warum? Weil Kultur, Haltung und Handlungsweisen noch in einer „alten Denke“ in der Organisation verankert sind.

Oder anders ausgedrückt: Scrum und andere agile Methoden erfordern eine andere Herangehensweise und vor allem Geisteshaltung. Nur dann wirst Du Effekte aus der Agilität für Dein Unternehmen verbuchen.

Und tatsächlich erfolgreich „auf der Welle der Unsicherheit“ in hoher Markt-Dynamik reiten können. Für die Gewinne von Morgen.

Q&A

Björn Schotte https://slideshare.net/BjoernSchotte

bjoern.schotte@mayflower.de 0931 / 35965 - 15

@BjoernSchotte

Nun sind wir schon am Ende dieses Talks. Wenn Du ein oder zwei Ideen hast, wie Du deine Teams oder Organisation besser aufstellen kannst, um bessere Software schneller zu entwickeln, dann hat sich dieser Talk für Dich gelohnt.

Was bleibt? Ich bin neugierig auf Deine Ansichten. Ich freue mich über Widerspruch, Kritik und Anmerkungen. Nur dann können wir voneinander lernen, und ich kann den Talk weiter verbessern :-).

Daher freue ich mich auch, wenn Du dich bei mir meldest. Die Kontaktmöglichkeiten habe ich auf diesem Slide notiert.

Bis bald!