Diese Folge haben Luca und Dierk live bei Youtube aufgenommen. Wir teilen unsere Freude über das Buch „Team Topologies“. Dieses Buch liefert so viel Wissen und hilfreiche Beschreibungen über den Zweck von Teams, ihren inneren Aufbau, den Aufbau der Organisation im “Raum”, d.h. wie verschiedene Teams miteinander interagieren und in welcher Beziehung sie stehen sowie den Aufbau der Organisation in der Zeit, d.h. wie sich Beziehungen und Interaktionen und innerer Aufbau über die Zeit verändern und verändern müssen. Es beschreibt u.a. vier Team-Typen und was das Ziel beim Aufbau einer DevOps Organisation sein sollte. Das Buch liefert so viel wissenswerte Informationen, dass demnächst eine zweite Folge erscheinen wird.
In dieser Episode erörtern die Gastgeber Luca Ingianni und Dierk Söllner die Konzepte aus dem Buch „Team Topologies“ von Matthew Skelton und Manuel Pais. Sie diskutieren, wie das Framework des Buches angewendet werden kann, um leistungsfähige IT-Organisationen zu schaffen, indem Teamstrukturen und -interaktionen verstanden und optimiert werden. Der Fokus liegt auf den vier Arten von Teams (Stream-Alignierte, Ermöglichende, Komplizierte Subsystem- und Plattform-Teams) und darauf, wie diese Teams interagieren und sich entwickeln sollten, um die kognitive Belastung zu reduzieren, den Fluss zu verbessern und die Autonomie zu gewährleisten. Die Episode behandelt auch Conways Gesetz und die Notwendigkeit, organisationale Monolithen aufzubrechen, mit dem Ziel, organisationale und produktbezogene Architekturen für bessere Leistung und Agilität auszurichten.
Inhalt
- Einführung in „Team Topologies“
- Die vier Arten von Teams: Stream-Aligned, Enabling, Komplizierte-Subsystem- und Plattform-Teams
- Diskussion über Conways Gesetz und Organisationsstrukturen
- Die Bedeutung der Minimierung der kognitiven Last und Maximierung der Teamautonomie
- Die Herausforderungen beim Abbau organisationaler und architektonischer Monolithen
- Anwendung von Lean-Management-Prinzipien in der IT
- Die Rolle von Enabling Teams bei der Einführung neuer Technologien und Praktiken
- Die dynamische Natur der Teaminteraktionen und organisatorischen Entwicklung
Shownotes:
Video zur Live-Aufnahme der Folge
Webseite von Team Topologies
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps. Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Luca Injani und Dirk Söllner.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps. Auf die Ohren und ins Hirn.
Gestaltet und produziert von Dirk Söllner und Luca Injani.
Servus, grüß euch.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung und unterstützen dabei, hochperformante IT-Organisationen aufzubauen.
DevOps umfasst für uns beide kulturelle, organisatorische und technische Aspekte.
Diese diskutieren wir hier im Podcast mit Experten aus der Praxis oder in einer gemeinsamen Folge.
Wie zum Beispiel jetzt auch. Eine gemeinsame Folge, Luca und ich.
Und unsere geschätzten Zuschauer.
Ja, das kommt ja jetzt. In der letzten Folge hatten wir nämlich gemeinsam, da haben wir es zum ersten Mal gemacht,
dass wir beide nur sprechen zu einem Fachthema.
Und ja, die Rückmeldung, die wir bekommen haben, war gut.
Wir haben ja auch eine Umfrage. Luca, was kannst du zur Umfrage berichten?
Ja, also die Umfrage bis jetzt haben sich noch nicht so viele dahingetraut.
Insofern möchte ich euch bloß nochmal ermutigen, schreibt doch ruhig was rein.
Wir werden auch wieder in den Shownotes einen Link zu der Umfrage reinhängen.
Weil je mehr wir über euch, liebe Zuhörer, wissen,
wir wissen, was euch interessiert, wie wir den Podcast noch besser machen können,
desto besser ist das für alle.
Diese Folge ist natürlich auch was Besonderes.
Wir haben es ja eben schon gesagt, wir nehmen sie im Livestream auf.
Das heißt, jeder, der beim Anhören des Podcasts denkt, komisch, das liegt vielleicht daran,
dass wir uns währenddessen auch sehen und auch vielleicht Chat-Nachrichten kriegen.
Und ja, ich bin mal gespannt, wie das so wird.
Also insofern, wir hoffen, dass noch ein paar mehr Gäste mit dazukommen.
Wir haben es ja auch ein bisschen verteilt.
In den sozialen Medien.
Und also für alle die, die das im Nachgang hören, auch da könnt ihr euch gerne melden
und mitteilen, ob euch das irgendwie gefallen hat, Rückmeldung geben.
Weil wenn uns das gefällt und euch das gefällt, dann kann man es im Prinzip immer machen.
Also, wir haben aus dieser Folge eine Folge, zwei Aufnahmen.
Einmal die Tonaufnahme für die Podcast-Folge, die hört ihr jetzt eventuell.
Und für die, die live dabei sind, hier das Video, was wir natürlich auch nachher bei YouTube abrufbar haben.
Aber ich würde sagen, Lukas, jetzt bist du mal dran.
Genau, ja.
Nämlich, wir haben momentan ein sehr spannendes Buch am Wickel.
Mit dem Namen Team Topologies.
Manch einer von euch mag davon schon gehört haben.
Es ist wirklich ein wahnsinnig spannendes Buch, weil es aus meiner Sicht irgendwie ganz viel Klarheit reinbringt
und ganz viel Kontext bringt zu Sachen, die bestimmt viele von uns irgendwie schon mal so gespürt haben,
aber vielleicht noch gar nicht.
Bis sie es so richtig bewusst waren oder noch nicht so richtig verstanden haben, welche Mechanismen dahinter stecken.
Für mich ist es ein wahnsinnig spannendes Buch, das ganz grob gesagt eben darum geht,
wie man Organisationen aufbaut aus einer Mehrzahl von Teams, wie diese Teams untereinander interagieren,
wie, sagen wir mal, die Gesetzmäßigkeiten sind in der Interaktion zwischen diesen Teams,
im internen wie externen Aufbau dieser Teams und in deren Rollen.
Und vor allen Dingen, das ist auch spannend, in der Entwicklung über die Zeit.
Du hast ja mich auf dieses Buch gebracht.
Ich weiß, das haben wir in unserem Trello-Aufgaben-Board, das ist aber schon ein halbes Jahr oder ein Jahr drin gewesen.
Und wir haben immer wieder überlegt, das können wir ja mal ein bisschen irgendwie einbauen.
Und irgendwann ging es dann ganz schnell, dass wir das aufgenommen haben.
Und insofern mein Dank an dich für dieses tolle Buch.
Ich wäre selber nicht drauf gekommen, also ich war aktuell noch nicht.
Und ich glaube auch, das könnte so ein Buch bei mir werden, was ich so ähnlich gerne empfehle wie Phoenix Project.
Also es gibt nicht so viele Bücher.
Es gibt Bücher, die ich für dich in jedem Training empfehle.
Aber Phoenix Project gehört mit dazu und das Team Topologies könnte, oder ist eigentlich jetzt auch schon so.
Also man muss noch sicherlich ein bisschen tiefer einsteigen.
Aber auf jeden Fall herzlichen Dank für die Empfehlung.
Ich habe von dir einen tollen Begriff gehört.
Wie lange lag denn das Buch auf deinem Stapel der Schande?
Ach Gott, ja auch viel zu lange.
Wie das immer so ist, es gibt so viele tolle Bücher, die man mal lesen möchte.
Und es gibt dann doch so wenig Zeit.
Aber dieses Buch, das kann man wirklich mit Fug und Recht ganz oben drauflegen und dann auch als erstes wieder runternehmen.
Einfach weil da wahnsinnig viel drin steckt.
Ich habe jetzt immer noch nicht alles, glaube ich, komplett durchdrungen, was in diesem Buch überhaupt drin ist.
Überhaupt, weißt du, das ist eins von diesen ganz lästigen Büchern, die, wenn man sich da alle interessanten Sachen anstreicht, ist hinterher das ganze Buch bunt.
Ja.
Das ist immer, das gibt es auch, dass man sich dann hinterher so fragt, warum streiche ich das eigentlich alles, warum streiche ich das eigentlich an?
Eigentlich muss ich das ganze Buch.
Mir merken.
Und das ist wirklich eins von diesen Büchern.
Das ist wirklich ganz voll mit ganz spannenden Aspekten.
Ja.
Dann kann ich dir einen Vierfarb-Coolie empfehlen.
Also ich lese das mit einem Vierfarb-Coolie und habe dann verschiedene Farben, die verschiedene Dinge ausschalten.
Nee, da zerkratzt mein Display.
Das ist der Bildschirm.
Ich lese doch haptisch.
Aber okay.
Auf deinem iPad wird das wahrscheinlich können, dass du den Stift in verschiedenen Farben nimmst.
Aber egal.
Also.
Dann ist es noch bunter.
Genau, eben.
Das hilft dann auch nichts.
Aber gut.
Warum ist das Buch denn so gut?
Warum gefällt uns das?
Wir haben ja in unserem Training ja immer so eine Folie drin oder zwei Folien zum Thema Conway’s Law,
wo wir auf ein bisschen Zusammenhänge zwischen Architektur und Organisation eingehen.
Und Conway’s Law hatten wir beide ja schon mal behandelt.
Und für die, die meine LinkedIn-Posts nicht lesen, ich hatte einen Schulungsteilnehmer, der hat sich beschwert.
Der hat sich beschwert über Conway’s Law.
Aber er hat sich davor quasi über Tuckman’s Modell beschwert.
Also erste Folie, Tuckman’s Modell irgendwo, Teams von 1977.
Und dann meinte der doch tatsächlich, wieso wir denn in diesem Jahr 2020 so ein altes Modell noch nehmen oder haben.
Und da habe ich ihm das kurz erklärt, dass es immer noch gut ist mit allen möglichen Facetten.
Und habe gesagt, und nachher kommt noch eins, das ist noch älter.
Ja, und dann kam Conway’s Law, also 1968 oder 65.
Ich habe da so zwei Zahlen gelesen.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Das ist im Prinzip der Kern dieses Buches.
Es geht bei dem Buch darum, das ist der Untertitel, Organizing Business and Technology Teams for Fast Flow.
Also es geht darum, dass wir im Prinzip auch wieder Grundprinzipien aus dem Lean Management übernehmen.
Das haben wir ja häufig im DevOps, dass wir Ideen und Prinzipien aus dem Lean Management übernehmen, nämlich aus der Produktion in die IT.
Und wenn ich so an meine letzten Jahre, Jahrzehnte zurückdenke, so viele Berater haben immer gefordert,
dass die IT industrialisiert werden soll.
Und das ist auch wieder ein Punkt.
Wir haben ja wieder Ansätze, die in der Industrie funktionieren und die übertragen wir quasi auf die IT.
Und das ist eben ein Buch mit dabei.
Also das ist interessant.
Also wie gesagt, Team Topologies, Organizing Business and Technology Teams for Fast Flow.
Also es geht darum, die Dinge sollen einfach schnell durchlaufen.
Und ich glaube, jeder Kunde wird sich darüber freuen, wenn Dinge schnell durchlaufen.
Natürlich muss auch die nötige Qualität kommen.
Gut.
Ja, ich finde, das ist immer der Punkt, weil es ist ja leicht zu fordern, etwas muss schnell gehen.
Aber letzten Endes, es gibt ja dieses berühmte Dreieck.
Schnell, gut, billig, wähle bestenfalls zwei.
Und ich glaube nicht, dass das stimmt.
Also das ist etwas, was ja auch die Forschungen, die verschiedene Leute gemacht haben,
die dann auch zu dem Buch Accelerate geführt haben und sowas haben gezeigt.
Man muss nichts wählen zwischen schnell und gut und billig.
Oder zumindest nicht teurer.
Sondern man kann alles haben.
Und man sollte alles haben.
Also das ist irgendwie immer mein Hauptargument für DevOps.
Warum sollte ich mir das Leben denn schwerer machen als nötig?
Ja, richtig.
Und jetzt könnten wir ja über den Unterschied zwischen Effektiv und Effizienz nochmal uns unterhalten.
Wollen wir aber mal sein lassen an der Stelle hier.
Wir wollen über das Buch reden.
Vielleicht für die, die das Buch noch nicht kennen.
Das sollten ja viele sein, die den Podcast hier hören.
Bei dem Buch geht es erstmal um den Zweck von Team.
Also welchen Zweck, welches Ziel haben die Teams?
Wie baue ich die Teams im Inneren auf?
Also die Organisation mit den Teams.
Und wir haben eben über schnell gesprochen.
Ein ganz wichtiger Punkt.
Also es geht darum, nicht, das ist auch so ein Kernpunkt,
dass häufig Teams aufgebaut werden, um auf ein Problem zu reagieren.
Also da wird schnell reagiert.
Und das Buch versucht zum Beispiel auch klarzumachen,
dass es eben eigentlich nicht darum geht, schnell ein Problem zu lösen,
sondern sich über den gesamten, um die gesamte Umgebung,
Gedanken zu machen.
Also nicht schnell bürgerliche Teams bilden.
Habe ich gerade wieder aktuell in einem Fall auch,
wo im Prinzip das Management schon Teams vorgedacht hat, vorgeschlagen hat.
Und man merkt, sie haben nicht zu Ende gedacht.
Und sie haben das Buch auch noch nicht gelesen.
Aber das mal am Rande.
Also es geht um den Zweck von Teams.
Es geht um den inneren Aufbau der Teams.
Und es geht darum, wie diese Teams quasi in dem Unternehmensraum aufgebaut sind.
Das heißt, wie sollten diese Teams miteinander,
wie sollten sie sich miteinander interagieren?
In welcher Beziehung sollten sie miteinander stehen?
Das werden wir bestimmt noch im Detail noch ein bisschen erläutern.
Und es geht darum, wie sich diese Organisation im Zeitlauf,
im Zeitablauf verändert.
Also es gibt da so ein paar Patterns und Anti-Patterns.
Das heißt also, vielleicht gibt es auch Organisationsformen,
die für einen kurzen Zeitraum sinnvoll sind,
die aber dann nur eine Übergangslösung sind.
Also das ist so quasi als Einführung
auf den groben Inhalt des Buches.
Habe ich was vergessen, Luca?
Nee, das war so ganz spannend.
Aber ich möchte gerade auf etwas einhaken,
was du so im Vorbeigehen erwähnt hast.
Nämlich du hast gesagt, oh ja, dieses Management,
das hat sich da schon irgendwie Teams zurechtgelegt.
Und man merkt, dass das nicht geht.
Woran merkt man das denn?
Ich merke das.
Also es war erst mal nur ein erstes Gespräch.
Also eine Art Kick-off.
Und ich merke, dass die Teammitglieder sich sperren.
Dass die Teammitglieder sagen, wir haben andere Gedanken.
Und so wird das nicht funktionieren.
Das heißt, da ist letzten Endes
bei den Teammitgliedern ein Bauchgefühl
oder vielleicht auch ein Kopfgefühl.
Aber sie bringen einfach zum Ausdruck,
dass sie mit dieser Grundidee,
wie die Teams geschnitten werden sollen,
nicht einverstanden sind.
Okay, also die sagen quasi schon voraus,
wir sehen schon, dass das nichts wird.
Weil wir es immer schon so gemacht haben
und weil wir uns DevOps anders vorstellen zum Beispiel.
Also ich glaube, das ist auch das,
was du ja vorhin sagtest,
dass in dem Buch viele Dinge beschrieben sind,
die wir so irgendwie wissen oder ahnen,
aber die wir nicht so konkret beschreiben können.
Und das Buch beschreibt das eben.
Und ich kann mir sehr gut vorstellen,
wenn das in dem Projekt weitergeht,
dass ich aus dem Buch einiges mitnehmen kann
und einige Punkte erklären kann
und das in Worte fassen kann,
was die Teammitglieder jetzt im ersten Kick-off
noch nicht so in Worte fassen konnten.
Ja, ja, ganz bestimmt.
Weil man weiß es ja auch,
dass insbesondere der Kern von
jeglicher Art von Arbeit in der Organisation
besteht in Kommunikation.
Deswegen sage ich ja auch immer,
das erste Engineering-Projekt,
das an einem Mangel an Kommunikation gescheitert ist,
war der Turmbau zu Babel.
Das sind jetzt irgendwie keine neuen Sachen,
die wir verhandeln, sondern das war schon immer so.
Wahrscheinlich auch die Steinzeitmenschen
hatten schon Schwierigkeiten mit der Kommunikation.
Kann ich mir gar nicht anders vorstellen.
Und Menschen sind Menschen geblieben.
Und ich denke, all die Sachen,
die damals gültig waren, sind heute immer noch gültig.
Und die Technologie, wenn man jetzt an Lean denkt,
das aus, keine Ahnung, Toyota kommt,
da sind auch Menschen unterwegs.
Entsprechend wüsste ich nicht,
warum das jetzt bei Toyota gehen sollte,
aber nicht bei Google oder sowas.
Ja, na gut, Turmbau zu Babel.
Da wird ja immer vorgeworfen,
dass sie unterschiedliche Sprachen gesprochen haben.
Aber selbst wenn wir jetzt auf die heutige Zeit gucken,
dass wir alle Deutsch sprechen,
also uns alle zumindest verbal verstehen
oder alle mit Englisch reden,
trotzdem reden wir aneinander vorbei.
Kommunikation muss beachtet werden.
Aber gut, wir gehen noch nicht ins Detail.
Wir fangen ja langsam an, uns dem Buch zu nähern.
Genau.
Du bist ja derjenige,
der für die Übersetzung zuständig ist.
Ist das so.
Was heißt denn Topologies?
Topologie.
Das ist ja toll.
Erklär das mal einem Geografen.
Genau, also wirklich
die Gestalt von etwas,
die Form von etwas.
Man kann es ja,
man kann es ja geografisch deuten,
man kann es auch mathematisch deuten.
Also grundsätzlich, es geht darum,
welche Form nimmt etwas an
und daraus erschließt sich natürlich auch,
wie verhält es sich zu sich selbst,
aber wie verhält es sich vielleicht auch zu anderen Dingen.
Und insofern stimmt das natürlich,
was du eingangs gesagt hast.
Wenn man Teams zuschneidet,
ohne sich zu überlegen,
wie die alle zusammenpassen,
naja, dann wird es halt klemmen.
Wenn man ein Puzzle bauen möchte,
dann wird es halt klemmen.
Wenn man ein Puzzle bauen möchte,
dann wird es halt klemmen.
Aber in der Praxis ist das ja etwas,
was ja trotzdem häufig passiert.
Also zumindest ist das meine Beobachtung,
dass zu wenig darüber nachgedacht wird,
in welcher Weise Teams dann auch tatsächlich
miteinander interagieren müssen.
Man sagt, ja, hier,
wir haben jetzt irgendwie zwei Teams,
die haben wir jetzt irgendwie definiert.
Ja, und was passiert zwischen diesen Teams?
Warum sind das zwei?
Und zumindest mir fehlten da zum Teil
auch noch so ein bisschen
das Instrumentarium, um darüber nachzudenken,
warum zwei Teams da jetzt richtig oder falsch sind
warum zwei Teams da jetzt richtig oder falsch sind
und ob die Trennlinie an genau der richtigen Stelle ist.
und ob die Trennlinie an genau der richtigen Stelle ist.
Und das ist das tolle an dem Buch,
dass es da uns Werkzeuge gibt,
um uns Antworten auf diese Frage anzunähern.
um uns Antworten auf diese Frage anzunähern.
Das, was du eben sagtest,
dass man, ja,
jetzt ist es weg.
Das ist so ein Punkt, den man
in einer Podcast-Aufnahme schon rausschneiden könnte.
Wenn wir live sind, lassen wir es drin.
Also, ich wollte noch darauf hinaus,
mit den Landschaften und so weiter,
wie man Teams schneidet.
Das ist ja genau der Punkt, dass ich,
wie du auch findest,
in diesem Buch gibt es sehr schöne Hinweise,
wie man es schneiden sollte.
Man kriegt ein Verständnis dafür.
Und der Untertitel, habe ich ja vorhin gesagt,
der Untertitel ist das, was mir so gefällt,
dass man Fast Flow hinbekommt.
Und das könnte auch ein Grund sein,
dass Personen, die die Teams jetzt zusammensetzen,
gar nicht auf diese Zielsetzung achten.
Das heißt, die gucken, welche Menschen
sie da haben und wie die jetzigen
Silos oder Abteilungen geschnitten sind,
machen sich aber keine Gedanken,
was man mal grundsätzlich das mal verändern sollte.
Auch deswegen ja vorhin der Hinweis,
es geht nicht darum, oder das Buch empfiehlt,
eigentlich nicht schnell,
reaktiv Teams zusammenzusetzen,
sondern sich wirklich Gedanken zu machen
und das eben anhand des, oder mit der
Basis des Buches, die Teams anders
zusammenzusetzen, als reaktiv
auf irgendeine Fragestellung,
weil, wenn sich die Fragestellung ändert,
wenn sich das Problem ändert, muss man ja neue Teams bauen.
Und das wird ja im Buch versucht zu erklären,
dass man das nicht machen sollte.
Ja, entweder die Teams ändern sich,
oder die Interaktion zwischen den Teams ändert sich.
Also vielleicht sind es dieselben Leute wie vorher,
aber vielleicht stehen die jetzt in einer neuen Beziehung.
Und allein das finde ich schon interessant,
sich zu überlegen, so,
für die ersten, ich weiß nicht, sechs Monate
stehen wir mit unserem benachbarten Team
in folgende Beziehung und dann
ganz bewusst sagen wir,
wir ändern diese Beziehung jetzt,
hin zu etwas anderem. Was damit konkret gemeint ist,
da werden wir im Laufe des Podcasts nochmal
näher eingehen. Ich glaube, das
Wichtige ist jetzt erstmal kurz zu sagen,
dass nicht alle Teams gleich sind,
sondern dass es,
das Buch definiert vier verschiedene
Geschmacksrichtungen von Teams,
die, weil es bestimmte Eigenschaften
haben und die natürlich auch bestimmte
Zielsetzungen vielleicht haben, die sagen nämlich,
es gibt vier verschiedene Sorten von Teams.
Es gibt einerseits, was sie nennen,
Prima Line Teams, das heißt Teams,
die in einem Wertstrom
eingebettet sind und
die mit der Aufgabe betraut sind,
ein Produkt oder einen Produktanteil
zu erschaffen.
Das ist jetzt irgendwie so ein ganz klassisches,
irgendwie DevOps-Team, das ist Cross-Funktional
und so, das ist Ende zu Ende,
alle üblichen Sachen, das sind die,
die sozusagen ganz unmittelbar wertschöpfend sind,
die im Sinne
des Kunden, intern, extern,
was weiß ich, spielt keine Rolle,
etwas erzeugen.
Ich darf jetzt mal übertragen auf
einen einfachen Ansatz,
das sind die Product Teams,
die Business System Teams, richtig?
Ja, genau, genau.
Dann gibt es die Enabling Teams.
Die sind so ein bisschen das, wie der Name
auch schon sagt, die sind
unterstützende Gruppen, die
anderen Teams, die anderen Teams
dabei helfen, neue Fähigkeiten
zu erwerben oder
neue Technologien in den Einsatz
zu bringen. Das könnte zwischen
einem einzelnen Team von Coaches sein. Ich sage jetzt mal
irgendwie agile Coaches in irgendeinem
großen Unternehmen, die zu jedem einzelnen
Streamerlein-Team hingehen können und denen
helfen können, neue agile
Techniken sich anzueignen
und umzusetzen. Oder
es könnte auch ein technisch basiertes Team
sein, das da sagt, pass mal auf, wir
helfen euch dabei,
Testautomatisierung umzusetzen,
wir helfen euch beim Aufbauen, wir beraten euch,
wir gehen vielleicht gemeinsam
die ersten Schritte, aber, und das ist das
Wichtige bei einem Enabling Team, irgendwann sind die
wieder weg. Die sind,
wie ein Coach oder sowas, die begleiten
für eine gewisse Zeit,
um dem Streamerlein-Team oder
wie auch immer, dem Kundenteam nächstes Mal
dabei zu helfen, neue
Fähigkeiten, neues Wissen
und so weiter sich anzueignen und
dann gehört das denen. Und
dann geht das Enabling Team wieder weg und
macht dieselbe Sache für wen anders. Und
das heißt, das ist für mich etwas, was
ich in unserer einfachen Darstellung
nicht wiederfinde oder nicht direkt zuordnen
kann. Wir haben ja normalerweise, wir haben
Produktteams oder Productteams, die den Kunden
ein Produkt liefern und die
Plattformteams, die quasi die Infrastruktur
bereitstellen, mal ganz einfach gesprochen.
Diese Enabling Teams
sind neu für mich an der Stelle.
Ja,
wobei, das ist ganz spannend,
weil es ist etwas, ich weiß nicht, wie dir das geht,
Dirk, aber wenn ich bei unserer typischen
Conway-Folie bin, dann
komme ich da quasi unter einer Dreiviertelstunde nie wieder
weg von der Folie. Weil das
zu so viel Gesprächsbedarf führt
bei den Teilnehmern, erfahrungsgemäß. Und das
denen so wichtig ist und
auch so viele Gedanken freisetzt.
Insofern sieht man, glaube ich,
auch, auf was für fruchtbaren Boden dieses Buch
fällt. Und ganz häufig kommt dann ja auch die Frage
auf, was mache ich denn mit so Leuten wie,
ich weiß auch nicht, wie einem Datenbanker,
der irgendwie überall
gebraucht wird oder sowas. Und
insofern, ich glaube, der,
auch wenn dieser Begriff eines Enabling Teams
vielleicht noch nicht
präsent war, ich glaube, dass
der Bedarf an einer solchen Rolle,
den spüren viele
auch ohne, ohne
dass sie dafür einen Namen wüssten oder sowas.
Ja. Also ich glaube auch,
wir kommen ja zu den beiden anderen Teams noch, aber ich glaube,
dass das eben auch das
unterstreicht, was du vorhin gesagt hast. Das ist
jetzt in Worte mal gefasst worden, es ist beschrieben
worden, was wir quasi spüren.
Und wenn ich jetzt den Datenbanker nehme,
ich komme dann immer mit meinem Witz, dass ich
natürlich, wenn ich zehn Teams habe und nur
fünf Datenbanker, dass das eine ziemlich
blutige Angelegenheit wäre, wenn ich
die aufteile. Ja, es geht ja gar nicht.
Dann sage ich also, ja, da müssen die
eben in das, in das Plattformteam
und müssen ihr Wissen quasi abgeben, damit
das Wissen in den Produktteams ist.
Und genau dafür ist so ein Enabling Team, glaube
ich, oder die Idee eines solchen
Enabling Teams eine sehr, sehr
interessante Lösung.
Im Einzelfall, das Spannende
ist ja dann immer, was macht man mit so einem Datenbanker
wirklich? Denn man könnte ja auch
einen anderen Weg wählen. Man könnte ja auch die dritte Art
eines solchen Teams anwenden. Man könnte
sagen, die ganzen
Datenbanken, die stecken wir in ein Plattformteam
und die bauen für uns eine Datenbank.
Plattform. Die stellen uns eine Infrastruktur
bereit, die von
allen Stream-Aligned Teams genutzt werden kann.
Da muss man bloß wahnsinnig
aufpassen, weil es ist, es wäre
natürlich verlockend, da in das alte
Denkmuster zurückzufallen, zu sagen, ich habe jetzt eine Datenbankabteilung
und die macht irgendwie halt so Datenbankkram.
Aber so ist es nicht gedacht,
sondern ein solches Plattformteam, das erstellt
auch ein Produkt, aber natürlich
ein Produkt, das nicht unmittelbar
dem Endkunden zur Verfügung gestellt wird, sondern
ein Produkt für
die Stream-Aligned Teams. Das heißt, damit
müsste dann ein Datenbankprodukt
daraus werden, dass die
nutzen können, und zwar auf
bestimmte Weisen, über die wir dann, glaube ich, als nächstes
sprechen wollen. Ich
spare jetzt mal ganz, ganz bewusst aus,
woran man festmachen kann, ob
man jetzt eher in Richtung eines
Enabling-Teams gehen sollte, wenn man
zum Beispiel an unsere Datenbanken denkt, oder ob man in Richtung
eines Plattformteams gehen sollte. Weil
jetzt einfach nur so wäre mir das noch nicht
klar. Ist das jetzt ein Enabling-Team
von Datenbankberatern, nenne ich es mal, die
auftauchen und mir ein halbes Jahr
lang was erklären über Datenbanken, und dann
wieder fort sind? Oder ist das ein Plattformteam,
die irgendwie fortwährend
ihre Datenbankmagie
vollbringen, und ich nutze irgendwie deren
Dienstleistung? It’s Magic! Genau!
Und es gibt ja dann, wo wir gerade
bei Magic sind, es gibt ja noch die vierte
Sorte von Teamen, über die wir noch gar nicht gesprochen haben,
nämlich diese sogenannten Complicated
Subsystem Teams. Cooler Name!
Ja, gell? Die sind
im weiteren Sinne sowas ähnliches wie ein
Plattformteam.
Die sind nämlich damit
betraut, sich um besonders
verzwickte Sachen zu kümmern.
Ich sage jetzt mal, irgendwie
ein Team, das eine künstliche Intelligenz
irgendwie bereitstellt oder sowas,
die dann natürlich von den Stream-Aligned Teams
benutzt, konsumiert, betrieben
wird, aber wo
das Thema, die Materie als solche
so dermaßen in sich hat, dass man dafür
einfach wirklich einen Haufen von Fachleuten
braucht, irgendwie hier, ich weiß ja auch nicht, gestandene
Doktoren der Mathematik oder sowas,
die dieses
eine verzwickte Subsystem
irgendwie, naja,
die Fuhre in der Kurve halten. Insofern ist es so ein bisschen
angelehnt vielleicht an ein Plattformteam, aber
es ist was anderes, weil so eine Plattform
ist vergleichsweise, ich sage mal, harmlos,
ist vielleicht auch ein bisschen breiter,
während dieses komplizierte Subsystem,
das wird vielleicht wirklich nur von einem einzigen Stream-Aligned
Team wirklich
verwendet, aber
die Materie ist so teuflisch,
dass es sich lohnt,
das wirklich auszulagern, sodass sich jeder
auf seinen eigenen Kram konzentrieren kann.
Auf seinen eigenen Kram konzentrieren.
Also das ist ja wirklich
ein ganz wichtiges Argument oder
eine ganz wichtige Erkenntnis,
die in dem Buch rüberkommt, dass man letzten Endes
die Teams so schneiden sollte,
Stichwort Convice Law, dass sie sich auf
ihren Kram konzentrieren können. Also
versuchen, möglichst wenig Interaktion
zu anderen Teams zu haben, weil
das eben nicht diesen Fast Flow
unterstützt.
Ja, aber das leuchtet mir
jetzt a priori noch nicht ein, weil wir sagen doch
Kommunikation sei gut. Wieso ist die denn jetzt plötzlich
nicht mehr gut?
Im Team, nicht außerhalb
des Teams, ganz wichtig. Im Team
die Kommunikation, aber nach außen hin,
also Kommunikation im Sinne von
Abhängigkeiten klären,
Arbeitsweitergabe klären,
das sollte man minimieren. Das ist
zumindest eine Erkenntnis, die ich
aus dem Buch gezogen habe.
Das ist nämlich
der Kern der Sache. Und damit sind wir
auch bei dem, brauche ich ein
Enabling-Team oder ein Plattform-Team beispielsweise,
nämlich Teamorganisation
verfolgt
zentral drei verschiedene
Ziele. Einerseits Flow, sprich
schnell von der Idee zur Umsetzung
kommen. Und zwar zur wirklichen
Umsetzung im Sinne von
befindet sich im produktiven Einsatz
vor der Nase des Kunden. Aber zweitens,
damit man diesen Zustand von Flow
und von Geschwindigkeit erreichen kann,
muss man zwei Sachen
geschafft haben. Man muss nämlich einerseits
die kognitive Last der Teams
irgendwie im Griff behalten. Mit anderen
Worten, je schwieriger, je verwirrender,
je verzwickter ein Thema wird,
desto weniger schnell werden die vorankommen,
desto fehlerträchtiger wird
das Ganze werden.
Insofern, es geht darum, Teams
so zu schneiden, dass möglichst
viel von ihrer, ich sag mal, gedanklichen
Energie darauf verwendet werden kann,
Probleme oder
neuen Nutzen für den Kunden zu schaffen
und nicht herauszufinden,
mit welcher Abteilung sie sich jetzt in Verbindung
setzen müssen, um was hinzubringen
oder rauskriegen
müssen, wie man irgendwie eine API verwendet
von irgendeinem Produkt oder sowas.
Man kann sich ja leicht vorstellen, jeder hat irgendwie so,
ich sag mal, eine gewisse
Menge an
Hirnschmalz, die er zur Verfügung hat.
Und je mehr er die für irgendwelche
Nebenkriegsschauplätze aufwenden muss,
umso weniger bleibt naturgemäß übrig,
um wertschöpfende Arbeit
zu machen. Und darum geht’s,
dass man versucht, diese kognitive Last
möglichst niedrig zu halten, sodass
dieses Hirnschmalz auf die nutzbringendste Weise
zum Einsatz kommen kann. Auch das finde ich
einen coolen Ansatz. Diese
kognitive Last
oder Belastung, die kommt ja aus
einer ganz anderen Ecke. Die kommt ja aus der
Lernforschung oder
Hören- und Lernforschung. Finde ich aber super
interessant, das hier auch zu übertragen.
Wenn man mit dem Wissen dieser drei Arten,
dieser drei Belastungsarten
mal so seine tägliche Arbeit
anschaut, dann merkt man schon, da steckt
was hinter. Oder das kann man sehr gut
nutzen, um auch vielleicht
mal eine Demotivation zu erklären.
Weil einfach die kognitive Last zu hoch ist
für banale Dinge oder für scheinbar
banale Dinge. Aber für den
Mitarbeiter, den das gerade stört, ist das eben nichts banales.
Ja, genau,
weil der einfach erschlagen ist. Und ich glaube, das kennt
jeder, dass er sagt, also eigentlich
bin ich ja, weiß Gott, keine Ahnung, erfahren
genug, schlau genug für diese Aufgabe,
aber ich habe einfach schon 20 andere.
Ich weiß nicht mehr, wo ich es unterbringen soll,
selbst wenn ich die Zeit
dafür hätte, aber ich habe gar nicht mehr die gedankliche
Energie dafür. Zum Teil auch, das ist
ja auch interessant, zum Teil vielleicht nicht mal mehr die
emotionale Energie. Es hat sich ja gezeigt, dass
insbesondere Entscheidungen
Kraft kosten. Und insofern,
je öfter man sich entscheiden
muss, selbst für Banalitäten, nehme ich jetzt,
ist das Cola oder Sprite,
das zieht Energie
von mir ab, bis die dann halt irgendwann mal
verbraucht ist. Und dann habe ich zwar vielleicht noch
Stunden übrig in meinem Tag, aber kann mich
eigentlich nur noch mit irgendwelchen
Wettballaufgaben beschäftigen, weil ich
bin jetzt leer.
Kennt, glaube ich, jeder.
Oder zu sagen, du meintest,
ja, also ich könnte das lösen, aber ich
weiß, ich muss mit 15 Leuten
sprechen. Übertreiben wir nicht. Ich muss mit 5 Leuten sprechen,
wie ich das zu tun habe.
Und da habe ich jetzt einfach gar keine Energie
mehr zu. Das heißt, eigentlich könnte ich die Aufgabe
lösen, also fachlich, aber
die kognitive Belastung, mit anderen
draußen zu sprechen, rauszufinden, wo
muss man sich drum kümmern, die zieht
mich nach unten. Ja, genau so ist es.
Und insofern…
Du hast zwar drei Dinge besprochen.
Genau. Und das dritte hast du jetzt
im Prinzip schon erwähnt, nämlich
der dritte Aspekt ist Autonomie.
Sprich, ich sollte möglichst
wenige Abhängigkeiten
nach außen haben. Ich sollte
meine Aufgabe erfüllen können
zu meinen eigenen Bedingungen, in meinem eigenen
Rhythmus, mit meiner eigenen Geschwindigkeit, ohne
dass ich zeitreihende Abstimmungen
brauche, ohne dass ich jemanden um Erlaubnis
fragen muss, ohne dass ich jemanden um Mithilfe
fragen muss. Denn, das kennt jeder,
all diese Prozesse bremsen einfach,
sind einfach eine Hürde. Und
wenn ich es schaffe, diese Hürden rauszunehmen,
na ja, dann bin ich natürlich umso viel schneller,
dann kann ich umso besser in
meinen Flow reinkommen.
Und jetzt sind wir, glaube ich, genau bei
dem Punkt, den ich vorher ansprach,
Enabling Teams versus
Plattform Teams. Der Unterschied ist
genau, wie kann ich das
Kundenteam, sprich
das Stream-Align-Team oder sowas,
am besten zu mehr Autonomie führen?
Indem ich ihnen neue
Techniken
zur Verfügung stelle, indem ich ihnen
helfe, neues Wissen anzueignen, neue Methoden
anzuwenden, was auch immer. Oder
indem ich diese ganzen
Komplexitäten vor ihnen verberge,
und ihnen nur eine einfach
zu kommunizierende,
konsumierende Schnittstelle zur Verfügung stelle.
Sprich eine Plattform.
Daran entscheidet sich’s.
Wenn ich jetzt mal schaue, wir haben
ja schon, ja, was weiß ich, eine halbe Stunde
hier diskutiert, knapp eine halbe Stunde,
das war ja schon relativ viel. Also
bis hierher können wir mal festhalten,
wir haben eine, das Ziel
des Buches ist klarzustellen, wie
eine Organisation aus Teams
dieser vier Arten aufbauen kann. Also
Stream-Align-Teams, Enabling-Teams,
Complicated-Subsystem-Teams
und Platform-Teams.
Und das Ziel dabei ist, dass diese
drei, Quatsch, diese drei,
diese vier möglichen Arten von
Teams so zusammenarbeiten,
dass sich die drei genannten Ziele,
Flow, Minierung oder
Management der kognitiven Belastung
und Autonomie, dass ich die möglichst gut
erreiche. Richtig? Genau.
Super. So, jetzt reden wir
über Organisationen und über Menschen.
Und Conway’s Law
erzählt ja auch irgendwas von Architektur.
Das heißt, wie hängt Architektur
mit Conway’s Law zusammen?
Oder sagt das Buch da gar nichts zu?
Naja, dieses
ganze Buch ist quasi eine
Anwendung von Conway’s Law. Nochmal
zur Erinnerung, was sagt Conway’s Law? Conway’s Law
sagt, die Struktur einer Organisation
wird sich immer abbilden in der
Struktur der Produkte, die sie
hervorbringt oder der Architektur,
die sie hervorbringt.
Und jetzt sind wir natürlich genau
mittendrin, weil das bedeutet jetzt,
so wie ich meine Teams zuschneide und so wie
die Kommunikationsflüsse zwischen meinen Teams sind,
genauso wird dann auch
mein Produkt zugeschnitten sein. So werden
auch die Informationsflüsse innerhalb des
des Produkts sein. Und
ich glaube auch, dass
wiederum das eine Sache ist, die jeder
der geschätzten Hörerinnen
und Hörer aus eigener Erfahrung
kennt. Vielleicht nicht explizit, aber auf jeden
Fall irgendwie so intuitiv hat das
jeder schon mal erfahren. Dass Systemgrenzen
auch immer genau dort verlaufen, wo Teamgrenzen
verlaufen oder umgekehrt. Und
insofern ist Team Topologies,
da steht zwar das Wort
Team drin, aber es ist natürlich
auch ein Architekturbuch. Notgedrungen.
Kann gar nicht anders sein. Ich werde
gleich mal schauen, aber ich habe da so ein tolles Zitat
in dem Buch drin, da genau der
Punkt, wie hängt das zusammen? Wie hängt
Architektur mit Organisation
zusammen? Vielleicht
gleich noch, wenn nicht, bauen wir das demnächst noch
mal ein. Aber insofern,
wenn ich das richtig verstanden
habe, geht es darum oder
mein Verständnis ist, dass Team Topologies
mit Monolithen
nicht so sehr freundlich
ist. Ja, das
stimmt. Das fand ich ganz lustig. Die haben in diesem
Buch ein komplettes Kapitel oder
Unterkapitel einfach nur dem
Sturm auf den Monolithen
gewidmet. Und zwar in vielfältiger
Form. Das ist das Interessante daran. Die haben das
eben nicht nur bezogen auf
Software oder auf Produkte und
auf deren Architektur, sondern auch
auf die Art der Zusammenarbeit
oder auf die Art, wie Menschen
physisch angeordnet sind. Sprich,
wo sitzen die denn? Wie
sitzen die denn? Ist das jetzt
irgendwie, keine Ahnung, ein
Großraumbüro oder sind das viele Kleine?
Und deren Argument ist, das
wird sich niederschlagen in den
Kommunikationsstrukturen und somit
unweigerlich
auch im Produkt.
Das ist, das glaube ich,
kann einen echt wahnsinnig machen.
Diese Sachen sind alle miteinander irgendwie verquirlt.
Ich habe das im Converse Law
habe ich noch kürzer formuliert, nämlich
wenn Unternehmen kompliziert, dann
Software kompliziert. Und das
spielt ja da im Prinzip komplett
mit rein. Also wenn allein schon
das Arbeitsumfeld
kompliziert ist, dann wird sich,
die Menschen werden ihre Wege finden
und die werden sich nicht mehr auf die schwierigen
Wege begeben. Sie werden die einfachen
Wege nehmen. Also
wenn ich richtig verstanden habe, hast
du das Verständnis, dass das Buch versucht,
diese Monolithen aufzubrechen?
Da etwas zu erklären? Gibt es da
ein paar Beispiele, die du da sagen könntest?
Wie versucht das Buch genau das
zu erreichen?
Wie man diese Monolithen aufbricht? Na ja,
in erster Linie muss man anerkennen, dass irgendwo
tatsächlich ein Monolith ist. Und wodurch ist
ein Monolith definiert? Einfach dadurch,
dass da
verschiedene Sachen miteinander
verknüpft sind, die nicht miteinander
verknüpft sein sollten.
Dass Abhängigkeiten
bestehen, einfach nur, die sich aus der
die sich nicht aus der Natur der Sache ergeben,
sondern die sich aus der Architektur
ergeben, wenn man so will,
zufällig. Und das Buch geht dann auf
verschiedene bekannte
Architekturmuster ein, die man
verwenden könnte, um eine
Systemarchitektur zu bauen, die
einer Monolithisierung entgegenwirkt.
Zum Beispiel Domain Driven Design, solche Dinge.
Was auch sehr wichtig ist, weil wir alle
wissen, dass so ein Monolith, der ergibt sich
mehr oder weniger von alleine. Selbst wenn ich
anfange mit einem schönen
verteilten System, dann
im Laufe der Zeit fossilisiert das immer
mehr, wird immer mehr,
wächst irgendwie immer mehr zusammen, wird immer
verkneulter und verwirrter
und starrer,
es sei denn, ich arbeite aktiv
dagegen. Und
das ist ja auch etwas, was das Buch sagt,
solche Tendenzen
der Monolithisierung,
die kann man nicht nur im Produkt
selber sehen, sondern die kann man auch in den Team Interaktionen
entdecken.
Wenn ich zum Beispiel merke, dass immer wenn ich
in meinem Team irgendwas ändern möchte,
an meiner Komponente, dann muss ich
irgendwie notgedrungen immer zum Nachbarteam
gehen und die um
Mitarbeit bitten, wozu die
natürlich gerne bereit sind, das sind nette Leute und so,
aber das ist ein Signal, das ist ein sehr
wichtiges Signal, das mir
zeigt, hier ist jetzt eine Abhängigkeit
entstanden. Und da muss man
sich die Frage stellen, ist diese
Abhängigkeit notwendig,
aus der Sache herausgegeben,
oder hat die
sich mehr so eingeschlichen und in dem Fall
muss ich dagegen wirken, und zwar natürlich auf der
Produktebene, aber auch auf der Team-Ebene.
Da muss ich überlegen,
genau, stehen diese Teams
noch in der richtigen Beziehung zueinander,
oder muss ich ganz aktiv die Beziehung
dieser Teams anpassen,
um wieder einen entkoppelten
Zustand zu erreichen.
Und in dem Zusammenhang
habe ich auch ein neues Wort gelernt,
abgeleitet
aus dem Minimum Viable Product,
die
Fitness Viable Platform.
Also finde ich interessant, wie
aus der Grundidee von
einem MVP sich verschiedenste
Ableger bilden. Ich habe auch an anderer
Stelle noch andere Ableger,
wie man MVP noch ein bisschen ausdehnen
kann. Wie verstehst du
die Thinest Viable Platform?
Die Thinest Viable Platform, naja,
die geht zurück auf etwas, was
auch für einen
Ingenieur in dem Sinne nichts Neues ist.
Ich mag da immer sehr gerne den Spruch von
Antoine de Saint-Exupéry, der ja auch
immerhin ein ausgebildeter
Ingenieur war, und er hat gesagt, ein Ingenieur weiß,
dass er Perfektion erreicht hat, nicht
wenn es nichts mehr hinzuzufügen gibt,
sondern wenn es nichts mehr wegzunehmen
gibt. Das ist also der Punkt.
Die Thinest Viable Platform ist das
Dümmste, was du dir ausdenken kannst,
was seinen Zweck erfüllt.
Das sagt man den Ingenieuren.
Denkt euch mal was Dummes aus.
Wir denken
uns die beste dumme Sache aus, die du je gesehen hast.
Ja.
Und das ist
eben ganz wichtig, weil eine einfache Sache,
was nicht da ist, kann nicht kaputt gehen.
Und was wir nicht gebaut haben,
darüber müssen wir auch nicht reden,
das sorgt quasi automatisch für
eine Zunahme der Autonomie,
für einen Wegfall von kognitiver Last,
bis zu einem gewissen Punkt, wo man dann wieder
sagen muss, in seiner Einfachheit
macht es mir jetzt Schwierigkeiten,
wird es jetzt verzwickt, und dann ist der Punkt gekommen, wo man
wieder was dazu häkeln muss.
So einfach wie möglich, aber nicht einfacher.
Ich gucke so ein bisschen auf die Zeit,
und wir können
ja mal schauen, wie weit
wir schon gekommen sind, können wir mal kurz abhaken,
und dann entscheiden wir vielleicht auch,
ob wir daraus noch eine weitere Folge machen.
Es gibt so zum Schluss des Buches
hin so eine schöne Aufzählung,
was wirklich wichtig ist.
Und der erste Punkt von den sieben
ist, dass es die vier
grundlegenden Topologien gibt.
Würdest du da zustimmen, dass wir das erledigt haben?
Genau.
Der Zusammenarbeitsmodus der Teams,
Da haben wir noch gar nichts dazu gesagt.
Da haben wir noch gar nichts dazu gesagt.
Aha, da fehlt was.
Die Schnittstellen der Teams.
Die ergeben sich aus der Zusammenarbeit,
haben wir auch noch nicht drüber geredet.
Okay. Conway’s Law, da können wir einen Haken dran machen, oder?
Ja.
Es sei denn, es gibt einen Zuhörer, der sagt, er hätte gerne noch ein bisschen was gewusst,
aber wir machen uns erstmal einen Haken dran.
Das Thema
Organisationsgefühl, also wie
fühlt es sich in der Organisation an?
Haben wir dazu schon genug gesagt?
Wir haben was gesagt, aber ich glaube, es gibt noch mehr
darüber zu sagen. Das sind all diese Sachen,
dass man zuhören soll, wenn die Organisation
zu einem spricht.
Wenn Kommunikation stattfindet, von der man
sich fragt, warum die stattfinden muss, oder sowas.
Team first.
Ja, darüber haben wir irgendwie noch gar nicht
so richtig geredet, sondern Teams
haben wir bisher immer nur so als
Verschiebemasse so angesehen.
Die gibt es halt irgendwie und die haben verschiedene
Ausrichtungen, aber sonst, so richtig first
waren die bisher noch nicht.
Ja, da ist noch Bedarf, zumal jetzt, wo wir nicht mehr
America first haben, können wir ja auch
sagen, Team first. Also
kleiner Karlauer am Rande. Und
wie wir diese Topologien entwickeln.
Ich glaube, wir haben angesprochen, dass man
es tun sollte, aber so im Detail waren wir noch
nicht dran. Ja, das finde ich
ist auch ein wahnsinnig spannendes Thema,
weil so ein Org-Chart ja schon
voraussetzt, dass das irgendwie statisch
ist. Und
Team Topology sagt, ganz so einfach
ist das gar nicht.
Sondern es kann durchaus sein, dass die Beziehung
von Teams untereinander
sich im Laufe der Zeit wandelt.
Insbesondere, das hängt dann wieder mit den
Modi zusammen, dass die vielleicht anfangen
mit einer sehr engen
Zusammenarbeit und
mit dem expliziten Ziel, sich dann aber auch
hinterher wieder auseinander zu dividieren und
sich zu entkoppeln, mehr Autonomie
zu erreichen, für beide Seiten
die kognitive Last zu verringern. Also
das ist noch ein spannendes Thema, über
das wir noch, glaube ich, mit größerer Ausführlichkeit
sprechen können. Also länger
als nur ein paar Minuten. Also
insofern, wir haben noch ein paar
To-Do’s hier für die Themen.
Um darauf einzugehen,
ich würde sagen,
wir machen noch eine weitere Folge.
Ich glaube auch. Es ist so ein spannendes Thema.
Also ich kann auch den ganzen Tag drüber reden.
Das nur so zur Warnung.
Könnte
sein, dass dann irgendwelche Leute
dann irgendwann nicht mehr zuhören, weil
der ganze Tag ist dann schon ganz schön viel.
Aber vielleicht
machen wir ja auch eine Schulung daraus.
Wenn ich das so richtig mitbekommen habe,
bist du gerade dabei, da was zu überlegen.
Nicht nur vielleicht, sondern ganz konkret.
Diese Woche ist irgendwie eine Woche der
Experimente. Wir machen unseren ersten Livestream und
momentan mache ich auch ein anderes spannendes
Experiment. Ich werde
innerhalb von 48 Stunden
einen Workshop entwickeln. Zu genau
diesem Thema. Zu genau diesen
Fragestellungen der Teamorganisation,
der Teamzusammenarbeit.
Das heißt,
morgen Abend soll der vom Prinzip her
fertig sein. So ist der Plan. Insofern, wer
das Thema tatsächlich noch mehr vertiefen
möchte und
geführt sich dem annähern
möchte und das vor allen Dingen für seine eigene Situation
durchdenken möchte, für den
werde ich mit Erscheinung dieses Podcasts
ein spannendes Angebot haben. Die Idee
ist, dass das ein vierwöchiger Workshop
wird. Wir treffen uns jede Woche,
besprechen verschiedene Sachen und jeder nimmt dann
all diese Erkenntnisse wieder mit zurück in sein Unternehmen
und kann dann da das mal auf
sich wirken lassen. Und die Woche später sprechen wir noch
mal drüber, was denn da jetzt für
neue Erkenntnisse gekommen sind. Das wird
glaube ich eine ganz tolle Sache.
So, jetzt sehe ich unsere ersten
Chatmeldungen.
Mhm.
Ich glaube da, lieber Felix,
da steckt so viel drin, das kriegen wir jetzt zeitlich
nicht mehr unter. Oder was meinst du,
Luca? Weiß nicht, was steht denn da?
Am Beispiel der Datenbank, Leute von vorhin,
die stellen ein Produkt bereit
und ein typischer Interaction Mode
ist dann X as a Service.
Genau. Ja, das führt ja auch schon
viel weiter. Der Felix hat ein bisschen geschummelt, der hat
das Buch schon gelesen. Ist also
unschwer zu sehen. Ja,
weißt du, wie wir das machen? Wir nehmen
diese Sachen mit und reden
da in der nächsten Folge
des Podcasts drüber.
Jawohl. Nächste oder übernächste,
weil wir haben für die nächste Folge ja schon
ein anderes, altes Thema geplant. Ich habe
vorhin Tuckmen und Teams gesprochen. Die nächste Folge,
die sich mit diesem Buch befasst. So.
Und vielleicht,
vielleicht macht ja auch Felix mit.
Ja, dann eben.
Genau.
Also, wenn ich jetzt mal
gucke, wie gesagt, wir sind jetzt so ungefähr
bei den geplanten 45 Minuten.
Ich bin gespannt, wie das ankommt. Also ich bin gespannt,
auf die Kommentare. Wie sagt man so schön?
Schreibt die Kommentare hier unter,
unter das Video, wenn euch das
gefallen hat oder auch nicht gefallen hat.
Natürlich die, die Luca und mich kennen,
die können direkt auch die Kommentare zurückgeben,
wie euch das gefallen hat.
Die, die uns nicht kennen, die sollen bitte schon auch mit uns reden.
Das finde ich immer ganz toll, wenn Leute,
wenn Leute mit mir ins Gespräch
kommen. Ihr merkt ja, ich rede gerne.
Scheut euch nicht. Das wollte ich
gerade sagen. Die, die uns noch nicht kennen, die sollen sich
gerne bei dir oder bei mir melden und
einfach sagen, hey, hat mir gefallen.
Hat mir nicht gefallen, habe ich verstanden, habe ich nicht verstanden.
Vielleicht melden sich auch wirklich welche, die
dein Workshop oder Seminarangebot
eben nehmen wollen. Und
wir machen, wir machen weiter. Und
dann bin ich mal gespannt, wie es
wird, ob wir das zukünftig immer machen. Wer
weiß, ob wir daraus nicht quasi wirklich
einen festen Termin machen. Einmal im Monat
Liveaufnahme. Mal gucken. Also
ich fand es interessant. Es war mal ein ganz anderes
Gefühl. Es entfällt jetzt die
Arbeit des Podcast-Schneiden.
Und da muss ich mal gucken, wie mir das Ergebnis
gefällt an der Stelle. Schauen wir mal.
Gut. Also ich wäre durch,
Luca. Genau. Nee, ich fand das
toll. Vielen Dank, dass du da warst, Dirk.
Vielen Dank
auch allen sonst, die da waren.
Ein paar Zuschauer gibt’s.
Ich sehe die Statistiken. Ihr könnt euch nicht verstecken von mir.
Felix hat ja sogar
seinen Senf dazugegeben.
Also vielen Dank fürs Zuhören.
Vielen Dank fürs Dabeisein. Vielen Dank fürs Mitmachen.
Und auf bald. Auf bald.
Bis zum nächsten Mal.
Ciao.
Ciao.