Die zweite Folge zum Buch Team Topologies haben Dierk und Luca wieder live bei Youtube aufgenommen. Wir setzen unser Gespräch über das Buch fort. Dieses Buch liefert so viel Wissen und hilfreiche Beschreibungen über den Zweck von Teams und ihren inneren Aufbau. Es geht um 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. Das Buch gibt wertvolle Tipps zu den Themen:
• 4 grundlegende Topologien
• Zusammenarbeitsmodus der Teams
• Schnittstellen der Teams (APIs)
• Conways Law
• Organisationsgefühl
• Team first
• Entwicklung der Topologien
In dieser Episode von „DevOps auf die Ohren“ diskutieren die Gastgeber Dierk Söllner und Luca Ingianni intensiv über das Buch „Team Topologies“ und dessen Relevanz für den Aufbau hochperformanter IT-Organisationen. Sie erörtern verschiedene Teamtypen und deren Zusammenarbeitsmodi, wobei ein besonderer Fokus auf die Anpassungsfähigkeit der Teamstrukturen an sich ändernde Anforderungen gelegt wird. Es wird betont, dass ständige Überprüfung und Anpassung der Team-Zusammenstellungen entscheidend für den Erhalt des Workflows und der Effizienz sind. Der Podcast beinhaltet auch Diskussionen über praktische Anwendungen und Herausforderungen bei der Implementierung dieser Konzepte in realen Arbeitsumgebungen.
Inhalt
- Einführung und Neujahrsgrüße
- Überblick über „Team Topologies“ und dessen Bedeutung in DevOps
- Diskussion der verschiedenen Teamtypen und ihrer Funktionen
- Die Wichtigkeit von dynamischen Teamstrukturen und Anpassungsfähigkeit
- Zusammenarbeitsmodi der Teams und deren Auswirkungen auf Effizienz
- Die Bedeutung von Conway’s Law in der Teamstruktur
- Organisationsgefühl und die Rolle der Teamautonomie
- Praktische Herausforderungen und Lösungen bei der Implementierung von Team-Topologien
- Ankündigung und Details zu Luca Ingiannis Workshop
Shownotes:
Video zur Live-Aufnahme der Folge
Workshopangebot von Luca
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
So, hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren
und ins Hirn, gestaltet und produziert von Dierk Söllner und Luca Ingianni.
Und da das ja die Januar-Folge ist, alles Gute zum neuen Jahr für euch alle.
Ich sag auch, alles Gute zum neuen Jahr.
Auch wenn es schon ein paar Tage alt ist, aber man darf ja, glaube ich, noch alles Gute wünschen.
Und ich freue mich auf ein nicht so ganz verrücktes Jahr 2021.
Ja, das wäre mal erholsam, ne?
Ja.
Naja, also, wir sind beide DevOps-Trainer und Coaches mit langjähriger Erfahrung
und unterstützen dabei, hochperformante IT-Organisationen aufzubauen.
Also, DevOps umfasst für uns beide kulturelle, organisatorische und technische Aspekte.
Diese diskutieren wir hier im Podcast mit Experten aus der Praxis
oder, so wie jetzt, in einer gemeinsamen Folge.
In der letzten Folge hatten Dirk und ich ja über das Buch Team Topologies gesprochen
und festgestellt, dass man mit einer einzelnen Podcast-Folge diesem Buch eigentlich nicht gerecht werden kann.
Insofern folgt jetzt der zweite Teil dieser Debatte.
Aber bevor wir da rein starten, möchte ich gerne noch zwei Sachen sagen.
Das Erste ist, wir haben ja eine höhere und höhere Umfrage.
Den Link dazu findet ihr dann in den Shownotes.
Und wir würden uns wirklich freuen, wenn sich noch mehr Leute dann beteiligen würden.
Die eine oder andere Zuschrift haben wir schon und die ist auch wirklich sehr hilfreich,
einfach damit wir diesen Podcast noch spannender für euch gestalten können.
Aber natürlich, je mehr Leute ihren Senf dazugeben, desto besser wird das Ganze.
Insofern fühlt euch ermutigt.
Ich sage immer, an dieser Umfrage teilzunehmen, dauert nicht länger, als eine Banane zu essen.
Insofern, ich habe volles Vertrauen, ihr schafft das.
Jawohl, okay.
Und du hast ja von dem Senf gesprochen, den man dazugeben kann.
Das kann ein scharfer Senf sein, das kann ein süßer Senf sein.
Hauptsache, dass wir einfach ein bisschen was von euch mitbekommen, von euch ein bisschen was hören.
Luca, du hast eben die Shownotes angesprochen.
Ja, das ist richtig.
Ja, das ist richtig.
Ja, das ist richtig.
Ja, das ist richtig.
Ja, das ist richtig.
Ja, das ist richtig.
Es gibt das ein oder andere Portal, was die Shownotes nicht darstellt.
Ich glaube, bei Spotify kann man das nicht unbedingt sehen.
Also, falls irgendjemand auf unsere Hinweise von den Shownotes die Shownotes nicht findet
in seinem Portal, gerne auch auf uns zu kommen.
Wir haben ja auch den Link dann quasi, wo man auf jeden Fall die Shownotes dann auch sehen kann.
Wir haben ja den Podcast auf einer Plattform, wo man, wie gesagt, die Shownotes nochmal verlinken kann.
Genau.
Und das andere ist…
Ich möchte nochmal darauf hinweisen, auch dafür werdet ihr einen Link in den Shownotes
findet, sofern ihr die Shownotes findet.
Ich werde im März einen Workshop veranstalten, oder März und April muss man sagen, der sich
genau mit den Themen des Buches beschäftigt.
Wenn ihr also Lust habt und Interesse habt, nicht nur konsumierend und passiv diesen Podcast
zu hören oder dieses Buch zu lesen, sondern wenn ihr aktiv mit Gleichgesinnten, mit anderen
Themen das durchdenken und bearbeiten wollt, dann lade ich euch herzlich ein, an diesem
Workshop teilzunehmen.
Einen entsprechenden Link zu dem Workshop werdet ihr dann, wie gesagt, auch in den Shownotes finden.
Super.
Oder eben auch direkt bei dir Kontakt aufnehmen.
Hat man beim Messner ja auch.
Gerne.
Wir sind überall da zu finden, wo Digitales passiert.
Okay.
Ja, dann würde ich sagen, dann lasst uns einsteigen in das Buch Team Topologies.
Wir haben das ja beim letzten Mal schon über den grünen Klee gelobt.
Wir haben so viel zu besprechen gehabt und haben ja gesagt, wir machen nochmal weiter.
In Anknüpfung an die letzte Folge, in der letzten Podcast-Folge, nochmal so ein paar
Punkte, über die wir heute so ein bisschen sprechen wollen.
Im Buch, gerade hinten im letzten Teil, gibt es nochmal so einen Überblick über sieben
wichtige Elemente, die in dem Buch im Prinzip so überblicksmäßig besprochen werden.
Es geht um vier grundlegende Topologien, logischerweise.
Sollten in einem Buch, was Team Topologies heißt, auch Topologien bearbeitet werden.
Das haben wir beim letzten Mal besprochen.
Also vier grundlegende Topologien haben wir beim letzten Mal abgehakt.
Offen waren die beiden Punkte Zusammenarbeitsmodus der Teams.
Also wie arbeiten diese Teams zusammen?
Was hat das Buch dazu zu sagen?
Der nächste Punkt, Schnittstellen der Teams.
Auch da müssen wir heute noch drauf eingehen oder werden wir noch drauf eingehen.
Haben wir beim letzten Mal auch nicht gemacht.
Ein weiterer Punkt.
Ein weiterer wichtiger Punkt ist ja Conway’s Law in dem Buch.
Das Buch setzt ja quasi auf Conway’s Law auf.
Da haben wir uns lang und breit darüber unterhalten.
Dann gibt es so den Punkt, das Gefühl einer Organisation oder Organisationsgefühl.
Das vertiefen wir heute nochmal ein bisschen.
Da haben wir beim letzten Mal so ein bisschen was angerissen.
Das werden wir, wie gesagt, vertiefen.
Der nächste Punkt, der auch noch offen ist, ist das Thema Team First.
Auch da sollte man sicherlich erwarten, dass in einem Buch was Team First ist.
Auch da sollte man sicherlich erwarten, dass in einem Buch was Team First ist.
Aber Team Topologies heißt, was über Team besprochen wird.
Team First machen wir heute noch und dann die Frage, wie können wir diese Topologien entwickeln.
Es ist ja immer schön, im Buch was zu lesen.
So geht das oder so sollst du das machen.
Immer die Frage, wie kommt man da hin.
Immer die Frage, wie kommt man da hin.
Also das heißt das Thema, wie entwickeln sich die Topologien.
Das vertiefen wir heute nochmal ein bisschen.
Das vertiefen wir heute nochmal ein bisschen.
Also mal ganz kurz, um auch reinzukommen.
Luca, wir hatten ja was über die Team Typen gesprochen.
Luca, wir hatten ja was über die Team Typen gesprochen.
gesprochen oder erzählt beim letzten Mal,
wie, kannst du das mal ganz kurz
wiederholen? Genau, ja, also
das Buch, einfach um euch nochmal abzuholen an der
Stelle, beschreibt ja vier
grundlegende Arten von Teams, nämlich
einerseits die Stream-Align-Teams,
ich sage jetzt mal
unser ganz gewöhnliches
Quote-unquote
Wald-und-Wiesen-DevOps-Team,
cross-funktional,
hat eine bestimmte Aufgabe
in Bezug auf das Produkt,
in Bezug auf
Kunden
fokussierte
Arbeiten, die da
gemacht werden müssen. Das zweite sind
Enabling-Teams,
die
innerhalb der Organisation wirken,
die also in irgendeiner
Weise
andere Teams unterstützen, ich sage
jetzt zum Beispiel mal in Bezug darauf,
ihre eigenen Zusammenarbeitsweisen
weiterzuentwickeln, beispielsweise.
Das sind also eher beratende
Teams in diesem Sinne.
Das nächste waren Complicated-Subsystem-Teams,
die man
nicht haben muss, aber eventuell
haben könnte. Das sind
solche, die wirklich nur
einen ganz kleinen, aber irgendwie verzwickten
Bereich
beackern, des Produkts.
Ich sage jetzt mal den zentralen, ich weiß
auch nicht, KI-Algorithmus eures Produkts
oder sowas. Da sind dann irgendwie die ganzen
promovierten Mathematiker oder sowas, die
machen echt nur dieses eine kleine Eckerl.
Und sind in dem Sinne
auch gar nicht mehr wirklich kundenfokussiert,
weil die machen wirklich
nur so ein Fetzen
von all dem, was da noch
dazugehört. Einfach, weil das für sich schon
so verteufelt ist.
Und zuletzt
gibt es Plattform-Teams,
die, wie es der Name schon
andeutet, eine Plattform
zur Verfügung stellen, eine Dienstleistung
zur Verfügung stellen, die wiederum nach
innen gerichtet ist, die den anderen
Teams irgendwie ermöglicht,
effektiv
und effizient
voranzuschreiten. Das sind die Leute, die
vielleicht die Server
Dienste
bereitstellen,
wobei die natürlich ihrerseits
auch einen
Kundenfokus haben,
einen cross-funktionalen
Zuschnitt haben, ganz klassische
DevOps-Teams sind, bloß deren Kunden sind halt nicht
extern, sondern die sind intern.
Das sind dann wiederum zum Beispiel
viele Streamer-Line-Teams.
Okay.
Das heißt also, dass, was ich da so
schön finde, ist, dass es so eine Erweiterung ist.
In unseren Unterlagen, wir haben ja Produkt-Teams,
Plattform-Teams, finde ich,
das ist ja auch ein wichtiger Punkt, den du
immer wieder ansprichst. In dem Buch stehen
Dinge drin, die, wenn man sie liest,
die einem sozusagen dann als total
natürlich erscheinen. Und mit diesen vier
Teams, denke ich, kann man so schön
eine teamorientierte Sichtweise auf
die Organisation aufbauen.
Gut. Lass uns weitermachen. Also die Teams
haben wir jetzt nochmal ganz kurz dargestellt.
Was ist das Ziel überhaupt?
Warum gibt es diese Team-Organisationen?
Und was ist das Ziel,
was in dem Buch beschrieben wird?
Da gibt es natürlich auch was dazu im Buch.
Und haben wir beim letzten Mal auch besprochen.
Es geht um Flow. Das heißt, wie kriege
ich einen Flow in der Organisation
hin? Wie kriege ich die Organisation
so gestaltet, so aufgebaut,
damit der Flow eben da ist?
Also damit es schön, schnell und
einfach durchgeht durch die Organisation.
Da haben wir beim letzten Mal
gesprochen über die kognitive Last.
Etwas, was ich in dem Buch zum ersten Mal
gelesen habe, was für mich
auch diesen Punkt hatte. Ey, stimmt.
Es steht da und es ist total logisch.
Also wichtig ist, dass wir mit der
Organisation, mit der Team-Topology
oder den Team-Topologies
die kognitive Last in den
Teams senken. Dass wir das eben
beachten, dass wir uns darüber Gedanken machen, dass wir das
senken. Und drittens
geht es bei den Team-Topologies
auch immer darum, die Autonomie
der Teams sicherzustellen.
Also, dass die Teams wirklich autonom arbeiten,
können. Da kommen wir nachher bestimmt noch mal
drauf, wenn wir über Kommunikation reden.
Weil es muss ja auch einen Grund geben, warum die Teams
autonom sein sollen und was Autonomie
mit Flow zu tun hat. Aber
das, um noch mal ganz kurz zu sagen, das ist
das Ziel quasi, was man
mit Team-Topologies
verfolgt.
Und jetzt, glaube ich, ist der richtige Zeitpunkt
gekommen, um in etwas
einzusteigen, was wir eben das letzte Mal nicht mehr
geschafft haben.
Nämlich, wir haben jetzt diese
vier verschiedenen Arten von Teams
und jetzt haben wir da irgendwie…
so einen Haufen von Teams, die sind jetzt irgendwie so alle mal da,
aber was machen die jetzt miteinander?
Wie
arbeiten die zusammen? Wie
interagieren die? Und auch dafür
bietet das Buch
eine Systematik. Die sagen, es gibt
drei grundlegende Arten
der Zusammenarbeit, nämlich
einerseits tatsächlich direkte
Zusammenarbeit. Zwei Teams
kooperieren in irgendeiner Weise.
Sie haben, was im Buch
genannt wird, Access-as-a-Service. Also
ein Team stellt eine Dienstleistung
bereit für
eins oder viele andere Teams.
Oder es gibt den Modus der Facilitation.
Dass also dieses Team
dabei hilft,
innerhalb eines anderen Teams zu wirken
und dieses Team irgendwie
weiterzuführen
und dann vermutlich auch
wieder weggeht.
Das ist ganz spannend.
Wie sieht das denn jetzt aus?
Facilitation, das sind
die
das ist bestimmt so ein klassisches Team
von, ich sag jetzt mal, agilen Coaches
zum Beispiel. Das wäre vielleicht ein Beispiel dafür.
Die kommen her, die helfen
einem Team, neue Fähigkeiten
für sich selbst zu entwickeln
und begleiten dieses Team
und nach einer Weile
gehen sie wahrscheinlich auch wieder raus.
Oder ziehen sich weitgehend zurück.
Sind bestimmt immer noch irgendwie
bei der Hand, wenn man nochmal das Gefühl hat,
Hilfe zu brauchen. Aber es soll eben nicht so sein, dass
eine Abhängigkeit entsteht.
Wie sie
und um das zu sagen, Facilitation
kann ja auch nicht nur sein
im Sinne von zum Beispiel agilen Coaching,
sondern es kann auch sein, dass da wirklich ganz klassisch
Wissen vermittelt wird. Angenommen,
keine Ahnung, ihr wollt jetzt Kubernetes
einführen in eure Organisation. Vielleicht gibt es
da ein Facilitating Team
mit Leuten, die Ahnung von Kubernetes
haben. Die kommen rein,
die helfen mal die grundlegende Architektur
aufzusetzen, die
schulen die Entwickler in dem Team,
solange bis die auf eigenem Bein stehen können
und dann gehen sie wieder und wenden sich
dem nächsten Team zu und helfen dort mit.
Ein bisschen was anderes
ist der Modus, der im Buch genannt wird
Zusammenarbeit. Da sind
zwei Teams, die gemeinsam
etwas
bauen. Das ist typisch dann
der Fall, zum Beispiel
wenn man etwas Neues
aussetzen will, zum Beispiel in Kubernetes
und aber noch nicht so richtig weiß, wohin man will
oder sowas, dann gibt es,
sage ich mal, ein Team, das gerne
Kubernetes nutzen möchte und ein Team,
das gerne Kubernetes betreiben möchte
und die beiden
raufen sich dann irgendwie zusammen
und fangen gemeinsam
an, dieses neue Ding zu entwickeln,
zu bauen, zu konzeptionieren
und wiederum, das ist etwas, was
nicht auf Dauer angelegt sein
sollte und dürfte,
sondern wahrscheinlich
wird dann das, ich sage jetzt mal,
Kubernetes-Betriebsteam,
das Team, dem Kubernetes gehört,
wird sich irgendwann mal zurückziehen und sagen,
wir bieten euch das jetzt an, as a service,
X as a service und die
anderen nutzen diesen Dienst und dann wird
aus einer Kollaborationsbeziehung eine
Auftraggeber-Auftragnehmer oder
Kunden oder wie auch immer man es nennen möchte
Beziehung. Macht es Sinn soweit, Dirk?
Ich überlege jetzt gerade,
ja, auf jeden Fall,
X as a service kommt ja gleich noch, aber ich habe gerade
überlegt, so im Rückblick,
ich habe ja meine ersten Projekte
und ersten Unterstützungen von ein paar
Jährchen gehabt und in einem meiner ersten
Projekte war es wirklich so, dass bei
dem Kunden, ich glaube, sieben oder acht
Scrum-Teams aufgesetzt waren,
die haben aber schon ein bisschen mehr gemacht
als nur Entwicklung, haben also
auch ein bisschen Betrieb mitgemacht,
ist ja auch schon sieben Jahre her oder acht
Jahre schon fast
und die hatten
auch zum Beispiel das Thema
Testautomatisierung und da glaube ich,
im Rückblick hatten wir ein Facilitation-Team,
das heißt, es war ein Team,
das waren, glaube ich, auch nur zwei oder drei,
Experten, die wirklich als
Experte sich mit Testautomatisierung
im SAP-Umfeld,
ja, da waren sie die
Experten und drei Leute, da kommt mein
alter Witz, drei Menschen auf sieben Teams
aufteilen, das geht nicht so einfach
mit der blutigen Angelegenheit, den Witz,
den kennen wir schon und die sind aber,
glaube ich, diese drei Leute sind immer in den Teams
quasi umhergelaufen, also nicht tagtäglich,
sondern sie haben in den Sprints
mitgewirkt und das, glaube ich, wäre
ein sehr schönes Beispiel dafür, dass man
eben auch sagt, man hat weiterhin die
Experten, wenn ich,
so wie ich Scrum verstehe, sagt ja Scrum,
naja, die Experten, die müssen zu Generalisten
werden und so wie ich das
Team-Topologies hier verstehe, ganz klar,
es gibt weiterhin auch
die Notwendigkeit für Experten und
die Experten hier als Facilitation-Team
helfen den anderen
mit dem ganz klaren Ziel zu helfen
und auch wieder rauszugehen, also nicht
quasi wirklich sich in einem Team
unablässig
oder sich im Team
unentbehrlich zu machen, jetzt haben wir es,
im Team unentbehrlich zu machen,
sondern wirklich unterstützen, helfen als Experte
und dann wieder rausgehen und wenn dann im Team
irgendwann mal Fragen sind, dann können sie ja wieder helfen.
Also insofern, bis hierher finde ich passt das
und du hast ja gesagt, oder wir haben ja weiter
festgestellt, dass wir bei dem Buch
so viele Dinge sehen, die wir auch in der
Praxis quasi vorher erlebt
haben, entweder als Schwierigkeit,
die nicht gelöst wurde
oder wirklich als
gelöstes Problem. Also hier
Facilitation habe ich auch in der Praxis
schon erlebt und ist auch schon ein bisschen länger her.
Das finde ich jetzt interessant, dass du das gerade
sagst von Schwierigkeiten.
Hast du da irgendwie gerade was präsent, wo
eine Schwierigkeit
bestehen könnte, wenn ich jetzt so eine Anordnung
habe?
Also Schwierigkeit,
also mir fällt jetzt keine
gerade wirklich konkrete ein,
aber ich sehe immer wieder die Schwierigkeit,
wenn man jetzt rein nur mit der
Scrum-Lehre drauf guckt,
mit dem, was in Scrum geschrieben wird,
wenn die Unternehmen, also letzten Endes,
seit Jahren schon mit Scrum
arbeiten, mal besser, mal schlechter
und dann kommt das Thema Betrieb
mit dazu, dann will man den nächsten
Reifegrad entwickeln, dass sie
dann häufig quasi
mein Verständnis
in den
anderen Frameworks, die wir haben,
also Scrum und so weiter,
vielleicht gar nicht mehr so eine richtige Antwort finden.
Also das ist für mich eben
glaube ich auch ein Punkt,
der für das Buch spricht, dass das Buch
da letzten Endes aus der Praxis
konkret Vorschläge macht, wie man
mit diesen Schwierigkeiten umgehen kann.
Also wie gesagt, was ist, wenn ich den Betrieb mit
dazunehme,
wie gehe ich damit um, wenn ich wirklich noch
mehr Arbeit zusammenbringen muss
und das wirklich auch mit,
nicht nur mit Entwickeln und über den Zaun werben,
sondern wirklich auch mit, wenn ich an Betriebs denke.
Ja, es ist interessant.
Das war nämlich auch etwas, was mich
unterschwellig schon immer gestört hat am Agilen,
dass die da sich so ein bisschen aus der Affäre gezogen
haben und gesagt haben, wir kümmern uns nur um
ein Team.
Damit ist es ja in der Regel nicht getan.
Und hier habe ich jetzt irgendwie etwas, was mir
auch so ein schönes Vokabular und so ein schönes
Instrumentarium liefert,
wie es zum Beispiel die Agilität macht,
um nicht nur innerhalb eines Teams
nachzudenken, wie soll es denn laufen, sondern auch
zwischen Teams, wie soll es denn laufen.
Aber es ist
vielleicht sollte man
eine Schwierigkeit oder eine Gefahr,
so muss man es nennen, man sollte eine Gefahr vielleicht erwähnen.
Nämlich, wenn ich diese drei Modi habe,
dann sieht man schon, zwei
dieser drei Modi
sind mehr oder weniger
auf Zeit angelegt.
Facilitation auf jeden Fall.
Der gesamte
Ansatz dahinter ist, man macht das für eine Weile und dann
hört man auf damit.
Zusammenarbeit,
na gut, das kann auch bestehen bleiben,
aber ich denke, die Intensität sollte
variieren. Am Anfang muss man bestimmt
sich mehr zusammensetzen und mehr Sachen gemeinsam
planen, aber
nach einer Weile muss das
auch aufhören.
Nach einer Weile muss man
es dann schaffen, sich wieder voneinander zu
entkoppeln
und idealerweise dorthin
zu kommen, dass man sagt, X as a Service, das ist
quasi maximale Entkopplung. Natürlich
hat man eine Entkopplung in dem Sinne, dass einer es anbietet
und der andere es nutzt, ja, ja, schon.
Aber jeder macht irgendwie so sein Ding.
Und eigentlich
besteht dazwischen nur so eine
Schnittstelle, so eine API, wenn man möchte.
Das heißt, wir haben…
Wir haben jetzt im Prinzip die vier Teamtypen,
wir haben die drei Zusammenarbeitstypen, mit denen
man wirklich, sagen wir mal, die Realität sich
erklären kann. Damit kannst du
Architekturen, kannst du Interaktionen
beschreiben und verstehen.
Aber ich habe bei dem auch schon rausgehört,
so ganz statisch ist das ja nicht, weil
das wäre ja sehr schön.
Ich nehme das Buch,
nehme meine Menschen, packe die in irgendwelche Teams rein
und sage, so, und ihr macht jetzt Zusammenarbeit,
ihr macht Facilitation. Also,
das ist ja ein bisschen komplexer als
in der Realität, oder die Realität
ist komplexer.
Wie würdest du denn damit umgehen?
Was hast du aus dem Buch da rausgelesen?
Das ist eben auch das ganz Tolle
an diesem Buch, dass es mir endlich
ein
Koordinatensystem gibt
und zu verstehen, was passiert denn da
innerhalb meiner Organisation. Weil genauso
wie du sagst, es soll halt überhaupt nicht
statisch sein. Es ist eben…
Man verwendet dieses Buch nicht, um da jetzt ein
Org-Chart zu bauen, und das gilt für die nächsten fünf Jahre
oder sowas,
sondern
das muss…
Das muss dem Wandel unterworfen sein.
Wir haben ja schon darüber geredet,
eines der wesentlichen Ziele ist
Autonomie-Management von kognitiver
Last, und wenn ich jetzt zum Beispiel
eine Facilitation-Beziehung
hätte zwischen zwei Teams,
und die hört einfach nicht auf,
dann sind die natürlich wahnsinnig eng gekoppelt
und völlig unautonom.
Und
es ist anzunehmen, auch die
kognitive Last zum Beispiel wäre sehr hoch.
Flow wäre sehr schwierig zu erreichen.
Also,
mit anderen
Worten,
es muss ganz klar sein, dass alle diese
Sachen dem Wandel unterworfen
sind, und man hier nur einen Satz von
Werkzeugen hat, um zu verstehen,
bin ich noch in einer guten Situation, oder
muss ich vielleicht einen Wandel auch aktiv herbeiführen?
Muss ich zum Beispiel sagen, pass mal auf,
liebes
Team, dass
ihr eine Facilitation bekommt, ihr müsst
jetzt mal schaffen, auf eigenen Beinen zu stehen.
Wir können nicht ewig so weitermachen.
Ihr müsst selbstständiger werden.
Oder ihr müsst loslassen.
Also, es kann ja auch sein, dass ein Team nicht loslässt.
Ja, ja, vollkommen richtig, genau.
Aber jedenfalls, da hast du jetzt plötzlich
die Begriffe, um zu sagen, pass mal auf, so sollte die Beziehung
aussehen, schaut die denn noch so
aus? Das finde ich auch so schön.
Das ist im Prinzip das, was wir
als Ziele im ersten Podcast hatten.
Flow, Management der kognitiven
Last und die Autonomie. Das heißt,
ich baue jetzt nicht die Teams
so, dass, wie du sagst, fünf Jahre oder drei
Jahre, wie auch immer, ich muss ja noch nicht mal unbedingt
eine Zeitaktie dranlegen,
und ich gucke eigentlich immer wieder,
habe ich einen guten Flow, sind die Teams
autonom genug, habe ich die
kognitive Last im Griff an der Stelle?
Und wenn das nicht gegeben ist, dann
muss ich wieder gegensteuern, indem
ich irgendetwas verändere.
Genau.
Letzten Endes geht
man komplett weg von diesem Organigramm und
sagt eben nicht mehr, genau so müssen
diese verschiedenen Lego-Steine jetzt zusammen
gesetzt werden, sondern
erreiche ich noch meine
grundsätzlichen Ziele? Habe ich
noch einen Flow, der mich
zufriedenstellt? Ist meine kognitive
Last so, wie ich sie mir wünschen würde?
Ist es mir gelungen, meine Teams
autonom zu gestalten oder verfilzen
die? Weil das ist ja auch etwas,
was passiert, wenn du nicht aktiv gegensteuerst,
wird sowohl deine Produktarchitektur
im Laufe der Zeit
sich immer enger koppeln, so Sachen rutschen
die einfach durch, und auch die Leute.
Und bloß, um das richtig zu verstehen,
natürlich sollen die Leute
zusammenarbeiten und sich aushelfen,
und auch unbürokratisch irgendwie Hand in Hand
arbeiten. Natürlich.
Selbstverständlich. Aber
nicht um den Preis,
dass einer nicht mehr ohne den anderen
kann.
Okay, also, wenn wir das jetzt mal zusammenfassen,
haben wir die Viererkette,
wir haben vier Teamtypen, wir haben
drei Zusammenarbeitstypen und drei Ziele,
also 4-3-3. Wenn wir noch den Torwart
dazu packen, haben wir die
Fußballspieler.
Jetzt haben wir das damit,
ein Instrumentarium, eine Struktur,
zu gestalten. Wir haben eben gesagt,
wir können immer mal wieder, oder müssen immer mal wieder
verändern. Der nächste
Punkt, den wir hatten, der offen
war aus dem letzten Podcast,
auch der aus der letzten Folge war,
das Thema Schnittstellen der Teams, also
APIs zu gestalten.
Und so ganz
glücklich sind wir beide damit nicht so
mit dieser Überschrift und mit
diesem Thema, oder?
Ja, also, es ist halt
ein ganz heißes Eisen,
weil das ist etwas,
was das Buch ausdrücklich
sagt. Jedes Team sollte
eine definierte Schnittstelle haben zu anderen Teams,
sollte ein Team-API haben, wenn man so will.
Und das ist vollkommen
richtig. Man sollte
durchaus definieren, was biete ich anderen an,
oder was bekomme ich von anderen,
oder was benötige ich von anderen.
Man sollte das explizit machen,
damit man auch zum Beispiel in der Lage
ist, zu überprüfen,
bekomme ich denn das, was ich benötige?
Oder liefere ich das, was die anderen benötigen?
Aber ich finde,
da besteht eine Gefahr drin,
insbesondere mit diesem Begriff Team-APIs.
Die sind ganz toll
für
entwicklungsmäßig vorbelastete Team-Mitglieder,
weil die darunter sofort was verstehen.
Und das ist die große Gefahr, weil
ein, glaube ich,
ein ganz großes
Sogkraft dieses Begriffes
besteht, und dann fangen die Leute an, irgendwelche APIs
zu definieren und die womöglich ganz
fein zesiliert auszuarbeiten. Da muss man sich, glaube ich,
wahnsinnig zusammenreißen.
Dass man da nicht anfängt, rumzuspielen
und dann plötzlich wieder in so einen starren
Prozess mit einem 400-seitigen
Prozesshandbuch reinkommt, wo man genau
davon weg wollte.
Das ist für mich die Gefahr dabei,
dass man da den Leuten
irgendwie plötzlich was gibt, wo sie sich
daran festhalten können, weil sie sagen, oh, das verstehe ich,
das ist mir bekannt, und jetzt geht’s los.
Du hast ja vorhin auch nach Praxisbeispielen
gefragt. Ich habe interessanterweise in einer meiner
letzten DevOps-Schulungen auch
von einem größeren Konzern,
der schon ziemlich lange an der Stelle
arbeitet, und da war ein
Teilnehmer dabei, der genau gesagt hat,
dass sie das haben. Das heißt, wenn sie
ein neues Team jetzt aufsetzen
oder in den letzten Jahren aufgesetzt haben,
dann war eine ganz wichtige
Aufgabe für das Team, genau so
etwas zu tun, also zu beschreiben,
was sie denn liefern, also
was sie wirklich, also auch was man sie dann ja auch
ansprechen oder
festnageln kann. Also die haben das getan,
und das Ziel war, das auf zwei Seiten
zu bringen. Also das hat er eben explizit
betont, gesagt,
das ist eine der ersten Aufgaben,
dass sie beschreiben auf ein bis zwei
Seiten, und das eben ziemlich, ziemlich konkret.
Nicht so, wir schaffen das beste System
der Welt und retten die Welt,
sondern das liefern wir, das liefern wir
und das liefern wir, und
dafür auch immer
Ansprechpartner. Also all die,
die von diesem Team Leistungen
bezogen haben, wussten, wenn es nicht
klappt, da haben sie eine Telefonnummer
oder einen Chatkanal
oder eine E-Mail. Also
wirklich, die haben sich festgelegt, auch auf
die wirklich Kommunikationsschnittstellen
von außen. Und wie gesagt, die eigenen
Leistungen, das, was sie liefern,
war das Ziel, auf maximal zwei
Seiten zu beschreiben. Keine Ahnung,
ob das funktioniert, aber
fand ich eine sehr interessante
Überlegung, und da zeigt sich auch, dass das
Buch jetzt nicht wissenschaftlich vordenkt,
sondern eigentlich Dinge aus der Praxis beschreibt.
Ja.
Das ist auch etwas, was ich aus meiner eigenen
Praxis leidvoll so gut
kenne, in Bezug auf meine eigenen
Kunden. Es ist nämlich ganz selten,
dass man einen Kunden hat,
der überhaupt sich in der Lage sieht,
im Voraus zu sagen, was er von mir gerne hätte.
Weil ich würde zum Beispiel häufig
ganz gerne nicht
auf Stundensatzbasis arbeiten, sondern irgendwie
auf Fixpreisbasis und sagen, pass mal auf,
hier ist die Aufgabe, die kostet Summe X,
aber ganz häufig erlebe ich, dass die Kunden überhaupt nicht in der Lage sind,
zu formulieren, was ich eigentlich bei ihnen soll.
Das passiert wahrscheinlich eben nicht nur nach außen, sondern auch
nach innen, dass man sagt, ich stelle jetzt
irgendwie so ein Team auf, und dann überlegen wir uns mal,
was das Team eigentlich tun soll und für wen.
Und insofern
ist das super, wenn man das so macht,
wie du das gerade überschrieben hast, Dirk,
dass man sich erstmal hinsetzt und sagt so vorher,
was ist denn die Daseinsberechtigung
für dieses Team? Was machen die denn?
Warum brauche ich die denn eigentlich? Und wenn mir nichts
einfällt, ja, dann gibt es das
Team nicht.
Wollte ich gerade sagen. Und wenn mir nicht genug
einfällt, also gefühlt genug,
es ist ja die Frage immer,
wann ist es genug? Aber wenn das Team
sagt, Mensch, ja, wir haben da was, aber
die Abnehmer, die Kunden sagen, das reicht,
dann ist das ja auch genau der Punkt, da muss man
eben als Team sich entwickeln
und die Schnittstellen nach und nach anheben.
Also nach und nach mehr Leistung
mit reinpacken, anstatt
zu sagen, ich warte jetzt ein halbes
Jahr, bis ich all das beschreiben kann
und liefern kann, was ich denn tun soll.
Sondern das ist ja auch etwas
Lebendes an der Stelle. Gut.
Schnittstellen der Teams. Fällt dir
dazu noch irgendwas ein, wenn ich jetzt hier mal
den Moderator
mache?
Zu den Schnittstellen
nicht, aber es scheint natürlich,
danach, dass man diesen ganzen
Faden jetzt weiterspinnt. Das heißt, du willst
zum Thema Organisationsgefühl was sagen?
Genau. Weil das ist, glaube ich,
das, worauf auch alle
Zuhörer schon so ein bisschen warten, weil es
ergibt sich ja so ein bisschen.
All die Sachen, die wir jetzt
dort erarbeitet haben, oder die
das Buch erarbeitet hat,
Teamtypen,
Zusammenarbeitsarten,
Wege, diese
Zusammenarbeit auch explizit zu machen
und zu kartieren über Team-APIs zum Beispiel,
die führen dazu,
dass man
ein Gefühl entwickeln kann
für diese Organisation.
Dass man sagen kann, fühlt sich die noch richtig
an? Macht die, was sie soll?
Und das ist etwas,
was natürlich wahnsinnig machtvoll und spannend
ist und was, glaube ich,
vielen Organisationen
noch so ein bisschen abgeht. Oder beziehungsweise,
nee, das stimmt nicht, sondern jeder hat ja
so ein Gefühl, rein intuitiv.
Passt das so? Arbeite ich
gut mit meinen Kollegen zusammen? Arbeite ich
gern mit meinen Kollegen zusammen? Oder
graust es mir schon davor, irgendwie wieder zu einer
Besprechung mit diesem Team zu gehen, weil das
artet dann immer irgendwie aus in
irgendwelche hypothetischen
Wolkenkuckucksheime oder sowas?
Muss ja gar nicht Streit sein.
In der Regel kommen die Leute ja gut miteinander aus.
Das finde ich immer
ganz versöhnlich, das zu sehen, auch in Trainings.
Die Leute sind ja alle
vom Grundsatz her vollkommen konstruktiv
und freundlich
und gewillt.
Anderen zu helfen.
Aber trotzdem, wenn sich das dann irgendwie ungut
anfühlt, dann hatte man bislang, glaube ich, wenig
Chancen, wirklich den Finger
da drauf zu legen und zu sagen, pass mal auf,
deswegen stimmt es nicht, weil diese zwei Teams
irgendwie in einer ungünstigen
Anordnung sich befinden. Und jetzt
hat man plötzlich diesen Hebel.
Ja, weil für mich
ist das Buch da oder gibt das Buch
letzten Endes eigentlich auch so eine Art
Kompass oder so eine Art Hinweis, auf was man
denn achten sollte. Denn was
ich dann erlebe,
was du eben auch
beschrieben hast, die sind zwar alle nett miteinander,
aber dann kommt doch häufig der ein
oder andere, der mit
etwas quasi von außen kommt. Also
dann wird gesagt, ja, Scrum sagt
aber, das sollten wir so und so machen.
Oder Service Management
sagt, wir sollen das so und so machen. Also dann
kommt der ein oder andere mit einem Blick von
außen und sagt, irgendwo in einem Buch
steht, dass man das so machen sollte. Und
ich will Team Topologies so verstehen.
Ich habe die Ziele. Ich habe
diese 4-3-3-Kette da sozusagen.
Also ich habe die Typen, ich habe den Zusammenarbeitsmodus
und die 3 Ziele.
Und dann, sage ich immer wieder,
fühlt sich das noch gut an für die
Organisation in Bezug auf diese 3
Aspekte, die wir bisher schon erläutert
haben. Das heißt, das ist für mich eben
der Vorteil, dass die
Organisation eigentlich eher so ein bisschen
da angeleitet wird, selber wirklich
zu fühlen. Jetzt kann man sich natürlich
fragen, ob Organisationen fühlen dürfen.
Ich würde sagen, ganz klar
ja, auf jeden Fall. Aber
das ist eben das Schöne. Wie gesagt,
keine Vorschrift. So
sollte das sein. Und wir überlegen,
wie gut wir sind. So einen Reifegrad am besten
auch noch ermitteln. Sondern, fühlt sich das
gut an? Sind wir noch im Flow?
Haben wir eine passende Kommunikation? Ist die
kognitive Last, haben wir die im Griff?
Wie fühlt sich das an? Das finde ich hier sehr, sehr
schön dabei.
Und das ist, glaube ich, auch einer
der ganz wichtigen
Aspekte von diesem Buch.
Das habe ich jetzt schon öfter gesagt, dass es
einem ein Vokabular
gibt.
Ich habe am Anfang des Buches auch,
so ein bisschen drüber genörgelt bei mir und
habe gesagt, ja, gibt es wirklich nur
vier Teamtypen oder müssten es nicht mehr sein
oder weniger oder andere? Und ich bin
jetzt darauf gekommen, es ist total wurscht.
Sondern diese vier Teamtypen, die sind
ziemlich gut überlegt. Vielleicht könnte man es noch ein bisschen
schöner machen.
Spielt aber keine Rolle. Ich habe Begriffe.
Ich habe
Wege zu artikulieren,
ob ein Team
mehr von dieser Art oder mehr
von jener Art sein solle und ob eine
Zusammenarbeit eher so oder eher so
aussehen sollte.
Und das ist die ganz große
Stärke. Ich habe
jetzt ein
Fingerspitzengefühl entwickelt
für Organisationen, für
Topologien und ich bin in der Lage,
mit anderen Leuten darüber zu
sprechen und wir haben eine gemeinsame
Begrifflichkeit.
Zu wiederholen mal, ich bin ganz begeistert von diesem Buch,
einfach deswegen, weil es so
eminent nützlich für
mich ist.
Und ich bin gespannt, was aus deinem
Workshop rauskommt, weil du ja gerade gesagt
hattest, vier Typen.
Die Praxis wird,
da wird mindestens einer kommen in der Praxis.
Das kennen wir alle aus dem Training. Das mag
so sein, aber bei uns ist alles ganz anders.
Ja, dann kann man ja genau mal gucken,
was denn bei denen anders ist oder
ob man es nicht doch hinbekommt,
die Organisation quasi
mit diesen vier Typen zu erklären, um
zum Beispiel auch zu sagen, naja, also
da und da die Probleme, die ihr da habt,
die kommen, weil ihr diese
vier Typen nicht umgesetzt habt. Überlegt
doch mal, ob das helfen könnte.
Genau.
Insofern bin ich mal gespannt
auf deine Erfahrungen aus deinem
Workshop. Lass uns
bei den offenen Punkten noch bleiben,
die wir heute noch zu besprechen haben.
Wir haben eben das Thema
Organisationsgefühl gehabt, wir haben
Schnittstellen gehabt, Team Topologies.
Ein offener
Punkt ist, ganz banal eigentlich,
bei so einem Buchtitel, der
Hinweis Teams First. Also
was hast du da drunter
verstanden oder was hast du aus dem
Buch daraus gelesen?
Das ist einfach die Perspektive, die dir
das Buch einnimmt und sagt,
wir denken
alles vom Team her.
Wir versuchen unsere Organisation,
vielleicht auch sogar unseren Produktzuschnitt
und so fort,
abzuleiten
von den Teams. Nicht von größeren Einheiten
oder auch nicht von kleineren Einheiten. Wir gehen
weder von Abteilungen noch von Individuen oder
sowas aus, sondern wir sehen
alles durch die Brille von Teams.
Das kann man
gut finden oder schlecht, aber ich finde es toll,
dass sie ganz klar sagen,
das ist unsere Perspektive,
weil das ermöglicht es ja auch jedem zu sagen,
okay, diese Aspekte der Perspektive,
die halte ich für nützlich oder jene halte ich für
weniger hilfreich.
Es ist wenigstens mal
klar aufs Tapet gebracht.
Und es passt natürlich auch ganz
ausgezeichnet zu
der Sichtweise, die zum Beispiel Agile hat
oder die zum Beispiel DevOps hat, die natürlich auch
vorzugsweise aus
einer Teamperspektive heraus argumentieren.
Und das sei auch nicht verschwiegen,
das ist ja auch kein Zufall, sondern einfach
das ist die Art, wie
Menschen gerne über
Menschen nachdenken. Das ist glaube ich
etwas, was uns als
irgendwie Primaten natürlich erscheint.
Du hast eine Familie, die hat, ich sage jetzt mal
zehn Leute plus minus
und
du hast eine
ein Dorf oder du hast
eine, keine Ahnung, eine
Sippe oder wie auch immer
man das dann nennen möchte.
Das sind, man sagt doch immer,
die Grenze sei ungefähr 150 Leute,
die man tatsächlich
näher kennen kann
und mit denen man, sagen wir mal,
bedeutsame soziale Interaktionen haben kann.
Also im Prinzip,
wenn ich auf der
Team-Ebene denke, dann denke ich genau auf der
Ebene, wie soziale Interaktionen
zwischen uns
Menschen funktionieren und wahrscheinlich macht es das auch
deswegen so wirkungsvoll.
Die Zahl, die du eben genannt hast, die kommt
aus einer anthroposophischen
Forschung, glaube ich.
Anthroposophische Forschung, jawohl.
Das ist Dunbar’s Number.
Ah genau, ich habe gerade überlegt, wie der Typ hieß.
Anthroposophische Forschung und das erinnert mich
daran, ich habe einen Kontakt, mit dem
wollten wir mal genau über solche
Dinge sprechen. Also es gibt ja ein paar,
es gibt ja auch
Parkinson’s, das Parkinson’sche
Gesetz und so weiter. Es gibt so ein paar Punkte,
die eben quasi gar nicht aus der
IT herauskommen, die aber bei uns
sehr gute Anwendungen finden können. Ich muss
auf den Heiko mal zugehen, dass wir da noch
mal drüber sprechen. Also
zurück zu unserem Podcast
hier, Teams First.
Was ich daran schön finde,
ist, ähnlich wie du auch sagtest,
das ist, denke ich, gerade der große
Trend, dass ich Teams bilde
und vor allen Dingen, dass ich echte
Teams bilde. Wir haben ja beim nächsten Mal
ein Thema, das erklären wir
gleich noch ein bisschen, was das beim nächsten Mal bedeutet,
geht aber auch in Richtung Teams.
Und was ich schön finde, ist eben,
dass ich damit eigentlich
Aufgaben und vor allen Dingen
die Befähigung und die Befugnis
dezentralisiere. Also ich komme,
ich gehe weg von einer zentralen Steuerung,
von einer zentralen Vorgabe.
Natürlich muss ich noch Dinge aus Governance-Gründen
zentral vorgehen oder überprüfen
und ich glaube, auch Security
kann ich nicht dezentralisieren,
aber die Verantwortung für Themen
und das Umsetzen und vor allen Dingen
die Verantwortung, das Dezentralisieren
eben in die Teams, das glaube ich,
ist egal, ob man jetzt über
Scrum oder sonst wie redet oder
über DevOps, das ist etwas, was man
oder was ich wirklich sehr, sehr stark
feststelle. Teambildung,
echte Teambildung, das heißt, dass die Teams auch
nicht nur auf dem Papier zusammengehören,
sondern sich auch entsprechend zusammengehörig fühlen
und dann eben die
entsprechende Befähigung dieser Teams.
Einen Punkt haben wir noch.
Das ist ja alles wunderschön, was wir jetzt hier
so erzählt haben, aber es kommt ja die
Frage, die kennen wir auch aus der
Schulung. Ja, toll, was ihr da erzählt,
aber bei uns geht das nicht.
Was steht im Buch dazu? Wie entwickle ich
diese Topologien? Das Buch
gibt da sogar tatsächlich ein paar
konkrete Vorschläge.
Also
ganz grundsätzlich sagen sie natürlich,
diese Topologien sind nicht in Stein
gemeißelt, sondern sollen
einer fortwährenden Überprüfung
unterzogen werden, im Sinne dieses
Organisationsgefühls
oder ich mag eigentlich den Begriff andersrum
lieber eine fühlende Organisation.
Eine, die sich selbst
ihres Zustandes bewusst
ist und sich darüber Gedanken macht,
aktiv. Aber die sagen auch, es gibt
so ein paar klassische
Ereignisse, bei denen
zu erwarten ist,
dass sich die Team-Topologien ändern
müssen, und zwar
womöglich sogar tiefgreifend.
Oder ein paar, ich sag jetzt mal,
ein paar Signale, ein paar
Smells, um es mal
mit den agilen Begriffen,
zu sagen, zum Beispiel
ein ganz klassischer Swell ist,
wenn ich plötzlich feststelle, ich kann
meine gewünschte Kadenz
nicht mehr halten. Meine Lieferungen werden irgendwie
lahmer,
alles wird so ein bisschen zäher
und teigiger und träger.
Schade, dass die Leute im Podcast
das jetzt nicht sehen können, wie du
diese Kadenz, dieses Träge darstellst.
Das ist ja genauso rum,
wenn alles langsamer ist.
Genau.
Aber das ist,
glaube ich, auch etwas, wo viele Leute
ganz natürlich sagen, warte mal, wir müssen darüber nachdenken,
wie wir zusammen arbeiten, damit
wir diesen Flow weiterhin haben.
Aber
jetzt hat man die Werkzeuge.
Jetzt auf einmal
kann man da was draus machen,
außer zu sagen, wir sollten mal
oder wir müssten mal.
Oder so ein anderer Klassiker ist,
wenn man
plötzlich sich dessen bewusst wird,
dass da eine zunehmende Verfilzung besteht.
Dass immer mehr Dienste
Abhängigkeiten zu
anderen Diensten haben, zu anderen Teams haben,
dass diese Abhängigkeiten immer
enger werden. Und
nochmal, wenn man nicht aktiv gegensteuert,
dann ist das etwas, was passieren wird. Das ist dann einfach
technische Schulden und
dann Conway unmittelbar übersetzbar
auch in organisatorische Schulden.
Dieser Verfilzung muss sich aktiv entgegenwirken.
Und da wiederum habe ich jetzt ein Instrumentarium,
um zu sagen, passt man auf, ist diese Beziehung noch
so, wie sie sollte? Ist da wirklich
noch Access-as-a-Service, wie
wir es uns ursprünglich vielleicht noch vorgestellt
hatten? Oder sind wir mittlerweile
versehentlich in einen Zusammenarbeitsmodus
gerutscht? In einen, den wir
nicht so wollen. Weil du hast ja vorhin gesagt,
dass wir nicht so stark
zusammenarbeiten, dass wir eben verfilzen.
Wenn du es ja auch so schön
genannt hast. Genau.
Darum, das ist der wesentliche Unterschied. Wenn ich ganz
bewusst sage, hier ist Zusammenarbeit
von Nöten, denn wir sind uns bewusst, dass
wir zum Beispiel das Umfeld
noch nicht gut genug kennen. Wir müssen erst mal
gemeinsam erarbeiten, worum geht es denn
hier eigentlich? Aber dann müssen
wir uns entkoppeln. Und wenn uns das nicht gelingt, dann haben
wir da plötzlich, dann haben wir
jetzt Begriffe dafür, um zu sagen,
ist diese Beziehung
noch so, wie wir sie wollen? Wir können uns ja
auch durchaus als Ziel geben. Das kann man ja auch ganz
explizit sagen, dass man sagt, für
das nächste Vierteljahr arbeiten
Team A und Team B eng zusammen.
Und dann müssen wir aber eine
Entkoppelungsbewegung sehen.
Und wenn wir das nicht tun, dann ist das für uns ein
Warnsignal. Wenn du das so sagst,
ist das, glaube ich, auch ein Punkt,
der mir noch nicht so bewusst geworden ist,
warum mir das Buch eben auch so gefällt.
Du hast ja gesagt,
oder was ich aus dem, was du eben
gesagt hast, raushöre, ist, es geht um
Veränderung. Also nichts ist
in Stein gemeißelt. Nichts ist statisch.
Das heißt, das ganze Buch sagt ja eigentlich,
wir geben dir, sagen wir diese Landkarte,
wir geben dir eine Erklärung,
wie etwas sein könnte oder sein sollte,
aber das ist immer
in Veränderung begriffen. Das heißt
eigentlich, Menschen, die sich
in einer festen Struktur
wohlfühlen, also in einer Abteilung
oder wo auch immer, die werden
damit natürlich ein Problem haben, weil
wir ihnen eigentlich sagen, du darfst
dich gerne wohlfühlen.
Wo auch immer du bist, wohlfühlen,
aber das ist etwas, was immer
wieder hinterfragt wird und wo wir immer wieder
überlegen, sind wir noch an diesen
drei Zielen ausgerichtet.
Also lieber zum Beispiel
sich Gedanken machen über die
kognitive Last, wenn die vielleicht zu hoch ist
und dafür eine Veränderung der
Teamstruktur in Kauf zu nehmen,
als die Teams stehen zu lassen, weil
ja die Jahresplanung auf Kostenstellenbasis
für das Jahr, die muss ja noch
gelten und alle ächzen und stöhnen.
Also Veränderung ist eigentlich, glaube ich,
auch ein ganz wichtiger Punkt, den man aus diesem
Buch immer wieder rausliest, obwohl es gar
nicht so explizit drüber steht.
Aber das ist mir so ein bisschen bewusst geworden,
weil es du das eben so gesagt hast.
Du sagst das eben, ich immer wieder gucke,
ja, passt das noch so?
Und man kann Veränderungen eben auch
wirklich bewusst planen. Man muss die nicht
mit sich passieren lassen irgendwie,
sondern man kann sagen, ich stelle jetzt hier
zwei Teams auf und ich erwarte, dass die zunächst
in folgender Beziehung
zueinander stehen und dass das dann aber
im Laufe einer
gewissen begrenzbaren
Zeit übergeht in eine andere
Beziehung.
Und wenn das nicht passiert, dann habe ich
da ein Signal, dann kann ich sagen, Moment,
was ist da los? Habe ich
das Produkt missverstanden, beispielsweise?
Oder habe ich
es schon richtig verstanden, aber ich muss diesen Teams
Hilfestellung leisten, um
zu einer gedeihlichen Beziehung
zurückzuführen, sich zu entkoppeln, beispielsweise?
Ich bin jetzt halt nicht behilflos
meiner Architektur
ausgeliefert,
sondern ich kann die ganz
bewusst verstehen und ich kann
sie ganz bewusst
formen, bezogen auf die Gegenwart
und bezogen auf die Zukunft.
Sehr schön, richtig. Und
es gibt diesen schönen Spruch,
Menschen haben nichts gegen Veränderung,
sondern etwas dagegen, verändert zu werden.
Also die Frage ist ja,
wer stößt die Veränderung an?
Und auch da wieder, wenn man das
Buch verinnerlicht hat, wenn man über diesem
Buch oder mit diesem Buch den Menschen
erklärt, was quasi das Ziel
ist, dann haben sie vielleicht
oder wahrscheinlich viel eher ein
Verständnis dafür, dass sie aus sich
heraus die Veränderung eben angehen
müssen.
Ja, das stimmt.
Wiederum, auch weil man jetzt Begriffe hat
und uns erklärbar machen kann.
Pass mal auf, so stehen
wir momentan da und so wollen wir aber eigentlich nicht stehen.
Das ist eine perfekte Überleitung, Luca.
Gell? Ich habe es mir auch gerade gedacht.
Wohin leitest du den Überblick?
Zu deinem Workshop.
Ich frage
jetzt auch nicht, ob du noch Themen hast,
weil wenn im einen oder anderen jetzt noch
ein paar Fragen auf dem Lippen brennen, dann könnte
man die in den Chat schreiben. Da sehe ich
gerade keinen. Ich gucke immer mal rüber.
Aber viele der Fragen,
die der eine oder andere jetzt vielleicht noch hat, werden
in deinem Workshop erklärt. Also,
wir nehmen das,
den Podcast ja heute auf, heute
am 14.1. Wir werden den morgen
am 15.1. veröffentlichen und
feel free to contact
Luca. Also, wenn ihr
Interesse habt an dem Online-Workshop
von Luca,
du kannst gleich noch ein bisschen was erklären
vielleicht auch noch, aber insofern, wir lassen
das jetzt hier mal so stehen. Wir beenden
das jetzt mal und sagen, wer noch Fragen hat, darf gerne
zu Luca in den Workshop gehen.
Ja, oder auch mich einfach
kontaktieren. Also, ihr merkt ja, ich rede gerne.
Scheut euch nicht.
Das ist ein wahnsinnig spannendes
Thema und ich tausche mich darüber gerne
mit Leuten aus, ob sie jetzt dann hinterher in
meinen Workshop kommen oder nicht und mir dafür jetzt Geld
geben oder nicht. Sei es drum.
Aber ich bin auch schon ganz
gespannt auf diesen Workshop, weil das wird genau so
was, dass man eben nicht nur, ich sage jetzt mal,
Allgemeinplätze über das Buch ausbreiten kann,
sondern dass wir uns auch ganz konkret anschauen,
wie sieht es denn bei euch aus,
in welcher Situation
befindet ihr euch, in welcher Situation
würdet ihr euch gerne befinden und wie sieht vielleicht ein
Weg dahin aus?
Und wir werden das in
genau der Weise machen. Ich werde
euch Wissen vermitteln und
wir werden uns, der ganze Workshop läuft
über vier Wochen, so wird das sein.
Wir werden uns jede Woche treffen. Wir werden einen Call haben
in einer kleinen Gruppe
und wir werden ganz
konkret eure Fragen, eure
Zweifel, eure Situationen
diskutieren
und Wege finden. Und ich glaube,
darin besteht die große Macht von diesem
Workshop dann, dass nicht nur,
keine Ahnung, du und das Buch
und auch nicht nur, keine Ahnung,
ich in der Schulung und erzähle dir irgendwie
die Geschichte vom toten Hund,
sondern, dass man sich auch
mit Leuten austauschen kann, die ganz konkret
auch in derselben Situation sich befinden und sagen, ja,
ich habe da jetzt irgendwie einen Haufen Leute
und wie mache ich denn da jetzt Teams draus? Ich fühle mich da jetzt
gerade unsicher, weil das ist ja auch total
verständlich. Das ist ja,
das ist ja die Millionen-Euro-Frage, wie
baue ich eine gute
Produktarchitektur und angelehnt daran
Teamarchitektur,
da gibt es ganz viele Möglichkeiten,
sich in den Nesseln zu setzen
und insofern ist das, glaube ich, wahnsinnig hilfreich,
erstens zu sehen, dass es anderen genauso geht
und zweitens auch einfach mal gemeinsam mit
anderen zu durchdenken, Erfahrungen auszutauschen,
Sichtweisen auszutauschen und
insofern bin ich wahnsinnig
gespannt auf diesen Workshop.
Ich habe auch schon die ersten Interessenten.
Wie gesagt, der findet statt,
ab Mitte März,
wird einen Monat lang laufen und wer sich dafür
interessiert, der möchte mich gerne kontaktieren.
Ein paar Plätze sind noch frei.
Da bin ich ja mal gespannt.
Wir werden bestimmt nochmal eine Folge haben
mit deinen Erkenntnissen, mit deinen
Geschichten aus diesem, aus dem
Workshop und vielleicht gibt es ja den einen oder anderen
aus dem Workshop, den wir zu Gast
kriegen in unserem Podcast.
Ich drücke uns
bei allen mal die Daumen. Gut,
das war die Erlor-Folge.
In der nächsten Folge haben wir wieder einen Gast,
also wir haben jetzt ein paar Folgen gehabt, wo Luca und ich
ein bisschen was erzählt haben, wo wir beide
die Themen vorbereitet haben.
Wir haben beim nächsten Mal im Februar wieder
einen Gast. Wir haben Rolf Katzenberger
zu Gast, der seine Sicht
auf Teamwork darstellt und
die, die die beiden Folgen jetzt gehört haben,
also auch die letzte, wir sprechen
unter anderem auch über das Tuckman-Modell
und das ist eben noch älter
als Conway’s Law
und trotzdem ist es noch aktuell, also
zumindest bis jetzt. Mal sehen, was uns
Rolf dann dazu sagte und
wer mit dem Begriff Tuckman-Modell
noch nichts anfangen kann, das geht um das Thema
Forming, Storming, Norming,
Performing, also diese ganzen vier
Phrasen oder vier Phasen,
man kann sich streiten, was das so ist
und der Titel der Folge
haben wir auch schon, der lautet nämlich
Teamwork makes the dream work.
Also, wie heißt das so schön?
Dranbleiben und bis zur
nächsten Folge.
Ich sage danke Luca für diese
Heute, das waren ja schon wieder mehr
als 45 Minuten, aber
mir bringt es immer was, ich lerne
ja auch was, habe ich ja eben auch schon wieder gesagt
und dann würde ich sagen, bis
zum nächsten Mal mit Rolf Katzenberger
und Teamwork makes the dream work.
Genau, ich freue mich schon drauf.
Dirk, bis bald.
Bis dann, danke, tschüss Luca.
Ciao.
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik